Most advice about building an app with AI stops at the demo. A prompt, a screen recording, a working-looking prototype. This guide is about the part after that: taking a design all the way to a production-ready product that real people pay for, without an engineering team.
The example is PATE, a bill-splitting app built with Lovable and Claude. I designed it in Figma in March 2024 and built it on my own over fourteen months. Claude ran the project. Lovable produced the code. I made every decision. Here is how it worked, what the stack looked like, and where the time really went.
The short version
One person, every role. Product design, research, front end, back end, QA, security review, compliance, marketing site and support.
2.5 years from concept to launch, with 14 months of active build from June 2025 to launch-ready in August 2026.
70+ documented sessions. Every build day was written up and fed back into project knowledge.
A production stack, owned outright: Lovable, Supabase, Azure Document Intelligence, Stripe, and a Progressive Web App.
Zero numbers typed by users. That was the one rule the whole product had to keep.
What PATE is, and why it was hard
PATE has one rule: nobody ever types a number. You photograph the receipt, tap who had what, and everyone gets their exact amount. The AI reads the bill. People only answer the one question they can actually answer, which is who ate the chips.
Every other splitter still asks you to type amounts and divides the total. But a bill is a list of items, and the fair split lives in the items. Splitting evenly is how the person who had a starter, a main and two cocktails ends up subsidised by the one who had soup.
That created the design tension that ran through the whole build. Remove all the effort and you also remove the checking. So trust had to be designed in somewhere else.
From Figma to app: designed before the tools existed
When I designed PATE in March 2024, there was no realistic way for one designer to build it. Claude Projects arrived that June, bringing persistent project knowledge. Lovable launched publicly at the end of the year. I started building in June 2025, as the tools grew up around the design.
The bet, in one line: get the design right early, and let the tooling catch up to it. If you are still at that first stage, How to Use Figma to Design an App covers it properly.
How Claude and Lovable work together: one loop, run seventy times
The whole build was a single loop, repeated.
Decide (me). The product call: what to build, what to cut, what “done” means.
Specify (Claude). The decision becomes a written spec and prompt, checked against the project memory of everything built so far.
Build (Lovable). The spec becomes working code: a React front end and a Supabase back end, deployed to the live project.
Test (me). Every change tested on a real phone. Behaviour checked, not confirmations. Findings written up.
Each session’s report went back into project knowledge, so the next spec started smarter. This is context engineering in practice, and it is the difference between this and prompting and hoping. Vibe Coding for Designers explains why that judgement matters.
One standing instruction was written into the project early and applied to every prompt:
“PATE is a commercial production application intended for real paying users at scale… never introduce dependencies on trial services or free tiers that real traffic could exhaust.”
It is the difference between a demo and a product.
The stack: Lovable, Supabase and Stripe, boring on purpose
Every service in the chain is production-grade and owned directly. The interesting part is not the technology list. It is that a designer chose it, wired it, and shipped on it.
Lovable, the build layer. React, Vite, Tailwind and shadcn/ui, produced from written specs. If you are new to it, start with How to Use Lovable AI.
Supabase, the back end. Postgres with row-level security on every table, plus Auth, Storage and Edge Functions.
Azure Document Intelligence, the reading. Receipt OCR, chosen after a head-to-head test on the same Spanish receipt: 98%+ accuracy against a rival’s 60–70%. The decision took an afternoon.
Stripe, the money. Subscriptions and premium gating, with the edge cases fixed before launch, not after.
Progressive Web App, the distribution. Installable on iOS and Android. No app store sits between a user and the product.
What the research kept saying
The discovery work started with the original 2024 concept: interviews, a competitor review, and a lot of watching people fail to split bills gracefully. Four findings did most of the shaping.
The pain isn’t the maths. It’s the moment. Anyone can divide by six. Nobody wants to at 11pm with a waiter watching. So capture is photo-first, with nothing to set up.
“Fair” means itemised, not divided. Even splits breed quiet resentment. So assignment is by item, and shared dishes divide between whoever shared them.
One organiser always carries the admin. So every flow is built organiser-first: their friends, their groups, their one-tap re-use.
Friends won’t install an app to pay you back. So claim links open in any browser. No account, no download, no login.
Designing trust into an AI product
The product is four screens: scan, verify, assign, settle. The second one is where the trust lives.
Verification is the product. The AI will sometimes be wrong, so the design assumes it. Every scan lands on an editable list before any splitting happens. Users correct the machine. The machine never corrects the users.
Honest beats smooth. When the items don’t add up to the scanned total, the screen says so plainly rather than hiding it.
Waiting can be designed. OCR takes 15 to 25 seconds. The flow was rebuilt so the upload happens instantly and a skeleton of the real layout renders while the reading happens in the background. Same wait. Feels like half.
From vibe coding to production-ready: the unglamorous 40%
Roughly two of every five sessions went on work no user will ever screenshot. This is the part most case studies skip, and the part that makes the product real.
Security. Row-level security on every table, so users only ever see their own bills. A security review of my own design found that claims could be read or edited by guessing a name. It was fixed with a secret token per claim, checked server-side.
Money. Stripe prepared for live mode, with subscription states handled before launch.
Compliance. Privacy policy, terms, signup consent, cookie notice and full account deletion. GDPR treated as a design constraint from the start, not a retrofit.
Distribution. A device-aware install flow for iOS and Android that shows once and never nags.
By the end: 60 unit tests across five suites, every migration reviewed before approval, and a security scan graded A with zero critical findings.
Testing on real receipts, and deferring the launch
In August 2026 I ran a structured test campaign: fourteen real receipts across US, UK and Spanish formats. The OCR held up on every well-lit capture. The faults were ours. Our own code was discarding values that had been read correctly.
So I built an admin diagnostics tab that logs every scan. Before it existed, failures were invisible. Within a day of logging existing, it surfaced 108 silent rate-limit refusals over 30 days and an infinite retry loop that hung without a trace.
The same telemetry changed the launch date. By 13 August, 264 of the month’s 500 OCR pages were already spent. Launching on a half-empty quota risked the product failing on its best-ever traffic day, so the Product Hunt launch moved to September. Deferring your own launch on the strength of your own telemetry is the least exciting decision in the project. It is also the one I’d defend hardest.
Five lessons from building a production app with AI
Verify behaviour, never confirmations. The build tool twice reported changes it hadn’t fully made. Both were caught by checking the data, not by asking the tool to mark its own homework.
The newest tool gets the blame. The logs disagree. When scans failed, instinct said the OCR was flaky. The evidence said our code was at fault.
Working is not the same as right. A feature can function and still be the wrong behaviour. Reworking a small thing at once is cheaper than living with it.
Name the risk number out loud. A fix made two days before launch testing got rated 2/10 risk, with reasons written down. Saying the number turns “should be fine” into an actual decision.
The AI wrote every line of code. It made none of the calls. What to build, what to cut, when to defer a launch. The hands were automated. The judgement wasn’t.
FAQ
Can a designer really ship a production app without engineers?
Yes, but not by prompting alone. The code was the easy part to delegate. The work was specifying precisely, testing on real devices, and making the product calls. That is a method you can learn.
How long does it take?
PATE took fourteen months of active build, because it handles real money, real accounts and real data. A simpler first product is far quicker. How to Build an App with AI Without Coding sets realistic expectations for a first build.
Which tools do I need?
PATE used Figma for the design, Claude for project memory and specs, and Lovable for the build, on top of Supabase and Stripe. For the wider route from design file to working code, read the complete guide to converting Figma to code.
What is the hardest part?
Everything users never see: security, payments, compliance and diagnostics. Budget for it. It was about 40% of the work here.
Can Claude and Lovable work together?
Yes, and they suit different jobs. Claude held the project memory, wrote the specs and checked each decision against everything built so far. Lovable turned each spec into working code and deployed it. Keeping those roles separate is what kept the build under control.
Are apps built with Lovable production-ready?
They can be, but not by default. PATE needed row-level security, payment edge cases, legal pages, real-device testing and diagnostics before it was safe to charge money. Lovable writes the code. Making it production-ready is still your job.
Where this fits in the bigger picture
The Figma file was never the deliverable. Designers have always been able to see the product. Now we can ship it. The tools will keep improving. The judgement is still the job.
You can see the product side of this story in the PATE case study. If you want to learn the method behind it, the Flux Coding Framework teaches it end to end.
And if you would rather have help applying this inside your team, I offer AI development training and product design consulting.