AI-built apps · Production readiness · New Zealand
Your AI-built app, made production ready.
You built it in Lovable, Bolt, v0, Replit or Cursor and it works on your screen. Now it needs real customers, real data and a go-live date. A senior engineer reads the whole thing, fixes what would hurt you and takes it live, at a fixed price and without the lecture.
The review is a fixed price, and the report is yours whether or not we do the fixing.
Built inLovableBoltv0ReplitCursor
The short answer
What production ready means for an AI-built app
An app is production ready when a stranger can use it with real data and nothing bad happens if they try to misuse it, if a server fails, or if you need last week back. AI builders such as Lovable, Bolt, v0 and Cursor are very good at the part you can see: screens, flows, a working demo. They are much weaker at the part you cannot: who may read which rows of the database, where the secret keys live, what happens to email, backups, monitoring and the hundred-user day. Those are the same jobs a senior engineer does on any system before launch. Production readiness for an AI-built app is that review and that fixing, done on the code you already have, so you keep what works and launch on a date you can promise.
What the AI builder gives you
Screens
Flows
A working demo
Where the demo stops
What a stranger with real data finds
Who may read which rows
Where the secret keys live
Email that arrives
Backups you can restore
Monitoring that reaches a person
The hundred-user day
Findings register · the entries we see most
The pitfalls we find in AI-built apps, and how we fix each one
Every review ends in a written register like this one, each item rated by how much it could hurt you. The ratings here are typical. Yours are rated against your app.
CriticalHighMedium
FindingWhat we findHow we fix it
Anyone can read the whole database
Critical
What we find
The most common and the most serious. AI builders usually ship on Supabase or Firebase, and the access rules are either switched off or written so loosely that any signed-in user, sometimes any visitor, can read or change every row. It never shows up in a demo because the demo only has your data in it.
How we fix it
Row-level security policies for each table and each role, then tested with a deliberately hostile account that tries to read what it should not.
Security that only exists in the browser
Critical
What we find
Admin pages hidden behind a menu, role checks done in the page code, prices and permissions trusted from the form. Anyone with the browser developer tools open can change all of it.
How we fix it
Every check moves to the server, and every server function confirms who is calling it before it does anything.
Secret keys in the wrong place
Critical
What we find
Service keys, payment keys and API tokens pasted into the front-end code or committed to the repository, where anyone can lift them.
How we fix it
Rotate every exposed key, move them to server-side configuration, and use separate keys for test and live so a mistake in testing cannot touch real money or real customers.
One environment for everything
High
What we find
Changes are made on the live app because there is nowhere else to make them, which makes every edit a small gamble with your customers’ data.
How we fix it
A test site with sample data that mirrors live, where every change is built, tested and reviewed first. That is how the StaffChecks portal was run, and nothing reached clients that had not passed on the test site.
No backups, and no way to undo
High
What we find
The database has never been backed up, or it has and nobody has tried a restore. Schema changes were made by hand in a dashboard, so there is no record of what changed when.
How we fix it
Scheduled backups, a restore rehearsed on the test site, and versioned migrations so the database can be rebuilt from the code.
Email that never arrives
Medium
What we find
Sign-up, password reset and notification emails sent from a shared or personal address with no domain authentication, landing in spam or nowhere.
How we fix it
A transactional email service on your own domain with SPF, DKIM and DMARC set up, proper templates, and bounces handled so you know when an address is dead.
Nobody is watching
High
What we find
The app fails quietly. Nobody is told when a server function throws, when the site goes down or when a payment webhook stops.
How we fix it
Error reporting, an uptime check, structured logs and an audit trail of who did what, with alerts that reach a person.
Dates, time zones and other quiet bugs
Medium
What we find
Times stored and shown in UTC, so anything published before 1 pm appears a day behind. Links that drop part of the address. Names with a macron that break the page they live on. None of them crash anything; all of them cost trust. We fixed the first two on a live New Zealand site in October 2026.
How we fix it
A review pass aimed at exactly this class of bug, with New Zealand dates, names and addresses in the test data.
It works for one user
Medium
What we find
The demo flies with ten records. With ten thousand, a page that fetches everything and filters in the browser takes a minute, and a loop that queries the database once per row brings the server to its knees.
How we fix it
Indexes, pagination, server-side filtering and a load test before launch rather than after.
The business does not own its own app
High
What we find
The hosting, database, domain and AI-builder account are all in one person’s name, sometimes a contractor’s.
How we fix it
Everything moved into accounts the business owns, the code in a repository you control, and a one-page map of where each piece lives and who holds the keys.
No plan for the day you go live
High
What we find
The switch from the old way to the new app is treated as flicking a setting.
How we fix it
A go-live list agreed in writing, a rehearsal of the switch against a copy of the real data, one change window, a small friendly group first, then everyone. On the StaffChecks job the rehearsal took under an hour and caught a problem that would have stopped the real switch that evening.
What you get
What the production readiness work covers
Most AI-built apps need some of this, not all of it. The review tells us which, and you get the list before any fixing starts.
01
Production readiness review
We read the whole app: every table, every role, every server function, every third-party key. You get a written findings register with each item rated by how much it could hurt you and what fixing it involves. No jargon, and nothing changed yet.
02
Security fixed first
Database rules so each person sees only their own rows, authorisation that runs on the server rather than in the browser, secrets moved out of the code, sign-in limits, two-step sign-in where the data warrants it, and an audit trail.
03
Data you can trust
Scheduled backups with a restore we have actually tested, versioned database changes instead of edits made live, and a separate test site with sample data so nothing reaches real customers until it has passed there.
04
Email, domain and the go-live
Your own sending domain with SPF, DKIM and DMARC so sign-up and reset emails arrive, DNS and hosting in accounts your business owns, error reporting and uptime checks, and a rehearsed switch-over with a date in the contract.
05
Finish worth paying for
The screens tidied so they look like a product and not a prototype, mobile checked on real phones, loading states, empty states, plain-English error messages, and the performance problems that only appear with real volumes.
06
Maintained after launch
A small monthly arrangement if you want it: dependency updates, monitoring, backups checked, and someone to call when a customer reports something. The same person who did the review, not a ticket queue.
How it works
From a link to your app, to live
Step 01
Review
Read-only access to the code, the database and the hosting. Nothing is changed. Usually days, not weeks.
Step 02
Findings and a fixed price
A written register, each item rated, then a fixed price for the fixing, so you know the whole number before anything changes.
Step 03
Fix on a test site
Security first, all on a test site with sample or anonymised data. Your live app is untouched.
Step 04
Rehearse, then go live
A rehearsal against a copy of the real data, one change window, a small friendly group first, then everyone.
Step 05
Looked after
If you want it: updates, monitoring, backups checked and a person to call. Everything stays in your accounts.
From the client
“Engaging Isaac Vicliph of Tally Digital to rebuild our client portal is one of the best decisions StaffChecks Ltd has made in nearly thirty years of business.”
Dan Thompson, CEO and Director, StaffChecks
Case study · StaffChecks client portal
The portal came to us already built by someone else.
ReviewedEvery table, role and server function
FixedSecurity first, on a test site, before anything reached clients
RehearsedThe switch-over, in under an hour, catching a problem before the real switch
DeliveredEvery client switched across on the date promised
Not answered here? Send the link to your app with your question.
Can you take over an app built in Lovable, Bolt, v0, Replit or Cursor?
Yes. Those tools produce standard code on standard services, usually React or Next.js with Supabase, Firebase or a Node backend, and we work in that stack every day. We export the code into a repository your business owns and carry on from there. You can keep using the AI builder for ideas, but once real customers are on the app, changes go through the test site.
Do I have to rebuild the app from scratch?
Almost never. The review tells you which parts are unsafe or will not scale, and those are fixed in place. A rebuild is only on the table if the foundation genuinely cannot carry the business you are planning, and we would say so in the review, before you spent anything on fixes.
What does the production readiness review involve?
Read-only access to the code, the database and the hosting. We read every table, role, server function and third-party integration, and run a set of checks against a copy of the app. You get a written findings register, each item rated by how much it could hurt you, with what fixing it involves. Nothing is changed during the review.
How long does it take to make an AI-built app production ready?
The review is usually days, not weeks. Fixing depends on what it finds. A small app with a handful of tables and an honest set of access rules can be live within a couple of weeks of the review. A client portal with roles, documents and a migration from an old system takes longer. You get a date, in writing, before work starts.
What does it cost?
The review is a fixed price. The fixing is quoted as a fixed price from the findings, so you know the whole number before anything changes. We do not charge by the hour, and the report is yours whether or not we do the fixing.
Can the app stay on Supabase, Firebase or Vercel?
Yes, and in most cases that is the right call. Those are production-grade services, and the problems are usually in how the app uses them rather than in the services themselves. We move hosting only when there is a concrete reason, such as data that must stay in a particular country or a cost that will not scale.
Is my data safe while you work on it?
We work on a copy. The review and all fixing happen on a test site with sample or anonymised data, and we touch the live database only at the rehearsed switch-over, with a backup taken first. Access is through accounts you control and can revoke the moment the work is done.
My app is also a mobile app. Does this apply?
Yes. The pitfalls are the same, because a mobile app is a front end to the same database and server functions. We review the backend the same way, and the mobile side for anything that stores secrets or trusts the device.
Will you maintain the app after it goes live?
If you want that, yes: a small monthly arrangement that covers dependency updates, monitoring, backups checked and a person to call. You are not tied to it. Everything is in your own accounts, with the code in your own repository, so you can take it anywhere.
Can you get an AI-built app through a security review or a large customer’s procurement?
That is a common reason people come to us. The findings register, the access rules, the audit trail, the backup and restore record and the environment separation are exactly what a corporate or government procurement questionnaire asks for. We write the review so you can hand it over.
Tell me what has to be live, and by when.
Send the link to your app and a sentence on who it is for. You will get a plain answer on what it takes to get there, and a fixed price for the review.
