Be honest about what you have
Your vibe-coded prototype is valuable. It proves the idea works. It shows you what the UI should feel like. It may already have real users poking at it. Don't throw it away — but don't pretend it's production code either.
Here is what it almost certainly has: no clear separation between presentation, business logic, and data access. Dependencies pinned to whatever version the model happened to know the day it generated the code — or not pinned at all. No tests. Error handling that covers the happy path and nothing else. Database queries inside UI components. Secrets in environment variables that haven't been rotated since the project started. A git history that is an undo stack.
None of this is your fault. The tools that generated it optimise for speed-to-demo. That was the right tradeoff when you were validating the idea. The tradeoff that served you then is the liability that will hurt you the night your first paying customer hits an error case the prototype never handled. The moment of pain is precise and it is coming. This page describes how to get ahead of it.
Step 1 — The audit
Before we touch a line of code, we read what you have. The developer agent scans your codebase and produces a written report: what's there, what's missing, what's risky, and in what order it needs to be addressed.
The audit covers: dependency versions — are they pinned, and do any appear in the GitHub Advisory Database; architecture — is there any separation between UI, business logic, and data access; security surface — exposed secrets, missing or incomplete authorization, injection risks, CORS policy; test coverage — almost certainly zero; and deployment — where does it run, who controls it, and can you reproduce the deployment tomorrow from the repository alone.
The lawyer agent runs in parallel: SPDX license identifiers for every dependency, terms-of-service compliance for any third-party APIs, and regulatory surface if the application handles EU resident data or payment card data. A project that needs GDPR data-residency answers or PCI DSS scope reduction cannot afford to discover that in month three.
You receive the report in writing. It names exactly what needs fixing and in what order. A human engineer reads it before it leaves our hands. This takes 1–2 days.
Step 2 — Architecture
We design the target architecture before writing a line of code. This is the step vibe-coding structurally skips, and it is the step that determines whether the codebase is still workable in six months when the original context is gone.
For a typical early-stage application this means: an API layer separated from the frontend, with documented contracts. Business logic in its own layer, testable without a browser or a running database. Data access behind a clean interface — so that changing your database doesn't require rewriting your application logic. Configuration externalized and validated at startup, not scattered through the call stack. Error handling consistent and observable, not silently swallowed.
We don't over-architect. A seed-stage product doesn't need microservices or event sourcing. It needs enough structure that two engineers can work on it at the same time without stepping on each other, and that a new engineer can read it without first asking the original author to explain the layout. The architecture document is reviewed and signed by a human engineer before any code changes start.
Step 3 — Rewrite vs. rescue
Sometimes we can rescue the existing code. If the prototype is under roughly 3,000 lines, uses a reasonable stack, and has a clear UI that maps to real features, we refactor it into the target architecture. Your user flows stay. Your UI stays. The internals get rebuilt properly.
Sometimes it is faster to rewrite. If the prototype is a single 8,000-line file with inline everything — queries in components, business rules in route handlers, configuration hardcoded throughout — untangling it takes longer than rebuilding from scratch using the prototype as a specification. We tell you honestly which path is faster, and we tell you before we start work, not after the first week of billing.
Either way, the prototype keeps running. You do not lose access to it while we work. When the production version is ready, we cut over. The decision between rewrite and rescue is a technical one with a cost implication, and a named engineer owns it.
Step 4 — Tests and verification
Every function gets tests. Not aspirational coverage targets — concrete tests that verify the business logic actually does what it is supposed to do. The developer agent writes these alongside the code, not as a cleanup pass afterward.
The verification pipeline runs on every push: tests must pass before a change merges; dependency versions are pinned and checked against the GitHub Advisory Database on every run; the provenance trail at /launches/<date>/<sha> records what changed, what was checked, and who signed it. The trail is re-runnable — you can replay it against the current world months later and detect drift.
This is what changes six months from now. When you change something, the tests tell you whether you broke something else. When a dependency updates, the pipeline tells you whether it is safe. When an investor asks how do you know this works, the answer is a URL and a human signature, not a feeling.
Step 5 — Real infrastructure
Your prototype probably runs on Vercel, Netlify, or Lovable's built-in hosting. Fine for demos. For production you need isolation from other tenants, observability you control, a backup regime you can describe to an auditor, and a deployment process that is reproducible from the repository.
The DevOps agent provisions your environment: isolated Kubernetes — your own namespace, or a dedicated cluster if your compliance posture or load requires it. GitOps deployment: push to main, the test suite runs, and the manifests apply. Postgres with streaming replication and daily backups managed by CNPG. Valkey for caching. MinIO for file storage. Grafana for logs, metrics, and alerting. TLS certificates provisioned and rotated automatically. From $59/month.
You bring your domain name. We point it at your cluster. From that point on, git push is the deployment step. No manual actions. No dashboards to click through. Infrastructure that behaves like infrastructure should — and that you can describe accurately when the security questionnaire arrives.
Step 6 — Deploy and monitor
The first deploy is a real deploy. The CI pipeline runs the tests, the DevOps agent applies the Kubernetes manifests, the application comes up in your namespace, and the monitoring stack starts watching. Not a prayer. Not "seems to be working." A passing test suite, a running deployment, and alerts configured before anyone else uses the application.
You get alerts when something is wrong — not a blank page and a Slack message from a user. Logs are searchable in Grafana. Metrics are graphed. If the application crashes at 2am, the trail tells you what happened and when. A human engineer reviews the first deployment and signs the provenance record.
From here the agents continue working. The developer agent handles feature work and bug fixes through the same verification pipeline. The lawyer agent watches for license changes and compliance drift. The DevOps agent manages infrastructure. A human engineer reviews and signs every merge. The trail grows. It remains re-runnable.
What it costs
Infrastructure starts at $59/month for a development or shared namespace and scales to $649/month for a dedicated production cluster with 64 GB RAM, high-availability Postgres, and the full service catalogue.
The production-readiness engagement — audit, architecture, rewrite or rescue, tests, and infrastructure setup — is a $2,500 fixed-price launch. A senior engineer scopes it, reviews it, and signs it. You know the cost before we start. No time-and-materials billing that expands after you're committed.
After launch, the agents handle ongoing development at your infrastructure tier. All specialist agents, CI/CD, GitOps, and human review on every merge are included. Cancel any time, in-app. Annual plans refunded in the first 30 days, no questions.
The cheapest time to build it right is before your first real users find the bugs the prototype is hiding.