Can a vibe-coded app run in production?

Often, yes. The code an AI tool writes is rarely the problem; what is missing is everything around it: secrets sitting in the repository, a database that has never been backed up, a schema without migrations, failures that reach no one, a deployment only the builder remembers. Those are the things the takeover reads and the stabilization sprint puts right. Whether this particular app can run in production is what the week decides.

What does the takeover actually check?

The repository, the hosting, the environment and secrets, the database and its backups, every integration and API key, how the system deploys and how it recovers. It ends with monitoring in place, the deployment documented, a recovery procedure written and the critical risks named, and one of three answers.

What if you cannot take it over?

Then the report says so, and why. Either it names a stabilization sprint with its scope, or it says that replacing the system is cheaper than repairing it and what we would replace it with. You keep the report either way; a takeover that ends in a no still tells you what you have.

What is inside the monthly fee, and what is billed separately?

The monthly fee covers monitoring, backup verification, incident response within the agreed window, dependency and model updates, security patches, a small change budget and a health report. New functionality is billed separately, scoped and quoted on its own, so the month stays predictable.

Do you need to have built it?

No. Care takes over systems built in Lovable, Bolt, Replit, Cursor and Claude Code, n8n and Make workflows, and whatever a freelancer or a previous contractor left behind. What we built ourselves enters the same envelope on the same terms.

How is this different from a vibe coding cleanup service?

A cleanup is a project: somebody refactors the code and hands it back, and the next incident is yours again. Care is responsibility. The cleanup happens where the takeover says it must, and then somebody stays on the system, watching it, updating it, restoring it, for as long as you want them to.

Can we take it in-house later?

Yes, and it is a supported outcome rather than a penalty. Everything we add — the deployment, the runbook, the monitoring, the backups — is documented and lives in your accounts. Your own IT picks up the documentation and the alerts and carries on.

The takeover is a week priced from a floor that depends on how much there is to read; the figure is at the top of this page. Stabilization, where needed, is quoted in the takeover report. The monthly fee comes in the three sizes above, and new functionality is quoted separately.

All service tracks

You build it. We keep it running.

Managed care for systems built with AI tools, or by somebody who has since left: Lovable, Bolt, Replit, Cursor, Claude Code, n8n and Make workflows, a freelancer's repository. We read the system, make it safe to run, and take responsibility for it running.

Fee: from $900
Length: 1wk

What the engagement covers

Scope of work6

01Takeover: the readingWe get the repository and the hosting, stand the system up, and go through it in order: environment and secrets, database, backups, integrations, how it deploys, how it recovers. A week, and a report.
02One of three answersWe can run it as it is; we can run it after a stabilization sprint, with the scope named; or it is cheaper to replace, and we say what with. Whichever it is, the report is yours.
03Stabilization, only where neededDeployment that reproduces, migrations, backups that restore, secrets out of the code, logs somebody can read, the obvious holes closed. There are no new features in it, only the minimum before somebody is on call.
04Monitoring and the runbookAlerting on the things that break, a documented deployment and a recovery procedure, written once at the takeover and kept current while we run it.
05The monthly envelopeIncident response inside an agreed window, dependency and model updates, security patches, a small change budget and a health report every month. Agreed per system in the statement of work.
06Changes, and the way outNew functionality is scoped and quoted separately, never absorbed into the month. Everything stays yours: code, accounts, documentation. Taking it in-house later is a supported outcome.

What you get out of it

Somebody who understands how the system is built, sees when it breaks and can put it back
A yes or a no on responsibility in a week, before any monthly commitment
One standard runtime across everything you built: deployment, logs, secrets, backups, alerts
You own the code, the accounts and the documentation, and leave whenever you like

Where this sits9

Visibility AnalyzerfreeFree
Free AI DiagnosticfreeFree
INITE Care$750/mo
System Takeoveryou are herefrom $900
Visibility Upkeep$900/mo
Visibility Sprint$1,500
Stabilization Sprintfrom $1,800
Discovery Sprint$2,500
Implementation Sprintfrom $5,000

Three sizes of Care

The takeover report says which one a system needs. What moves between them is the scope of the envelope and the change budget; what stays the same is that everything is yours.

Per month3

01Essential$750/moOne internal tool the team relies onMonitoring, alerting and backup checks · Incident response in the SLA severity bands, business hours · Dependency, model and API updates · Health report every month
02Business$1,200/moA system a business process runs onEverything in Essential · Security patches on release, tested first · A small monthly change budget · A quarterly review with the process owner
03Criticalon requestSeveral systems, or one the business cannot pauseEverything in Business · Several systems in one envelope · Response window and escalation path set across all your systems · Scoped with you, not from a list

Two ways to keep it running

You can keep it yourself; a system that works today will mostly work tomorrow. The question is who notices when it does not, and what they have to know to put it back.

Keep it yourself

Write down how it deploys and where every secret lives, before the person who built it forgets or leaves
Set up backups and restore one, so the first restore is not the one that matters
Put alerting on the API keys, the webhooks and the model version, because each will change without asking
And keep somebody who can read the code the week something breaks at nine on a Friday

System Takeover

Hand it to us

A week of reading and a report that says whether we can be responsible for it, and what it would take
The repairs named in that report, and nothing else, before we go on call
A monthly envelope with a response window, agreed per system, and a health report you can read

Not for you if

Where this is the wrong buy4

There is no system yet. Care takes over what exists; a problem without a system is a build, and a build starts with Discovery.
You want new features inside the monthly fee. The envelope covers running the system; changes are scoped and quoted separately, so the month stays a month.
You need a response at any hour. The window is agreed per system and it is business hours; we would rather say so than promise a pager we do not run.
You would rather be told it is fine. A takeover ends in one of three sentences, and one of them is that replacing it is cheaper.

Three systems, from where they arrive to where they stand

The same sequence every time, on the kinds of system that arrive most often: read first, then decide, repair where it is needed, and run. What changes between them is which of the three answers the reading ends in.

A CRM built in Lovable4

The owner built it over two weekends. Sales lives in it now: sixty deals, three people, one Supabase behind it, and nobody has looked at the code since.

01We get the repository and the Supabase project, stand the system up on our side and read how it deploys.
02The reading finds the service key in the client bundle and no backup schedule. Both are stabilization, and both are named with a price.
03Two weeks of stabilization move the secrets, turn row-level security on, schedule nightly backups with one restore rehearsed, and put alerting on the auth and the database.
04The system enters Care at Essential. The monthly report shows uptime, restores tested and what changed.
Where it endsTwo months in, sales wants WhatsApp and the ERP wired in. That is a change, scoped and quoted on its own, and it goes back into Care when it ships.

Fourteen n8n workflows4

An operations manager built them one at a time over a year. Nobody knows which ones still run, which are duplicates, and which one sends the invoices.

01We export every workflow, map what triggers each one and what it writes to, and mark the ones that have not run in ninety days.
02The reading finds five live ones the business depends on, six dead and three duplicates of the live ones. One set of credentials is shared across all fourteen.
03Stabilization keeps the five, folds the three duplicates into them, splits the credentials per workflow, adds error paths, retains execution logs, and archives the six dead ones with a note.
04The five enter Care at Business: an invoice pipeline needs a shorter window than a Slack digest.
Where it endsA provider changes its webhook format on a Tuesday. That is an incident inside the envelope, not a change: repaired within the window and written up in the month's report.

An agent from a previous contractor4

A support agent built on a model API, handed over as a zip file and a Vercel login. The contractor has stopped answering, and the model it was tuned for is being retired.

01We stand it up, read the prompts and the tools it may call, and trace where a conversation goes when the model cannot answer.
02The reading finds that nothing evaluates the agent, that its decisions are recorded nowhere, and that the model name is hard-coded with a retirement date.
03Stabilization builds an evaluation set from real transcripts, logs every decision with its reason, moves the model behind a config, and tests the replacement against the set.
04It enters Care. The model update, when it comes, is a scheduled change tested against the same set rather than a surprise.
Where it endsThe reading can end the other way. If the agent decides money and complaints on its own and there is no clean line to a person, replacing it is cheaper than repairing it, and the report says so.

Asked before anyone buys this

Can a vibe-coded app run in production?: Often, yes. The code an AI tool writes is rarely the problem; what is missing is everything around it: secrets sitting in the repository, a database that has never been backed up, a schema without migrations, failures that reach no one, a deployment only the builder remembers. Those are the things the takeover reads and the stabilization sprint puts right. Whether this particular app can run in production is what the week decides.
What does the takeover actually check?: The repository, the hosting, the environment and secrets, the database and its backups, every integration and API key, how the system deploys and how it recovers. It ends with monitoring in place, the deployment documented, a recovery procedure written and the critical risks named, and one of three answers.
What if you cannot take it over?: Then the report says so, and why. Either it names a stabilization sprint with its scope, or it says that replacing the system is cheaper than repairing it and what we would replace it with. You keep the report either way; a takeover that ends in a no still tells you what you have.
What is inside the monthly fee, and what is billed separately?: The monthly fee covers monitoring, backup verification, incident response within the agreed window, dependency and model updates, security patches, a small change budget and a health report. New functionality is billed separately, scoped and quoted on its own, so the month stays predictable.
Do you need to have built it?: No. Care takes over systems built in Lovable, Bolt, Replit, Cursor and Claude Code, n8n and Make workflows, and whatever a freelancer or a previous contractor left behind. What we built ourselves enters the same envelope on the same terms.
How is this different from a vibe coding cleanup service?: A cleanup is a project: somebody refactors the code and hands it back, and the next incident is yours again. Care is responsibility. The cleanup happens where the takeover says it must, and then somebody stays on the system, watching it, updating it, restoring it, for as long as you want them to.
Can we take it in-house later?: Yes, and it is a supported outcome rather than a penalty. Everything we add — the deployment, the runbook, the monitoring, the backups — is documented and lives in your accounts. Your own IT picks up the documentation and the alerts and carries on.
What does it cost?: The takeover is a week priced from a floor that depends on how much there is to read; the figure is at the top of this page. Stabilization, where needed, is quoted in the takeover report. The monthly fee comes in the three sizes above, and new functionality is quoted separately.

Next step

Show us the system

Thirty minutes about your system: what it is, what it runs on and what it does for the business. If we take it on, a week with the code follows, and one of three answers: as it is, after stabilization, or replace.

Put a time in the calendar

Thirty minutes, free. The takeover is what the call is about.

Fee: from $900
Length: 1 week

Ends in one of three answers: we run it as it is, we run it after a stabilization sprint, or it is cheaper to replace. The report is yours either way.

Or see what Care costs a month