Andrew Crossley
    LOVABLE · BOLT · CURSOR

    Lovable to production

    Taking a Lovable app to production means turning a working prototype into something real customers can use and pay for: proper accounts and data access rules, AI output tested against real inputs, predictable cost per user, error handling, analytics and a launch surface. The build is usually 80% done and the last 20% is what decides whether it survives its first hundred users. I do that last 20%.

    Send me your Lovable app See The Crossley Method

    WHO THIS IS FOR

    Where prototypes usually stall

    • It works when you use it, and breaks the moment someone else does something unexpected.
    • Accounts exist but you are not confident one user cannot see another user's data.
    • The AI feature is impressive in a demo and you have no way to tell if it is right.
    • You have no idea what a hundred active users would cost you in model and infrastructure spend.
    • Errors fail silently — no logging, no alerts, no way to reproduce what a customer reported.
    • There is no pricing, no onboarding and no analytics, so launching would teach you nothing.

    THE FRAMEWORK

    The Crossley Method: idea to first revenue in seven stages

    See the full method
    1. STAGE 1DiscoverWeek 1
    2. STAGE 2ValidateWeek 2
    3. STAGE 3PrototypeWeek 3
    4. STAGE 4Build MVPWeeks 3-4
    5. STAGE 5LaunchWeek 5
    6. STAGE 6First RevenueWeek 6
    7. STAGE 7ScaleOngoing

    WHAT THE WORK COVERS

    What production hardening actually covers

    Nothing here is exotic. It is the unglamorous list that separates a prototype from a product, done in the order that reduces risk fastest.

    Access and data

    Real accounts, roles and row-level rules, then tested by trying to break them. This is the single most common gap in AI-built apps and the one with the worst consequences.

    AI reliability

    An eval set built from real inputs, a measured pass rate, guardrails, fallbacks and a human path for when the model is wrong. Quality you can point at rather than hope for.

    Cost and latency

    Cost per action and per active user modelled before launch, with model routing so the cheap model handles the easy majority.

    Resilience

    Error handling, retries, logging and alerting so a failure becomes a ticket you can reproduce rather than a customer who quietly leaves.

    Launch surface

    Pricing, checkout or waitlist, onboarding, and analytics instrumented against the two or three events that actually tell you whether it is working.

    HOW IT RUNS

    How a hardening engagement runs

    1. Day 1-2

      Production readiness review

      I go through the app as an attacker, as a confused first-time user and as a finance director. You get a written list of what must be fixed, what should be fixed, and what can wait.

    2. Week 1

      Access and data

      Auth, roles and data access rules corrected and tested. Nothing else matters if this is wrong.

    3. Week 2

      AI reliability and cost

      Eval set written from your real inputs, prompts and retrieval tuned against it, model choice and routing set against a cost target.

    4. Week 3

      Resilience and launch surface

      Error handling, logging, analytics, pricing and onboarding. The product becomes something you can put in front of strangers.

    5. Handover

      You own it

      Live product, the eval set, the cost model and a written next-steps list. No lock-in and no retainer required.

    PRICING

    Lovable to production pricing

    Fixed scope, fixed price. The review stands alone — plenty of founders take the list and do the work themselves.

    Production readiness review

    £950

    Two days. Written audit of access, data rules, AI reliability, cost, resilience and launch readiness, ranked by risk.

    Hardening sprint

    From £6,000

    Three weeks. The review carried out: access, evaluation, cost control, error handling, analytics and launch surface.

    Build and launch

    From £12,000

    Six weeks. Hardening plus the missing product work, pricing and public launch — the full idea-to-revenue route.

    Building rather than hiring? Get a number in 60 seconds with the MVP cost calculator.

    COMPARISON

    Hardening an existing build vs starting again

    Rebuilding is sometimes right. It is right far less often than agencies claim, because the prototype already encodes decisions that took you months to reach.

    FactorHarden what existsRebuild from scratch
    Time to launchThree to six weeks.Three to six months.
    CostLow five figures.Mid five figures upwards.
    What you keepYour product decisions, your data model, your momentum.A clean codebase and a repeat of the same discovery.
    RiskKnown gaps closed one at a time, in risk order.New unknowns, plus the old ones you had already solved.
    When it is rightThe concept is proven and the plumbing is weak.The architecture genuinely cannot support the business model.

    PROOF

    Why me for this

    I build this way myself

    This site, and the products behind it, are built with the same AI tooling. The failure modes are not theoretical to me.

    Product judgement, not just code

    Most hardening decisions are prioritisation calls. Knowing which 20% to fix first is the value, and that is a product problem.

    Founder track record

    I have taken products from idea to real customers, including Wocal, used by 300+ venues, and raised against a £2.7M pre-money valuation.

    You keep everything

    Fixed scope, full handover, no retainer trap. If you never speak to me again after launch, the engagement worked.

    Why AI-built apps break in the same places

    AI build tools optimise for producing something that runs. They are extremely good at that. They are indifferent to whether the thing that runs is safe, affordable or honest, because none of those properties are visible in the preview window.

    So the same three gaps appear again and again: data access that was never tested adversarially, AI output that was never measured against anything, and a cost curve nobody modelled. Each one is invisible until you have users, and each one is cheap to fix before you do.

    The 20% that decides whether you survive launch

    • —Can one customer reach another customer's data? Test it, do not assume it.
    • —What is your AI feature's pass rate on fifty real inputs, including the awkward ones?
    • —What does one active user cost you per month in model and infrastructure spend?
    • —When something fails at 2am, do you find out from a log or from a refund request?
    • —Which two events tell you the product is working, and are they being recorded?

    You do not need to rebuild it

    The most expensive advice a founder receives at this stage is that the prototype is throwaway. Occasionally that is true. Usually it is a quote for a rewrite of something that already works, sold on the discomfort of not understanding your own codebase.

    The prototype contains months of decisions about what the product is. Hardening keeps those and fixes the plumbing. Rebuilding throws them away and charges you to rediscover them.

    FREQUENTLY ASKED

    Lovable to production questions

    Can a Lovable app be used in production?
    Yes, with work. Lovable produces a real application on real infrastructure, so the question is not whether the platform is production-grade but whether your specific build is. In practice that means auditing data access rules, testing AI output against real inputs, modelling cost per user, adding error handling and logging, and instrumenting analytics. Most apps need three weeks of that work rather than a rebuild.
    What is the difference between a prototype and a production app?
    A prototype proves an idea can work. A production app assumes users will be careless, adversarial and numerous. The differences are access control, tested AI reliability, predictable cost, error handling, observability and a launch surface with pricing and analytics.
    How much does it cost to take a Lovable app to production?
    A two-day production readiness review is £950. A three-week hardening sprint starts at £6,000. A six-week build-and-launch engagement, where there is meaningful product work left as well as hardening, starts at £12,000.
    Do I need to rewrite my app in a different framework?
    Almost never. Rewrites cost months and usually reintroduce problems you had already solved. Rewrite when the architecture genuinely cannot support the business model, not because a codebase is unfamiliar.
    What is the biggest security risk in AI-generated apps?
    Data access rules. AI build tools frequently create tables and screens faster than they create the row-level rules that stop one user reading another user's records. It is the first thing I check and the most common thing I fix.
    Do you work with Bolt and Cursor builds too?
    Yes. The tool that generated the code barely matters — the gaps between prototype and production are the same across Lovable, Bolt, Cursor and Replit builds.

    GET IN TOUCH

    Send me your Lovable app

    Share the URL and what you are worried about. I will reply within 48 hours with an honest read on what it needs.

    Your details are used only to reply to you and are never sold or shared. See the privacy policy.

    EXPLORE NEXT

    Continue the journey

    Every stage from first idea to first revenue, mapped end to end.

    Idea to MVP

    Done-for-you six-week build from validated idea to live product.

    Read more

    AI Product Consultant

    Turning LLMs, RAG and agents into products that hold up in production.

    Read more

    MVP Cost Calculator

    Free estimate of what your MVP will cost and how long it will take.

    Read more

    The Crossley Method

    The seven-stage framework that takes an idea to first revenue.

    Read more