Prototype to production: your AI-built app works. Find out if it survives users.
You built a working app with Lovable, Bolt, Replit, Cursor or Claude Code, and people want to use it. A senior engineer reviews its security, data model, performance and deploy, and in 5 business days you get a graded report and a fix plan. $2,500 fixed, credited in full to a build started within 60 days.
A demo has to work once. A product has to work every time.
AI tools are very good at getting to a first version. The first version proves the idea, wins the meeting and sometimes signs the first customer. What it was never asked to do is keep one customer’s data away from another, recover from a failed payment, tell you it is down, or stay affordable at a thousand users.
None of that means the prototype was a mistake. It means the next stretch is engineering work of a different kind, and it is cheaper to find the gaps before launch than after the first incident. The review finds them for a fixed price, before you commit to anything larger. We wrote up the same pattern for AI pilots in the five gates between a pilot and production.
A Lovable or Bolt app on Supabase, checked where it breaks.
Four areas: security, data model, performance and deploy. Security comes first because it is the one that ends a launch. The Supabase points are cited to Supabase's own documentation.
Row-level security off, or too broad
Supabase says a table in an exposed schema without RLS is readable and writable by any role with a grant on it, and that a policy written to anon using (true) gives every unauthenticated visitor read access. We read every table and policy, flag policies that rely on user_metadata (Supabase warns against that too), and check whether one signed-in user can read or change another user’s rows.
The wrong key in the browser
The anon or publishable key is meant for client code and only reaches what Row Level Security allows. The service-role or secret key bypasses RLS, and Supabase says never to put one in a browser, a shipped app or source control. We check the built bundle, the environment files and the repository history for it.
Auth and sessions
Sign-up, sign-in, email confirmation, password reset, session expiry and refresh, and whether role checks run on the server or are only hidden in the interface.
Storage bucket permissions
Which buckets are public (anything in one is publicly accessible), and whether the policies on private buckets let a user reach only their own files.
Input validation and rate limits
Server functions and API routes that accept input without checking it, and sign-up, login or paid AI calls that anyone can repeat without a limit.
Secrets in the repository
Third-party keys (payments, email, model APIs) committed to the code or its history, or called from the browser. Anything exposed goes first in the fix plan, marked for rotation.
Schema and migrations
Whether the tables will hold up under real use, whether constraints and foreign keys exist, and whether schema changes go through migrations or are made by hand in a dashboard.
Backups
Whether backups exist, how far back they go, and whether anyone has ever restored one.
Queries and page weight
Missing indexes, queries that run once per row, and oversized responses and pages on the main paths through the app.
What it costs to run
Hosting, database and model or API spend per user, and where a cap belongs. A prototype that is cheap for ten users can be expensive at a thousand.
Environments
Whether development and production share one database or one set of keys, whether there is a staging environment, and whether a release can be rolled back.
Error monitoring and logs
Whether a failure reaches an engineer before it reaches a customer: error tracking, logs you can search, and alerts someone reads.
Who owns it
Whether the repository, hosting, database, domain and third-party accounts sit with your company or with a personal login.
A graded report and a fix plan, in five business days.
Written so your own engineers, another team or we can act on it straight away.
Graded findings
Every finding with a severity from critical to low, where it sits in the code or configuration, and the evidence for it.
A fix plan with effort
The findings in the order to fix them, each with an effort estimate, and which ones block a launch.
Keep, repair or rebuild
Our call on the codebase as a whole, with the reasons written down. The three outcomes are below.
What it is not: the review does not include fixes, which are a separate engagement quoted from the fix plan, and it is not a penetration test or a compliance certification.
Access on day one, the report by day five.
Access
You give us read access to the repository and the project's database and hosting dashboards. We make no changes.
The review
A senior engineer works through the four areas above against your real configuration, not a questionnaire.
The report
Graded findings and the fix plan, in writing. Yours to keep whether or not you work with us afterwards.
Fix it, with anyone
Fix it yourself, with another team, or with us. If you start a build with us within 60 days, the $2,500 is credited in full.
The call the report ends in.
Every codebase lands in one of three groups. You hear which, and why, before you have committed to more than the review.
Keep and harden
The data model is sound, the code is readable and the gaps are the usual ones: access rules, tests, error handling, deployment.
Most of the work is additive. This is the common case when the prototype was built carefully.
Repair
The product works but one layer does not hold: usually the schema, the auth model or a tangle of duplicated logic.
We replace that layer and keep the rest. Users see the same product.
Rebuild
Fixing it would cost more than writing it again: no consistent structure, no safe way to change one part without breaking another.
The report says so, with the reasoning written down. The prototype becomes the specification, which is still worth a great deal.
A fixed price to find out. A monthly rate to fix it.
The review has one price, because its scope is fixed. Fixing has a published monthly rate, because nobody can price fixes to a codebase they have not read.
5 business days, a graded report and a fix plan. Credited in full to a build with us started within 60 days. Fixes are quoted separately, from the plan.
An embedded team works through the fix plan in your repository, priced by role and seniority. Two engineers come to $6,000–$15,000 a month. 2–4 week trial, no lock-in, 30-day notice. First pull requests by Day 5.
Only one workflow to fix?
A single automation, scoped, built and deployed for a fixed price. A review and a team would be the wrong size.
AI features that need running after launch?
Monitoring, eval regressions and model-change response on a retainer. See what the retainer covers.
What we can show you, and what we cannot yet.
Joining a codebase that already exists
A Series B HR-tech company embedded a three-person Gigabit pod in a live product with a seven-engineer team. First pull requests in 5 days, and sprint velocity went from 34 to 78 points. Read the case study.
Shipping a first product to paying customers
A logistics SaaS went from pitch deck to 14 paying customers in 11 weeks for $48,000, with zero critical bugs at launch and 78% automated test coverage. Read the case study.
We do not yet have a published case study of reviewing or taking over an app that was built with an AI builder. The two above show the parts the work is made of: working inside someone else’s code, and getting a new product to a launch that holds. When the first one is public it will be linked here.
We are not a clean-up crew that bills by the hour to tidy code forever. The review has a fixed price and ends in a graded report, the fix plan says what each fix will take, and the work ends in a launch or an honest recommendation to rebuild.
Questions founders ask first
How much does a security review of a Lovable or Bolt app cost?
At Gigabit, the Prototype Production Review is $2,500 fixed and takes 5 business days. It covers security (including Supabase row-level security, exposed keys and auth), the data model, performance and deploy, and you get a graded report and a fix plan. The fee is credited in full to a build with us started within 60 days. Fixes are not included: they are a separate engagement, quoted from the fix plan.
What does the review check in a Supabase app?
That row-level security is on for every table in an exposed schema and that no policy is broader than it should be; that the service-role or secret key is not in the browser, the bundle or the repository history; sign-up, sign-in and session handling; storage bucket permissions; input validation and rate limits; secrets committed to the code; backups; error monitoring; and whether development and production are separated, with a release you can roll back.
Can an app built with AI tools go to production?
Often, yes. A prototype built with an AI app builder or a coding assistant usually proves the idea and the interface. What it tends to lack is what a demo never needs: access control that holds, tests, error handling, monitoring, a rollback path and a cost ceiling. Those can be added to a sound codebase. The review tells you whether yours is one.
What happens after the review?
You decide. The report and fix plan are yours, so you can fix the app yourself, hand it to another team, or have us do it. With us, fixing and launching is delivered by an embedded team at $3,000–$7,500 per engineer per month, with a 2–4 week trial and no lock-in; two engineers come to $6,000–$15,000 a month. A build with us started within 60 days gets the $2,500 back as a credit.
How much does it cost to make an AI-built prototype production-ready?
It starts with the $2,500 review, because nobody can price fixes to a codebase they have not read. The fix plan then gives each finding an effort estimate, so the cost of the rest is a number you can check before you commit. If we do the work, it is priced as an embedded team at $3,000–$7,500 per engineer per month.
Will you rewrite my app or keep the code?
We keep what holds. The report puts the codebase into one of three groups: keep and harden, repair one layer, or rebuild. If the answer is rebuild, the report says so in writing, with the reasons. We do not start a rewrite quietly.
Which tools' output do you work with?
Any that produce a normal codebase you can export: apps started in Lovable, Bolt, Replit or v0, and code written with Cursor, Claude Code, Copilot or similar assistants. What matters is the stack underneath, typically React or Next.js with a hosted database such as Supabase, and whether you can give us the repository.
Who owns the code and the accounts?
You do. The review only needs read access, and any later work happens in your repository and your cloud accounts. Part of the review is checking that the repository, hosting, database, domain and third-party accounts sit with your company and not with a personal login.
What if I only need one automation fixed, not a whole product?
Then a review and a team are the wrong size. A single, well-defined workflow is an AI Quick Win Sprint: $8,000 fixed, 3 weeks, built and deployed.
From the field notes
The security checklist to run before real users reach your AI-built app
Claude Code pricing in 2026: every plan, API costs and three worked examples
Why your AI pilot never reached production — and the five gates that get it there
Why AI systems break after launch — and what "operating" one means
What does an AI MVP actually cost? A build budget breakdown
Vendor Roulette: why switching AI vendors keeps you at square one
Find out what stands between your prototype and a launch.
Tell us what you built and what it runs on. In 5 business days you get a graded report and a fix plan, for $2,500 fixed, credited in full to a build with us within 60 days.