You built it with AI over a weekend. Now what?

Something changed in the last couple of years. An office manager, a founder or a sales lead with no developer background can open an AI tool on Friday and have a working app by Sunday. A spreadsheet becomes a dashboard. A booking form becomes a small system.

That's good news. The hard part of software used to be getting it built. Now the hard part is everything after: making it safe, dependable and somebody's job. That's the part our software and systems work is built around, and it's the part most weekend builds skip.

A demo and a product are different things

A demo has one user, the person who built it. It runs on their laptop, with their data, and when it breaks they know why. A product has many users who don't know how it works, data that matters, and nobody standing behind it to explain the strange error message.

We think about software in six stages: explore, prototype, demo, validate, launch and operate. A weekend build usually lands somewhere between prototype and demo. The list below is what it takes to get from there to launch.

The checklist

Logins and permissions. Who can sign in, and what can each person see and change? A crew lead shouldn't see payroll. A customer shouldn't see other customers. Decide the roles before you add the users, because adding permissions later means checking every screen again.

Where the data lives. Find out where your app actually stores its data. If the answer is a free tier, a file on someone's laptop or a service nobody remembers signing up for, fix that first.

Backups you've restored. A backup you've never restored is a guess. Set up automatic backups, restore one into a copy of the app and check it worked. Do it again after every big change.

What happens when it breaks. Every app fails sometimes. What matters is what the user sees and who finds out. Plain error messages for people, a log for whoever fixes it, and an alert when something keeps failing.

Security basics. Keep passwords and API keys out of the code, use HTTPS everywhere, and read what the AI tool added that you didn't ask for. Generated code can work perfectly and still leave a door open.

Hosting and running costs. Know what you pay each month and what makes that number grow. Usage-based services are cheap at ten users and surprising at a thousand.

Someone who owns it. Software needs looking after, the same way a website does. Libraries get security fixes, browsers change and people ask for the next feature. Name the person or team who does that before launch, not after the first outage.

Test it with the people who'll use it

This is the validate stage, and it's the one weekend builds skip most. The person who built the app knows which buttons to avoid. Everyone else doesn't. Sit with two or three of the people who'll actually use it, give them a real task, and watch without helping.

You'll find the gaps fast. The screen that only makes sense if you built it. The form that loses everything when the phone locks. The report that's right for the office and useless on a job site. Fix those before launch, because after launch they become reasons people stop using it.

Check it on the devices people really use, too. A tool built on a big monitor often falls apart on a phone in a truck, which is exactly where field teams open it.

Connect it to the tools you already run

A weekend app usually lives on its own island. Real software has to talk to the rest of the business: payments, email, the calendar, the accounting system, the CRM. Each connection is a new place for things to go wrong, so treat each one as its own small project.

For every connection, know three things. What happens if the other service is down for an hour. What happens if the same message arrives twice. And who gets told when the two systems disagree. Payments in particular need care: a charge that goes through twice, or not at all, is the kind of bug customers remember.

Write the handover before you need it

One page is enough. Where the app runs and who has the logins. How to put out a new version. Where the backups are and how to restore one. What it costs each month. Who to call when it breaks. If the person who built it left tomorrow, that page is the difference between a bad week and a lost system.

When it should stay a spreadsheet

Not every weekend build should become a product. Sometimes the honest answer is a well-built spreadsheet or an off-the-shelf tool. If only three people use it, it doesn't touch money or private data, and nobody minds when it's down for an afternoon, keep it simple.

If it takes payments, holds customer data or runs work your team can't do without, treat it as real software. That's where a second opinion earns its keep, before you spend money fixing the wrong thing.

Where to start

Go through the list and be honest about the gaps. If they're bigger than your team can close, that's normal. It's the same question you'd ask when hiring a designer or developer: who builds it, who keeps it running, and how you'll know it's working.

And if you're not sure which stage you're at, that's fine too. Most people aren't. Tell us what you've built and we'll help you work out what it needs next.