Hire a developer after Lovable.

What the last 20% actually is

The 80/20 split founders hear about is real, but it under-sells how different the two halves are. Lovable will get you a working UI, working auth, and basic CRUD against a Supabase Postgres in an afternoon. That first 80% is pattern-matching — scaffolding the same React + Supabase shape the generator has shipped a thousand times. The last 20% is the part where the shape stops being generic and your product’s specific rules start to matter, and that’s where the generator quietly stops being able to help.

Concretely, the last 20% looks like this. Row-level security policies that actually protect user data — not just enabled on the table, but policies that enforce auth.uid() = user_id on every read, write, and update path, including the ones the generator forgot to add. Stripe subscription lifecycle handling beyond happy-path checkout — webhook signature verification, idempotent handlers for customer.subscription.updated, graceful handling of invoice.payment_failed, proration on mid-cycle plan changes, and a refund path that also reverses the entitlement in your database. CI/CD so the next deploy doesn’t break production — GitHub Actions running type-check, lint, and tests on every PR, preview deploys per branch, migrations applied via a reviewed workflow rather than by clicking buttons in the Supabase UI.

It also includes auth edge cases that the generator skips entirely: password-reset tokens that actually expire when they should, OAuth statevalidation so callbacks can’t be replayed, session persistence across tabs, and a sensible answer for what happens when a user deletes their account mid-subscription. It includes custom OAuth flows for enterprise SSO — the moment a paying customer asks for Google Workspace or Okta, the default Supabase email-and-password flow is no longer the whole story, and you need a developer who understands how to map SAML claims to your user table without breaking your existing sign-in. And it includes database migration management — a committed, reviewable history of schema changes so that when you need to add a column, rename a table, or backfill data across ten thousand existing rows, you do it without losing data and without a three-hour outage. “Done” on each of these isn’t a feeling — it’s a test that runs in CI, a policy you can read, and a runbook your next engineer can follow.

None of this is complex. A mid-level backend engineer has built every one of these pieces ten times before. What makes the last 20% feel hard is that it’s consistently missingfrom AI-generated codebases in the same ways. The generator is trained on what ships a demo, not what survives a Tuesday outage. So the gap you’re staring at isn’t a hole in your product idea — it’s the standard production-engineering checklist that every non-AI codebase already had to cross. You’re not behind because Lovable failed you. You’re at the point every app reaches, a little sooner than you expected.

Our approach with Lovable codebases

We start with the free Rescue Diagnostic — a 48-hour async audit of your Lovable codebase. You give us read access to the repo and, if you’re comfortable, to Supabase and Stripe dashboards in read-only mode. We map every gap between “works in the Lovable preview” and “works for paying users on a Tuesday night when an email webhook fires.” The output is a written document: findings, severity, a recommendation of rescue vs. rewrite, and a proposed scope. It’s yours to keep whether you hire us or not.

Most Lovable apps come back with 8–12 issues. The distribution is remarkably consistent: security gaps (RLS disabled, auth redirect loops, service-role keys exposed in the client bundle), reliability gaps (Stripe webhooks without signature verification, unhandled promise rejections that become silent 500s, no retry logic on third-party API calls), and devops gaps (no CI/CD, production environment variables pasted by hand, no staging environment, Supabase migrations applied ad-hoc). Each issue gets a severity, an estimated fix effort, and a note on whether it blocks launch or can be queued.

From the audit we scope the smallest fixed-price engagement that closes the critical gaps. Typically that’s either the Break-the-Fix-Loop Refactor at $3,999(for apps that mostly work but have started regressing under the generator’s own edits) or Finish My MVP at $7,499(for apps that need the last-20% work described above before they can accept a paying user). We preserve all the working code — the UI, the data model, the core user flows that you’ve already iterated on with real users. We add what’s missing without rewriting what isn’t broken. A rescue is not a rewrite.

Practically, engagements run as two-week sprints with a written plan at the start and a demo at the end. You see every commit as it happens — we work in your repo on a branch named afterbuild/*and open pull requests you can review. Security fixes land first, reliability fixes second, devops last. By the end you have a production environment with secrets in a vault, a staging environment that mirrors production, CI running on every PR, and a handoff document that tells your next engineer (or you, in six months) exactly how the system is put together. If something surprises us in the audit — say a critical data-integrity bug we didn’t see in the initial read — we pause, tell you, and re-quote before continuing. No silent scope creep.

What happens to your Lovable subscription?

Most founders keep it. After we ship to production, Lovable becomes your UI editor — you use it to make frontend changes while we, or your next hire, manage the backend, the integrations, and the DevOps. This tends to be the best of both worlds for a non-technical founder: you can still make copy changes and layout tweaks through chat on a Sunday afternoon, and the parts that actually need an engineer stay out of Lovable’s reach.

Some founders migrate fully to a developer-maintained codebase and cancel Lovable — usually because they’ve hired their first full-time engineer and don’t want a second editor in the loop, or because the frontend has outgrown what the generator can reliably edit without regressing. We’ll tell you which makes more sense after the audit. There’s no prize for staying on Lovable and no prize for leaving; the right answer depends on who’s going to be editing this code six months from now. We’ve seen teams do both well, and we’ve seen teams do both badly — the common failure mode is picking the path for the wrong reason (sunk cost, team anxiety, vendor FOMO) rather than for what the code and the roadmap actually need.

A typical two-week production-hardening sprint

Concretely, here is what a typical production-hardening sprint looks like for a Lovable codebase that has 50–500 paying users and is starting to creak. Monday of week one, we kick off with a thirty-minute call to confirm the audit findings and the priority order. Tuesday through Thursday we’re in the repo writing RLS policies, backfilling them against existing data, and running them against a suite of test cases we write alongside them. By Friday, every table has row-level security enabled, a policy that enforces ownership, and a test in CI that fails if the policy is removed.

Week two focuses on payments and webhooks. We verify your Stripe webhook signing secret is in place, rewrite the handlers to be idempotent, and add handlers for the lifecycle events that weren’t wired: invoice.paid, invoice.payment_failed, customer.subscription.updated, customer.subscription.deleted. Each one updates the user’s entitlement in your database within a database transaction, so your app state can never drift from Stripe’s view of the subscription. A dead-letter queue catches anything that fails and alerts you in Slack before the customer notices.

Alongside the payment work, we stand up a real CI/CD pipeline: GitHub Actions that run type-check, lint, and tests on every pull request; a staging environment that mirrors production with its own Supabase project; and preview deployments for every branch so your designer can review UI changes without touching main. On the last day, we ship a handoff document — a living README that explains every non-obvious decision, a runbook for the most common on-call scenarios, and a backlog of anything we saw but didn’t fix, prioritised by severity, so you know what’s next whether you come back to us or hand it to someone else.

How this compares to hiring a full-time developer

A good full-stack engineer in the US or Western Europe costs $150k–$220k fully loaded, plus three to four months to find, plus onboarding. For a seed-stage founder with a Lovable MVP, that’s an enormous commitment before you know whether the product has legs. The math we hear back is that a fixed-fee Afterbuild Labs engagement gets the same code outcome— a production-ready app — at a tenth of the cost and in a fifth of the time, while deferring the full-time hire to the point where there’s enough ongoing work to justify a salary.

That doesn’t mean we’re the right call for everyone. If you already have ten engineers and you’re thinking of adding one more, hire in-house — we’ll happily pair with them to transfer the Supabase and Stripe playbook. If you’re pre-product-market-fit and still iterating on the idea weekly, stay on Lovable a little longer; hardening a product that’s going to pivot is spending money twice. The sweet spot for Afterbuild Labs is the founder who has a working Lovable MVP, a real user base, and the first signs that the current codebase can’t carry them to the next milestone.

Signals it’s time to bring in a developer

Founders usually know they need help a few weeks before they ask. The signal is rarely a single outage. It’s a pattern: a support ticket about a double charge that you can’t explain without SQL, a customer asking whether their data is visible to anyone else on the platform and you realise you’re not sure, a prospective investor asking for a repo walkthrough and you freeze. Each of those is your codebase telling you that the shape of your business has outgrown the shape of the generator. They’re not failures — they’re milestones. The codebase did its job getting you here; now you need a different class of tool to keep going.

A more mundane signal: you’ve started editing the generated code directly, through Lovable’s code view or a cloned Git repo, and you’re finding that the generator’s next round of edits undoes or regresses your manual changes. This is the “fix loop” we named a service after. It means the codebase has crossed the line from generated to hand-edited, and from that point on, the round-trip through the generator costs you more than it saves. Most teams hit this around month three of serious iteration. When you notice it, stop merging generator output for the risky files and bring in a human to own them.

The hardest signal to read is silent data risk. RLS misconfigurations don’t crash the app. Missing webhook signature verification doesn’t show up in Sentry. Expired password-reset tokens that still work will never page you. These failures only surface when someone looks for them — a security researcher, a curious user, or a breach. That’s what the 48-hour audit is designed to uncover: the problems that aren’t visible in your error logs because they haven’t caused an error yet. We’d rather find them on a Tuesday morning with you than see them on Hacker News on a Sunday night.

What working with us feels like day-to-day

We work asynchronously by default. You get a shared Linear or GitHub Projects board with every issue scoped and estimated; every pull request links back to a specific line in the audit. There are no weekly status calls unless you want them — instead, you get a written end-of-day update on working days with what landed, what’s in review, and what’s blocked. If you need a synchronous call, you can grab time on Hyder’s calendar directly; we try to answer non-urgent messages within one working day and urgent ones within an hour during your timezone’s working hours.

Every engagement ships with a 30-day warranty. If anything we wrote breaks in the month after handoff — a migration that fails under load, a webhook we missed, a policy that’s too strict — we fix it free. After the warranty period, most teams stay on a small monthly retainer for on-call coverage and ongoing improvements; others take the handoff document and run with it solo or with their next hire. Either is fine. The goal of the engagement is to leave your codebase in a state where you have real options, not where you’re locked into us.

If you want to see the shape of this before committing, the Rescue Diagnostic is free and you keep the report regardless. Most founders use it to decide whether to rescue or rewrite; a handful use it as ammunition to negotiate a better deal with their existing developer. However you use it, you’ll have a clear, written picture of your codebase’s gaps within 48 hours of kick-off. From there, the next step is yours.

One last note on what we don’t do. We don’t do brand. We don’t do SEO content. We don’t do paid acquisition. We are a small team of production engineers with a narrow specialisation — turning AI-generated MVPs into systems that can take a credit card without leaking data or double-billing a customer. If that’s the problem you have, we are almost certainly the right partner. If your problem is a different shape, we’ll happily refer you to a specialist we trust, because sending you to the wrong team wastes everyone’s time. Book the audit, keep the report, and take the next step from a position of clear information rather than guesswork. The worst outcome is that you learn your codebase is in better shape than you feared; the best outcome is that you ship a production-ready app a quarter earlier than you otherwise would have.