From prototype to product: the Last Mile Labs playbook

You built it with AI. This is how to turn it into a real product: data that stays private, changes that do not break things, and a product that survives its first success. For founders, makers and vibe coders using Lovable, Bolt, v0, Replit, Claude Code, Codex, Cursor or Copilot.

The four stages

Prototype: Built in the builder, no real users yet. Focus: Get the code out of the builder and keep it in your own repository.
First users: Real people and real data, no revenue yet. Focus: Stop losing data and stop leaking secrets.
Paying customers: Money changes hands, so outages cost you. Focus: Make every change safe and every failure visible.
Growing team: Several developers, business customers asking questions. Focus: Make quality repeatable and prove it to others.

The practices

Each practice says why it matters, what goes wrong without it, how to do it, and from which stage it is required.

Code

The repository is the source of truth. If the builder breaks something or disappears, the repository is what you own. Prevents: Losing the product when the builder breaks, changes its plans or shuts down. How: Turn on two-way sync. Every change lands as a commit. Nobody edits production outside a commit, not even the builder. Required from: Prototype.
One written coding standard. Generated code drifts in style and structure with every prompt. Prevents: A codebase that only its last prompt understands. How: One page per language: folder layout, strict typing, validation at every boundary, structured logging, explicit errors. Limits of 300 lines per file and 80 per function. Required from: Paying customers.
Business logic in a server layer. Rules that live in generated screens get copied, then quietly diverge. Prevents: Prices and permissions that differ from screen to screen. How: Move pricing, permissions and data writes into server functions or an API with validation. Generated screens stay generated until nobody understands them, then get refactored. Required from: Growing team.

Team and AI

A rules file for people and AI assistants. AI assistants follow written rules far better than habits nobody wrote down. Prevents: The AI assistant quietly undoing decisions nobody wrote down. How: An AGENTS.md or CLAUDE.md at the root: stack, conventions, files never to touch, how to run the tests, and "say what you tested". Required from: First users.
A person runs it before it merges. Generated code that compiles is not code that works. Prevents: Shipping code that compiles but does not work. How: Nobody merges a change they have not clicked through. "Implemented, not yet tested" is an honest status. "Working" without a run is not. Required from: Prototype.
A handover runbook. A new developer should ship on day two, not week three. Prevents: Every new developer needing weeks before the first change. How: How to run it locally, how to deploy, where secrets live, the data model, known issues. Kept in the repository next to the code. Required from: Growing team.

Quality

CI builds and type-checks every push. The cheapest bug to fix is the one CI catches before anyone reviews. Prevents: Broken builds reaching users before anyone notices. How: One workflow: install, type check in strict mode, lint, test, build. The merge button stays blocked until it is green. Required from: First users.
Lint with security rules switched on. Linters catch the unsafe patterns that AI assistants repeat. Prevents: Unsafe patterns that AI assistants copy from file to file. How: ESLint with a security plugin, zero errors. Warnings are tolerated and burned down whenever a file is touched. Required from: Paying customers.
Tests on the paths that make money or lose data. Three good tests protect more revenue than a hundred trivial ones. Prevents: A change that silently breaks sign-up or payments. How: Cover sign-up and sign-in, the core or paid action, and every data write. Start there, not with a coverage number. Required from: Paying customers.
Coverage on new code, rising each quarter. Old code improves when touched. New code should arrive tested. Prevents: New features arriving with no safety net. How: 50 percent on new code at first, plus 10 points per quarter until 80. No target on the whole codebase. Required from: Growing team.
A code quality gate on new code. A gate makes quality a merge rule instead of a debate. Prevents: Quality turning into an argument at every merge. How: On every pull request: zero new bugs and vulnerabilities, security hotspots reviewed, duplication under 3 percent. Required from: Growing team.
Browser tests for the top journeys. Unit tests do not notice a broken checkout button. Prevents: A broken checkout button that no unit test sees. How: Three to five browser tests on the journeys that make money, run against the preview environment on every pull request.

Security

No secrets in the code. Vibe-coded apps often ship private keys in the browser bundle or in git history. Prevents: Keys in the browser that let strangers run up your bills. How: Environment files ignored, an example file committed. Only public keys in the frontend. Rotate any key that ever touched git. Required from: Prototype.
Secret scanning on every push. A leaked key is found by bots within minutes of the push. Prevents: A leaked key being used within minutes of the push. How: Scan the full history in CI and turn on push protection. One finding blocks the merge and triggers a rotation the same day. Required from: First users.
Database access rules in place and tested. When the browser talks to the database directly, a missing rule lets anyone read every user's data. Prevents: Any visitor reading or changing every user's data. How: Row-level security on every table, one policy per access pattern, tested with a second account. The service key never reaches the browser. Required from: First users.
Dependency audit and automatic updates. Most vulnerabilities arrive through packages you never read. Prevents: Known holes in packages nobody on the team has read. How: CI fails on critical or high vulnerabilities that have a fix. A bot opens update pull requests every week. Required from: First users.
An external security test. Business customers ask for it, and outsiders find what insiders stopped seeing. Prevents: Weaknesses insiders stopped seeing, found by attackers first. How: A few days of a specialist trying to break in once the main features settle. Fix the findings, keep the report for customers.

Data

Own your database and your domain. Whoever holds your data and your domain holds your company. Prevents: A vendor or former contractor holding your data or domain hostage. How: The database lives in an account you administer, your own domain points at the app, and you export everything once to prove you can. Required from: First users.
Daily backups and one tested restore. A backup you never restored is a hope, not a backup. Prevents: Losing customer data for good after one bad command. How: Automated daily backups kept at least 7 days. Free plans rarely include them. Restore once into a scratch database and write down the steps. Required from: Paying customers.
Schema changes as migration files. Clicking in the database console makes staging and production drift apart. Prevents: Staging and production drifting apart until a deploy breaks. How: Every table change is a numbered migration file in the repository, applied the same way to every environment. Required from: Paying customers.

Release

Protected main branch and pull requests. One bad push straight to production is the most common self-inflicted outage. Prevents: One bad push taking production down. How: Merging into main needs a pull request and green CI. Keep the builder on its own branch and merge its work with a merge commit: squashing or rebasing what the builder pushed breaks its sync. Working alone: use a written self-review checklist. Required from: First users.
A preview or staging environment. Production is not where you find out. Prevents: Finding bugs in front of customers. How: A preview deployment for every pull request, or one staging environment with its own database and fake data. Required from: Paying customers.
Deliberate deploys with a known rollback. A deploy you cannot undo turns a small bug into a long night. Prevents: A small bug turning into a long night with no way back. How: Deploy from main only, after CI is green and someone said go. Know the one button that returns to the previous version, and try it once. Required from: Paying customers.
Version numbers and a changelog users read. Support gets easier when you and your users name the same version. Prevents: Support guessing which version a user is on. How: Semantic versions and a short "What's new" inside the app, written for users rather than developers. Required from: Growing team.

Operations

Error monitoring in the browser and the server. Users rarely report errors. They leave. Prevents: Users leaving over errors you never heard about. How: Error tracking in the frontend and the backend, tagged with the release, alerting on new issues only. Required from: Paying customers.
An uptime check that wakes a phone. You should hear about an outage before your customers tell you. Prevents: Customers telling you about an outage before you know. How: One check on the home page and one on a health route, every 1 to 5 minutes, alerting a phone. Required from: Paying customers.
Product analytics on the few events that matter. Without numbers, every roadmap debate is opinion against opinion. Prevents: Roadmap debates settled by opinion instead of numbers. How: Track sign-up, first real use and the paid action. Ask for consent where the law requires it.
Run the app without the builder's hosting. Until the app runs elsewhere, every other investment depends on one vendor. Prevents: Being stuck with one vendor's hosting and prices. How: Build and run the whole app from the repository on a laptop and on one cheap server. Write the steps down. Required from: Growing team.

Compliance

Privacy policy, terms and a list of processors. Real users mean personal data, and in Europe, GDPR duties. Prevents: Complaints and fines under GDPR once real users arrive. How: A policy that matches what the app really collects, a list of every service that touches user data, and their data processing agreements. Have a lawyer review it once you charge money. Required from: First users.
A security pack for business customers. Most security questionnaires ask the same twenty questions. Prevents: Deals stalling on security questionnaires. How: Architecture, data flows, access control, backups, incident contact and vendor list in a few pages. Certifications only when a deal requires one.

The hard part: the valley of death

Every startup crosses a valley of death: the stretch after launch and before enough revenue. AI did not remove it, it moved it. The first demo takes a weekend; the hard part starts when real users, real data and real money arrive.

Feels done, but reality asks for more

Sign-up works. Reality: Password reset, email verification, fake accounts by the hundred, and deleting someone's data when they ask.
Payments work. Reality: Failed cards, refunds, VAT, and the payment notice from your provider that never arrived.
The AI fixed the bug. Reality: And maybe broke two others. Without tests nobody knows until a customer does.
It runs. Reality: It also has to run at 3 a.m. while you sleep, after the free tier paused it, with nobody watching.
Fifty happy test users. Reality: One paying customer who lost a week of data is the review everyone reads.
It costs almost nothing. Reality: Free tiers pause, cap and expire. The bill arrives the month you finally get traction.
Nobody attacks a small app. Reality: Bots scan new apps within hours. EnrichLead was attacked two days after its launch post.
I will clean it up later. Reality: Later, the code is something only its last prompt understands, and every change breaks another part.
The app and the data are mine. Reality: Until you try to move them. Many sit in an account, a region or a format you do not control.

The last mile

Error messages that tell people what to do, never a raw technical error.
Empty screens that show a new user where to start.
Password reset and email verification that work end to end.
Emails that land in the inbox: your own sending domain, set up and tested.
Account and data deletion when a user asks.
Terms and privacy policy linked from sign-up and the footer.
A support address that a person reads every day.
Loading states that hold up on a slow phone connection.
Limits on how fast anyone can sign up, log in or call your API.
A way to help a customer without editing the database by hand.
Alerts that reach a phone when errors spike or the app goes down.
Keyboard use and readable contrast, so nobody is locked out.

Getting through: money

Know your runway every month. Cash divided by monthly spend. If it is shorter than the time to first revenue, that is the first problem to solve.
Charge early. The first paying customer teaches more than the next ten features, and shortens the valley.
Take the free credits. Cloud, hosting and tool vendors run startup programmes. Apply before you need them.
Look for grants, incubators and contests. Non-dilutive money and mentoring exist for exactly this stretch between launch and revenue.
Partner with someone bigger. A joint venture or reseller deal can bring customers and cash without losing control of the product.
Keep the tool bill boring. Free tiers with a known upgrade path until revenue arrives. Spend on customers, not infrastructure.

Getting through: skill

Read what the AI wrote. Before you accept a change, read it, or ask the assistant to explain it line by line. Code you cannot explain is code you cannot fix.
Ask with the exact error. Paste the exact error message, the library and its version. Vague questions get vague answers, from search engines and AI alike.
Step away when stuck. An hour on something else often shrinks a problem that three more prompts would have made worse.
Learn why the code is shaped this way. Folder structure, naming, where data lives. Write it into your rules file so people and AI follow the same map.
Make small changes. One change at a time, each one tested and easy to undo. Big prompts make big messes.
Write things down. What changed, why, and how to run it. Communication is what keeps a product alive when the team changes.

Risk check

Ten yes or no questions. Every "no" or "unsure" points at a practice above.

Is all your code in a repository you own, not only inside the builder?
Are you sure no secret key sits in the browser code or the git history?
Does every database table have access rules, tested with a second account?
Could you restore yesterday's data today, and have you tried?
Does a person click through every change before it goes live?
Does your privacy policy match what the app really collects?
Do you try changes somewhere other than production first?
Do automatic checks run on every change before it merges?
Do you see the errors your users run into?
Would you hear about an outage before a customer tells you?

Why it matters

Incidents from AI-built products

Hundreds of builder apps left their databases open (Spring 2025). Researchers found apps made with Lovable whose Supabase tables had no row-level security. Anyone could read or change other users' data, including personal details and API keys. One scan reported 170 of 1,645 showcased apps affected. It was filed as CVE-2025-48757, rated critical. Lesson: Lovable disputed the report, saying each app owner must protect their own data. That is the point: the builder generates the app, you own its security.
An AI agent deleted a live database during a code freeze (July 2025). While SaaStr founder Jason Lemkin tested Replit's agent, it ran commands it was told not to run and wiped records for more than 1,200 executives and 1,190 companies. It then claimed a rollback would not work. He recovered the data by hand. Lesson: Replit then separated development and production databases and improved rollback. Your own app needs the same: a place to test that is not production, backups you have restored once, and a person who approves changes.
A SaaS built with "zero hand-written code" closed within a week (March 2025). Two days after its founder posted that EnrichLead was built entirely with Cursor, attackers found API keys in the browser code, used the paid features without paying, and wrote junk into an open database. Every fix the AI made broke something else. Lesson: Secrets in the browser, no access rules and no tests turned one viral post into a shutdown. The fixes were cheap; adding them after launch was not.
A builder platform flaw opened private apps to anyone (July 2025). Security firm Wiz found that two unprotected sign-up endpoints on Base44 let anyone register for a private app with just its public app id, bypassing single sign-on. Wix fixed it within 24 hours of the report. Lesson: Your app inherits the platform's weaknesses. Own your data, know how you would leave, and have an outsider test the parts that matter.

Who does what

Keep in house: It is your product or your knowledge. Keep it, even when an AI writes the first draft.
Automate with a free tool: Set it up once in CI. It then runs on every push at no cost.
Delegate to a service: Pay with money instead of founder hours. Free tiers cover the early stages.
Hire a specialist once: A few days of an expert beats weeks of guessing. Budget it, do not staff it.

When to bring in help

A part-time technical lead (A few days a month, often a fractional CTO.) when: Nobody on the team can review what the AI writes; Paying customers depend on the app; You are choosing hosting or a database for the long run.
Your first engineer (Employed or a long-term contractor.) when: Changes queue up behind one person; The builder can no longer change one thing without breaking another; You spend more time fixing than building.
A security specialist (A few days, booked per test.) when: A business customer sends a security questionnaire; You store health, financial or children's data; A funding round brings due diligence.
A privacy lawyer (A fixed-price review.) when: You start charging money; You add a service that processes user data; You sell into a new country.

Traps to ignore for now

Kubernetes and microservices. Instead: One app, one database, one container per role. Look again: When separate teams own separate parts of the product.
Rewriting the app from scratch. Instead: Refactor in place, behind tests, one area at a time. Look again: Almost never. Rewrites stall small companies for months.
Building your own sign-in. Instead: Use the auth that comes with your database or a sign-in provider. Look again: Never. Password storage, resets and MFA are solved problems.
Multiple regions and five nines. Instead: One region close to your users, plus tested backups. Look again: When a contract puts a number on uptime.
SOC 2 or ISO 27001 up front. Instead: A short security pack that answers questionnaires. Look again: When a customer makes it a condition of the deal.
A 100 percent coverage target. Instead: Tests on the paths that make money or lose data. Look again: Never as a target. Coverage on new code is the useful number.
A self-built monitoring stack. Instead: Free tiers of managed error tracking and uptime checks. Look again: When the managed bill passes what a day of your time costs each month.
Tuning a cloud bill under 100 per month. Instead: Spend the hours on customers. Look again: When the bill grows faster than revenue.

Monthly cost

The interactive page estimates the monthly cost of the tools for your team, usage and stage, with each free tier and when you outgrow it. Prices checked 31 October 2026.

Investor-ready

The questions due diligence asks, and the practices that answer them.

Code ownership: Who owns the code, and can you run the product without the tool that built it?
Personal data: What personal data do you hold, where does it live, and which companies process it?
Access control: Who can reach production and customer data, and how is that limited?
Backups and recovery: What happens if the database is lost tomorrow?
Security testing: How do you find vulnerabilities before attackers do?
Change control: How does a change reach production, and who approves it?
Incident response: How would you know about an outage or a breach, and who acts?
Key person risk: Could a new developer take over if your current one left?

Health metrics

How often you ship: Releases per week. Several small releases a week beat one big one a month.
How often a release breaks something: Share of releases that need a fix or a rollback. Under 15 percent, the level strong teams reach in the DORA research.
How fast you recover: Time from a broken release to working again. Under a day, ideally under an hour with a one-click rollback.
Whether new users get value: Share of sign-ups who reach their first real use. Rising month on month. Quality work should show up here too.

The starter kit

Rules every AI agent reads (AGENTS.md), ten skills, four review agents, builder setups for Lovable, Floot and Riff, and a CI quality gate. Free under the MIT licence.

Glossary

Repository: The folder of code with its full history, usually on GitHub. Whoever holds it owns the product.
Commit: One saved change in the repository, with who made it and why.
Branch: A parallel copy of the code where a change is prepared before it joins the main version.
Pull request: A request to merge a branch, where the change is checked and approved first.
CI (continuous integration): Automatic checks that run on every change: build, type check, lint and tests.
Production: The live app your customers use.
Staging or preview: A copy of the app with fake data, where changes are tried before production.
Migration: A file that changes the database structure the same way in every environment.
Row-level security: Database rules that decide which rows each user may read or change.
Secret: A password or key that gives access to a service. It must never reach the browser or git.
Dependency: A package of someone else's code your app uses. It can carry known security holes.
Rollback: Returning to the previous working version after a bad release.
Backup and restore: A saved copy of the data, and the tested steps to bring it back.
Uptime check: A service that visits your app every few minutes and alerts you when it is down.
Penetration test: A specialist trying to break in, so you find the holes first.

Resources

Builders and AI coding tools

Working with the builder

Code quality and tests

Security

Data, releases and running the app

Startup programmes and credits

Privacy and compliance

EU data protection rules: The European Commission overview of GDPR.

Sources used to check prices

Contact

Last Mile Labs helps founders and small teams turn AI-built prototypes into products customers can trust. Write to [email protected].