The code is good. There is still no pipeline, no staging, and no way back.
Claude Code writes genuinely good code and a great deal of it. What it does not do on its own is own the operational surface - environments, pipelines, monitoring, and the handful of decisions that only make sense with production traffic in view.
- Typical timeline
- 2–4 weeks for a typical project
- Pricing
- Fixed quote after a free Production Check
- Rollback
- Written, rehearsed, and executed by you before handover
What staying on Claude Code actually costs
Not a list of features you are missing. These are the four things that reliably turn into an incident, an invoice, or a lost deal.
- 01
It runs on your laptop and nowhere else
There is no pipeline, no staging environment, no rollback, and nobody has ever practised a bad deploy.
- 02
The tests assert what the code does
Generated tests describe the implementation faithfully. What they rarely cover is what the code must never do - that a user cannot read another account's rows, that a refund cannot exceed the original charge, that a retry cannot double-charge.
- 03
Fast iteration leaves real inconsistencies
Three ways to fetch data, two authentication patterns, duplicated business logic that drifts apart.
- 04
Dependencies added at speed
Packages pulled in during a session to solve one problem, some unmaintained, some carrying known advisories, none reviewed.
The sentences we hear most, and what we do about each one
These are paraphrases of things founders have actually said on scoping calls. The left column is the experience; the right column is the work.
"I can build features faster than I can deploy them"
This is the defining experience of the tool. Feature velocity is extraordinary and the deployment story has not moved since the first commit, so work piles up in a branch that is increasingly frightening to ship.
How we helpA pipeline that makes shipping boring: tests and lint on every commit, a preview environment per pull request, promotion to production on merge, and rollback in one command.
"I do not know which of this code I can trust"
The volume is the problem. Thousands of lines, most of them fine, some of them load-bearing and unreviewed, and no way to tell which is which without reading all of it.
How we helpWe read the paths that carry authorization, money, and personal data, and write tests around their invariants.
"Every time I fix something, something else breaks"
The classic symptom of duplicated logic. Two implementations of the same rule that agree on the common case and disagree on edges, so fixing one surfaces the other.
How we helpWe find the duplicates that actually cost you - usually a handful - consolidate them behind one implementation, and cover the consolidation with tests.
"I have no idea if it will survive real traffic"
It has never been under load. There are no metrics, no error tracking, and no baseline, so "will it hold" is unanswerable rather than merely unanswered.
How we helpWe load-test against realistic traffic and watch what degrades first, then fix the ceiling we find and re-test.
Component by component, before and after
Every line is a decision we will walk you through, and every one of them is written down in the handover documentation.
| Today | becomes | After the migration | Why it matters |
|---|---|---|---|
| Runs locally | Containerised, deployed from git to your infrastructure | Identical runtime in every environment. The 'works on my machine' class of bug goes away. | |
| No environments | Development, preview per pull request, staging, production | Each with its own data and its own credentials. | |
| Tests asserting the implementation | Tests asserting the invariants | Authorization, money, and data integrity. The generated tests stay; these are added. | |
| Unreviewed dependency tree | Audited, pinned, with automated advisory monitoring | A new advisory opens a pull request rather than waiting to be noticed. | |
| console.log | Structured logging, error tracking, uptime monitoring | Errors grouped by cause, alerting a person, with a trace id you can search. | |
| Deploy by hand | Deploy on merge, rollback in one command | Rehearsed with you during handover, not merely documented. |
Four phases, each with something you can hold
Scope is fixed after phase one. Every phase ends in artefacts you keep, whether or not you continue to the next.
- 013–5 days
Production Check
Free, and first. We read the paths that matter, audit the dependency tree, and load-test to find the current ceiling.
You receive
- Security and correctness review of the load-bearing paths
- Dependency audit with advisories and maintenance status
- Load test results and the first bottleneck
- Ranked plan with effort estimates
- 024–6 days
Pipeline and environments
The project gets a pipeline, preview environments, and a rollback that has been executed.
You receive
- CI running tests, lint, and type checks on every commit
- Preview environment per pull request with seeded data
- Production deploy on merge, one-command rollback
- Secrets managed per environment
- 035–10 days
Invariants and consolidation
Tests are written around authorization, money, and data integrity. The duplicated logic that actually costs you is consolidated; the rest is documented and left alone.
You receive
- Invariant test suite running in CI
- Consolidated data access and authorization
- Dependency tree pinned with automated monitoring
- 043–5 days, plus 30 days support
Deploy and instrument
Production deployment sized for the traffic measured in phase one, with monitoring, alerting, and a runbook.
You receive
- Production infrastructure sized to measured traffic
- Error tracking, uptime monitoring, structured logs, alerting
- Runbook and architecture documentation
- Post-migration load test with before and after numbers
What can go wrong, and what stops it
We would rather write these down than discover them together. Each one is a real failure mode from a real migration, with the control that prevents it.
Consolidation quietly changing behaviour
Each consolidation is covered by tests written against the existing behaviour before the change, so a difference shows up as a failing test rather than as a support ticket.
A refactor that expands to fill the schedule
We consolidate the duplicates that cost you and document the rest.
Agent-driven changes bypassing the new pipeline
Branch protection, required checks, and a documented workflow for agent-assisted changes.
Before you book the call
No - most of our own work is done this way.
No. The generated tests are fine and they stay. We add the ones that assert what must never happen, which is a much smaller set and the only one that would have caught a real incident.
Most of it, with time. The pipeline is a weekend if you have built one before, and a fortnight of frustration if you have not.
Related migrations
v0 → production
v0 produces genuinely excellent React - clean components, sensible Tailwind, real accessibility primitives. It does not produce a backend, and most v0 projects reach us as a finished interface wired to mock data.
Read the planReplit → AWS
Replit is the fastest way to get from an idea to a running app, and a genuinely bad place to leave one once people depend on it.
Read the planBolt.new → production
Bolt gets a full-stack app running in an afternoon and it is genuinely good at that. The gap between "runs in the Bolt preview" and "runs in production for paying users" is remarkably consistent across projects, which is convenient: it means the work is known before we start.
Read the plan
Thinking about moving off Claude Code?
The scoping call is free, and it ends with a straight answer about whether it is worth doing yet.