You vibe coded an app. Now comes the hard part.

A decent share of our enquiries this year start the same way. Someone’s built an app themselves, in Claude or Google AI Studio or Lovable or Replit, and it works. Screens, logins, data going in and coming back out. They demo it off a laptop and it does what they say it does.

Then: “I just can’t work out how to make it real.”

Building it at all deserves credit, so let’s not skip that. Two years ago the same idea dies in a notebook, or costs twenty grand in developer time to find out it wasn’t worth building. Instead, the person who understands the business problem better than any developer ever will has sat down and built a rough version of the fix over a few weekends. Nothing below takes that away.

But the wall is real. Getting an app live is a different job from building one, and the AI tool has been doing neither of the hard parts for you.

What the tool was quietly doing for you

The whole time you were building, the tool had your app wrapped in a sandbox. It supplied the hosting, so you never picked a server. It gave you a scratch database so your test records had somewhere to live, probably its own API keys, its own web address, maybe its own login layer too. Your app has had exactly one user, on a good connection, typing sensible things into every field.

Move it to your own domain with paying customers and every one of those props gets pulled. Hosting, database, keys, traffic: all yours now. And if the database was one of the scratch ones, whatever’s in it evaporates when the session does.

That’s why “how do I deploy this” feels like hitting a wall. The sandbox was standing in for most of the system, and you’re being asked to supply the rest at the exact moment you thought you were done.

What getting it live involves

The unglamorous list, then.

The app needs somewhere to run: a hosting account someone owns, pays for, and can log into when things go wrong. It needs a database that persists, plus a backup someone has tested restoring, because an untested backup is a hope with a filename. The API keys the AI helpfully pasted straight into the code have to come out of the code. Anything shipped to a browser can be read in a browser, and a leaked key bills your card, not the AI’s.

If people have accounts, the logins need doing properly: hashed passwords, sane sessions, a password reset that doesn’t leak, and a real answer to who can see whose records. You need your domain pointed at the thing, with HTTPS. You need email that lands in inboxes instead of spam folders, which has become its own small science. And you need error logging, so you hear about the 6am crash from a log instead of from a customer on Thursday.

Ordinary plumbing, all of it. We covered the ongoing version in AI can help you build software, who keeps it running? The preview just never made you think about any of it, so it all lands at once, at the end, looking like one giant unanswerable question.

Nobody has attacked your app yet

There’s a nastier layer under the plumbing. The app was built with no adversary in mind, because in the sandbox there wasn’t one.

So, a few questions worth sitting with. If someone calls your app’s endpoints directly and skips the buttons entirely, what can they get? Plenty of vibe coded apps check permissions in the interface and nowhere else, which means the polite version of the app has rules and the direct version doesn’t. What stops a script hammering your signup form ten thousand times an hour? What do the AI features do when someone pastes something hostile where the customer enquiry was supposed to go?

If customer data is involved, this stops being a curiosity. The Privacy Act applies to you, the Notifiable Data Breaches scheme applies to you, and neither has a carve-out for “an AI wrote it”. If money is involved, don’t build that part at all. Stripe and its competitors exist so card details never touch your system.

Most of this is routine to fix for people who fix it weekly. It just has to happen before strangers show up.

Asking the AI to deploy it for you

People try this. It’s usually where the wheels come off.

Deployment mostly isn’t code, it’s accounts, credentials, DNS records, billing details and judgement calls, and all of that lives outside the chat window. The model can’t see your domain registrar. It doesn’t know your hosting budget, or that your customer records probably shouldn’t sit in a US data centre. So it does what models do and produces confident, plausible instructions: some right, some written for a version of the platform that changed last year, and some that work first go while quietly leaving your database open to the internet.

That last kind is the one we see most. Everyone asks “did it deploy?”, and often it did. The site loads, the AI said done, tick. Nobody asks what state it’s running in now that it’s up, and that’s the question with your name on it legally. We’ve made the longer argument about the gap between a good prompt and a working system in prompts are not an AI strategy.

And when the instructions only half-work, you end up debugging infrastructure you’ve never touched at 11pm, pasting error messages back into the chat and hoping. No shame in it. It’s just a terrible place to run a business from.

What you’ve built is a proof of concept

A good one, probably, and worth more than you think.

The part of software projects that fails most often is deciding what to build. You’ve done that bit. You’ve tested the idea against your own process and produced something concrete enough to argue with, and a working prototype beats any requirements document as a brief, because nobody nods vaguely at a prototype the way they nod at a document. The expensive disasters in this industry are careful builds of the wrong thing. You’ve already spent that risk for a few weekends and a subscription.

The gap between a convincing demo and something people can rely on hasn’t gone anywhere, though. We walked through it in proof of concept to production, and it doesn’t close just because the demo came out of a chat window.

Two ways it goes from here

When someone brings us one of these, it goes one of two ways, and we’ll tell you which after reading the code, not after reading your budget.

Sometimes the build is worth keeping. Contained scope, moderate stakes, an internal tool rather than a public product. Then the job is a hardening pass: audit the code, fix the dangerous bits, get the secrets out, put it on proper infrastructure with backups and logging, and hand it back with an honest list of what’s still rough. That’s our code cleanup and project rescue work, and it costs a lot less than a rebuild.

Sometimes the prototype has done its job and shouldn’t carry passengers. If the thing will face the public, hold customer data or take money, it’s often cheaper over a year to treat your version as the spec and build the production system properly, keeping every decision the prototype already proved right. If you want numbers for that path, we’ve published them rather than making you sit through a sales call first. Either way, the weekends weren’t wasted. They bought the kind of clarity most projects pay a lot more for.

If you’ve built something and hit this wall, send it to us: the app, who needs to use it, and what data it’ll hold. You’ll get a straight answer on which path you’re in and roughly what it costs, including “harden it yourself, here’s the list” if that’s the truth.