Stuck Building an App With AI? What to Do Next

It's a scene I see almost every week. Someone has a genuinely good idea, opens Lovable, Bolt or v0, types what they want, and within a couple of hours there's something on screen that looks like a real app. The first feeling is pure elation. "I built this myself, and it actually works." Then comes the second evening. People need to be able to sign up. You need to take a payment. The data has to live somewhere instead of vanishing when the page reloads. It needs to go live on the internet, not just sit on localhost. And suddenly everything grinds to a halt.

You ask the AI to "connect payments" and it generates code that looks right but doesn't work. You ask it to fix that, and it patches one spot while breaking three others. Ten rounds in, you've no idea which bit of code does what, the deploy throws an error neither you nor the AI understands, and that elation has curdled into the strange panic of having 70% of a product and not the faintest idea how to cross the last 30%. This is vibe coding meeting the wall it always meets.

If that's you, read to the end. Over the years I've seen plenty of these "nearly finished" projects. In this article I'll be straight with you about why this happens to nearly everyone, what "production-ready" honestly means, the three real options you have when you're stuck, and what each one costs. No hype, no hand-waving.

Why almost everyone gets stuck in the same place

This isn't your fault, and it isn't a measure of how clever you are. AI tools are built to get you to an impressive result as fast as possible, and the most impressive, easiest-to-show part is the visuals. Screens, buttons, forms, animations, a tidy layout. That's exactly what AI generates brilliantly, because there are millions of examples of that kind of code online and it's self-contained — it doesn't have to talk to your real database or your real bank.

The catch is that the impressive part was always the easy part. The real work — the work that turns a pretty mock-up into a functioning business — starts precisely where the AI hits a wall. I call that wall the hard 30%: authentication, payments, the database, security, GDPR, deployment, integrations and edge cases. That 30% of the scope eats 70% of the time and needs experience the tool simply can't hand you.

There's another reason you got stuck now rather than earlier. The AI works with a limited "memory" of your project. While there's not much code, everything's fine. But as the files pile up, the tool starts forgetting what it wrote earlier, and its fixes break working code more and more often. That's not a glitch — it's a limit of how the thing works. I go deeper into how a prototype differs from a product in a separate piece on vibe coding and why an AI prototype isn't a product yet.

What "production-ready" actually means

A lot of people assume "finished app" equals "looks good and works on my screen". In reality there's a chasm between those two things. Production-ready means the app works reliably for real people, on the real internet, with real money and real data — without you sitting next to it restarting the server every time something breaks.

Here's an honest picture of what AI did well in your project and where you almost certainly hit the wall:

Area	What AI does well	Where it hits the wall
User interface	Smart screens, forms, buttons, responsive layout	Almost nowhere — this is where AI is genuinely strong
Authentication	Login form, "forgot password" screen	Secure sessions, tokens, password hashing, real sign-in, passkeys and 2FA
Payments	The look of the basket and checkout pages	Real money moving, Stripe/PayPal webhooks, failures, refunds, PCI scope
Data	Simple CRUD examples, demo data	A real database that persists, migrations, backups, secure rules
Deployment	It runs on localhost	Domain, hosting, environment variables, SSL, actually going live
Security & GDPR	Next to nothing	UK GDPR, cookie/PECR consent, ICO registration, access control, a privacy policy
Edge cases	The "happy path" where everything goes right	What happens on bad input, a dropped connection, a declined payment

Look at the right-hand column. That's your "remaining 30%". It isn't cosmetic — it's the core of the product. An app that looks gorgeous but loses a customer's payment, or leaks their data, is worse than no app at all, because it destroys trust in your business. And in the UK specifically, the Data Protection Act 2018 and UK GDPR apply to every business — there's no small-business exemption. AI-built apps almost always ship with no privacy policy, no lawful basis, no cookie consent and no ICO registration. That's not a detail to bolt on later; it's a legal baseline.

The three options when you're stuck

When you reach this point, you really have three roads. None of them is right for everyone — it all depends on how much it matters to you to get this to market, and how much time and patience you can spare.

Option 1: keep fighting it yourself with AI

This road suits you if learning it yourself is the point, if it's a side project with no deadline, and if the risk of breaking for a real user costs you nothing. If that's the case, genuinely, use AI and keep at it. I say that openly, because not every project needs a developer, and I'm not in the business of selling you something you don't need.

Option 2: scrap it all and start over somewhere else

The truth is that not everything from your work is lost, even if you do start fresh. The idea itself, the user flows, the screen logic, what you actually want — that's valuable work you can carry forward. I write about how people travel from an idea to a real app, and the traps along the way, in my piece on going from a ChatGPT idea to a real app.

Option 3: hire someone to rebuild it cleanly from your prototype

This road suits you when it matters to launch for real, when actual customers or payments are waiting, and when you understand that your time is worth more spent on the business than on wrestling deploy errors. That's exactly where I come in.

Why I rebuild cleanly rather than patch spaghetti

I want to be honest about how I work, because it tends to surprise people. When someone brings me a stuck AI project, they often expect me to "just fix their code". I don't do that — and it's a deliberate choice in your favour.

I don't take over, patch or continue someone else's or AI-generated code. Even when the structure looks decent, untangling what the AI was "thinking" and hunting for hidden gaps costs so much that a clean rebuild almost always comes out more reliable. And if the code is what I call spaghetti — layer upon layer of AI patches where each change breaks three others, with no clear architecture — patching it would be both more expensive and less reliable than rebuilding. If you'd still rather carry on with the existing code, that's something you can do yourself or with whoever built it.

Here's the heart of it: I'm not offering to "tidy up your code". I'm offering to "build it so it works and earns". Those are different things. Tidying code means sticking yet another plaster on something already creaking. Building it to work means making sure payments go through, data is safe, sign-in is reliable, the deploy is stable, and when something does go wrong the system doesn't fall over. The expectation I always set up front: the hard 30% is the most expensive and the most time-consuming part, and it's the precise reason people get in touch.

The best part of your work — the idea, the screens, the flows — is almost always preserved. Rebuilding "cleanly" doesn't mean your work gets thrown away. It means the prototype becomes the specification, and I build a solid foundation under the visuals from scratch — the one the AI never built.

One more thing UK buyers rightly ask about: who they're trusting with this. I work as a registered company, I'll speak plainly about risk — security, data, downtime — rather than in jargon, and I own the outcome. You can see how I approach delivery on my app development page.

The local integrations AI can't wire up for you

There's a separate category within the hard 30% I want to single out, because it's specific to the UK market and AI is powerless in it. These are the real-world integrations. AI can generate a pretty checkout form, but it physically can't connect the live systems behind it for you.

The concrete examples I end up wiring by hand again and again:

• Payments via Stripe, PayPal, Apple Pay and Google Pay — account verification, webhooks, failure and refund handling, and reducing PCI-DSS scope by using hosted flows correctly, not just a form that looks like a checkout
• GoCardless Direct Debit and subscription billing — recurring payments, mandates and dunning, not "connect the API in five minutes"; the same goes for Klarna or Clearpay if you sell BNPL
• Auth and identity — Auth0, Clerk or Supabase Auth done securely, passkeys and 2FA, plus KYC via Onfido or Yoti and e-signing via DocuSign where the use case demands it
• Accounting and tax — pushing invoices into Xero or QuickBooks and meeting HMRC Making Tax Digital for VAT (with mandatory B2B/B2G e-invoicing via PINT UK/Peppol on the roadmap for around 2029)
• Shipping — Royal Mail Click & Drop, DPD or Evri label generation and tracking, plus Click & Collect, wired through carrier REST APIs rather than a plugin

AI only "knows" these systems superficially, and the code it generates often doesn't even compile or doesn't meet the provider's requirements. This is work that needs a human — sign-up, testing in a real sandbox, and experience. I go deeper into exactly why AI reaches its limit here in my article on the local integrations AI can't wire up.

What it really costs to get unstuck

Let me get to the numbers, because that's what you actually need. I don't finish AI code, so these are my prices for a clean rebuild from scratch, with your prototype as the specification — in euros, always "from". I'll stress this: the exact figure depends not on the state of your code but on what the product has to do — how many features, which payments and integrations.

Scope	What it covers	Price
MVP / PWA	Sign-in, database, security and deployment; iOS and Android from one codebase	from €2,900
Business app	Payments, accounts, admin and local integrations (Stripe billing / GoCardless / Xero + HMRC MTD / shipping)	from €6,900
Complex platform	Several user types, complex business logic, many integrations, scale	from €14,900

For context, a senior independent UK developer typically charges £400-£650/day + VAT — and that matters. A £450+/day quote signals someone who can actually ship to production, as opposed to a £5/hr marketplace gig that lands you back where you started. Notice, too, that these prices match normal web app development costs. That's no accident. AI does the easy half, but the most expensive part — the hard 30% — is still there, and that's what drives the price. People are sometimes surprised — "but half of it's already done." The cheap half is done. The expensive half is still waiting.

And it almost always pays off. Weigh up the alternative: a month of your own time fighting bugs, plus the risk of launching something that loses payments or doesn't meet UK GDPR. A clean professional rebuild takes that risk off the table and gets your product to market faster than you'd manage on your own.

What to do before you get in touch

If you decide you need a hand, here are a few steps that will speed everything up and help you get an accurate quote. The more clearly you describe what you want to build, the more accurately I can scope the work.

• Keep your prototype. A link to the working Lovable, Bolt or v0 prototype, or screenshots of the screens — that becomes the specification and visual reference. I don't need the code: I don't take it over, I build the product from scratch.
• Write down what you were trying to achieve. A few sentences on what the app should do and who your user is — that's worth more than ten screens.
• List what the product must do but doesn't yet. "Customers need to pay by card or Direct Debit", "the data has to persist", "users need a secure sign-in" — the more specific, the more accurate the quote.
• Gather your access. If you already have a domain, hosting account or a payment provider you've trialled, have that information ready.

In short: what to do when you're stuck

If you started building an app with AI and got stuck, the first thing to know is that it's normal and it happens to nearly everyone. AI gets you to 70% beautifully, but it leaves the hard 30% — authentication, payments, data, security, deployment and local integrations — to you. That's not cosmetics; it's the core of the product.

You have three roads: keep fighting it yourself (fine for a side project with no deadline), start from scratch (risking the same wall), or hire someone to rebuild it cleanly from your prototype (when launching for real matters). If you pick the third, your prototype becomes the specification and I build the product from scratch so it works and earns. You stay the owner of the code, I use mainstream technologies, and the hard 30% becomes my problem, not yours.

To carry on with the theme, it's worth reading how an AI prototype differs from a product, and the five traps on the road from a ChatGPT idea to a real app. And if you'd like your stuck idea turned into a working product right now, get in touch and tell me what you're building.

Frequently asked questions