The first 80% took two weeks. The rest has taken two months.
You're not imagining that, and you're not doing it wrong.
It started remarkably fast. You described what you wanted, the tool built it, and within a couple of weeks you had something you could demo. Screens, a database, a login. It felt like the hard part was behind you.
Then you started finishing it. Payments that work with real cards. Password reset that actually sends. The integration your customer asked about. Deploying it somewhere with your own domain.
Each of those has taken longer than everything before it combined. Some of them you've abandoned and come back to twice. You've got a launch date you've now moved once, and you're starting to wonder whether you should have built it differently from the start.
You shouldn't have. The first 80% being fast and the last 20% being slow isn't a flaw in how you built it. It's the shape of the work, and it catches experienced engineering teams too.
There's a specific reason for it.
The last stretch depends on things that aren't in your code
Here's the difference between the two halves.
The first 80% is describable. "A dashboard showing recent orders" contains everything needed to build it. The model reads your description, generates the code, and it works — because the correct answer was fully specified by the request.
The last 20% isn't like that. The correct behaviour depends on three things a model has no access to:
How an external system actually behaves. Not how its documentation says it behaves. What Stripe does when a card is declined mid-subscription. What your email provider does when a domain isn't authenticated. What happens when an API you depend on is slow rather than down.
What a real user might do. Refresh during checkout. Use a name with an apostrophe. Upload a 40MB file. Click submit twice. Sign up with an address they don't control. None of that appeared while you were testing, because you used the app the way you designed it.
What must never be allowed to happen. Your refund policy. Your permission model.
Whether a cancelled subscriber keeps access until the period ends. Nobody wrote these down, so nobody could generate them.
These aren't hard problems. They're problems where the answer lives outside the codebase — which is why prompting produces confident code that does the wrong thing, and why each attempt to finish quietly breaks something that was working.
So where does it actually stall?
What you see, and what's usually behind it
What's stalling | What's usually missing |
Payments work in test, fail live | Webhook signature unverified, live keys not set, endpoint not registered in live mode |
Subscriptions drift out of sync | No handling for failed renewals, cancellations or card expiry |
Password reset does nothing | Email provider unconfigured, or domain not authenticated so mail lands in spam |
Login works, roles don't | A role field exists and nothing consults it before allowing the action |
One integration won't connect | The provider's real API differs from what was assumed — auth, pagination or rate limits |
File uploads fail on larger files | No size limit handling, no storage configured, no recovery from a partial upload |
No admin screens | Never prompted for, because users never see them |
Errors blank the whole page | No error boundary, no fallback, no logging |
Can't deploy to a real domain | Environment config, DNS, SSL, and a build that only ever ran in the preview |
Works for you, breaks for testers | Edge cases, concurrency, and data shapes you never produced |
The eight areas that stall
Payments. Checkout usually works. What's missing is everything around it — webhook verification, idempotency so a retry doesn't charge twice, failed charges, refunds, and subscription state that follows what actually happened at Stripe rather than what happened once at signup.
Authentication, properly. Login exists. Password reset with a token that expires, email verification, session handling, roles and permissions enforced server-side, and social login working on a real domain — those are five separate pieces of work and generated apps usually have none of them.
Third-party integrations. Where the provider's actual API doesn't match what the model assumed. Auth schemes, pagination, rate limits, webhook formats, and sandbox behaviour that differs from production.
File uploads. Size limits, storage buckets and permissions, virus scanning if you need it, and what the app does when an upload fails at 80%.
Email delivery. Reaching inboxes rather than spam. SPF, DKIM and DMARC, a real sending domain, templates that render in Outlook, and bounce handling.
Admin functionality. The screens you need to run the business — refund someone, fix a bad record, see what's going on. Nobody prompts for these because they're not part of the product story.
Deployment and infrastructure. Your own domain, SSL, environment separation, and a release process you can repeat without holding your breath.
The unhappy paths. What happens when something fails. Almost never generated, because nobody thinks to ask for it, and it's most of what separates a demo from a product.
Some of this you can move on without us.
Three things worth doing yourself
Write down what "finished" means Not a feature list — a list of things that must be true. "A user can pay, and if their card fails they're told, and they don't keep access." Half the reason this stalls is that done was never defined, so every attempt at it moves.
Test your payment flow with a declined card Stripe gives you test card numbers that fail in specific ways. Run one. If your app doesn't visibly handle it, that's the highest-value thing on your list and it's not subtle.
Send yourself a password reset from a fresh browser Then use the link twice. If it works the second time, your reset tokens aren't being invalidated, and that's a security problem rather than a completion one.
None of these fixes anything. All three tell you how far you actually are, which is usually closer than it feels.
If you'd rather someone just finished it —
We finish it, against a scope you approve first
The audit produces a list: what exists, what's missing, and what "finished" would mean for your app specifically. You approve that list before anything starts, and it doesn't move without you agreeing.
That matters more here than on any other kind of engagement. Completion work is where scope drifts, because there's always one more thing — and the reason people stall at 80% twice is that the second attempt had no boundary either.
Then we build it. Payments that reconcile, auth that holds, integrations working against the real API, the failure paths handled, and the admin screens you need to actually operate the thing.
What we won't do
Rebuild an 80%-complete app. It's the wrong call and it discards work you paid for.
Expand the scope while we're in there. If we find something, we tell you and you decide.
Start without a written definition of finished.
Plenty of people keep building while we work.
Working alongside you
That's a normal arrangement and often the right one. You continue on the parts you understand — screens, copy, product decisions — and we take the parts that stalled.
What matters is that the boundary is written down, because two people editing the same files with different assumptions is how you end up further behind. We'll propose one in the audit.
Some people go the other way and hand over entirely for a few weeks, then take it back with documentation. Both work.
Before that, one thing worth knowing about what this is costing.
Stalling is more expensive than finishing
Not in money spent — in the thing you can't get back.
A launch date that's moved twice is a quarter of runway. A customer who was going to see it in March and sees it in June may not still be waiting. Credits spent on a problem that structurally can't be prompted away are gone whether or not it works.
And the codebase itself gets harder. Two months of changes made under pressure, each one abandoned halfway, leaves a project that's genuinely more difficult to finish than it was at the start.
The reason to stop is not that you can't do it. It's that the cost of another month is larger than it looks.
How it runs
01 — Audit. You send the repository. An engineer reads it and comes back within 48 hours with what exists, what's missing, and what finished would mean. Free.
02 — Scope. A written list of what gets built, with a fixed price. You approve it before work starts.
03 — Build. The remaining features, integrations and flows.
04 — Harden. Error handling, edge cases, and the paths nobody prompted for.
05 — Test. The critical workflows end to end, including the failures — declined cards, expired sessions, slow APIs.
06 — Ship. Deployed, documented, and yours. Continuing with us is optional and never assumed.
Questions
Will you finish it or rebuild it? Finish, in almost every case. Rebuilding an 80%-complete app throws away the part that's working to fix the part that isn't, and we'll say so plainly if someone has suggested otherwise.
How do we agree what "finished" means? The audit produces a scope list. You approve it before anything starts. Anything we find later gets raised, not absorbed.
Can I keep building while you work? Yes, and many people do. We'll agree which parts are whose so we're not editing the same files.
What if I don't know what's missing? Normal. Most people know something isn't right without being able to name it — that's what the audit is for.
We have a launch date. Say so on the form. It changes how we sequence, and sometimes it means recommending you cut scope rather than add engineers.
Can you handle payments specifically? Yes, and it's the most common single request on this page. Webhooks, subscription state, refunds and reconciliation.
Will you sign an NDA? Yes, mutual, before you send anything. One senior engineer reads your code, never used for training, access removed after delivery.
What happens after launch? Your call. Some people take the handover and continue alone, some hire, some keep an engineer monthly. None of those is assumed.
Send us the repository
You'll get what exists, what's missing, what "finished" would mean for your app, and a fixed scope to get there.
Also relevant
Payments · Authentication · Production readiness · Crashes with real users · Lovable · Bolt.new