Production Readiness
You shipped fast, users showed up, and now the cracks are showing: deploys are scary, nothing is tested, and nobody knows what happens if the database dies. In one to two weeks I make your system boring. Real tests, migrations, monitoring, backups you have actually restored from, and a written handover so your team can run it without me.
- Price
- On request
- Duration
- 1–2 weeks
- Category
- Core
- Deliverables
- 8
Your product works. Now make it survive.
Getting to a working product is cheap now. Keeping it alive is not. Most systems that break in production were never wrong, they were just never finished: no test that catches the regression, no migration path, no alert when the queue backs up, no restore drill for the backup nobody verified. That gap is invisible until you have real users, and by then it is expensive and stressful. This is the unglamorous work that decides whether you still have a product in year three, and it is exactly what I have done across five of my own production systems.
The full scope.
Production audit: what actually breaks, ranked by how likely and how bad
A real test suite against a real database, no mocked-out persistence
Database migrations with a rollback path, not hand-edited schemas
Monitoring and alerting that pages a human only when it should
Backups plus a restore you have watched work end to end
CI/CD on every push: lint, type-check, test, build, deploy
Secrets out of the repo and into something you can rotate
Written handover so your team owns it, no dependency on me
From kickoff to ship.
Days 1–3, Triage: I read the code, run it, break it on purpose, and hand you a ranked list of what will fail first. You get this even if we stop here.
Days 4–8, Fix: highest-risk items first. Tests, migrations, monitoring, backups, pipeline. You watch each one land in a staging environment.
Days 9–10, Handover: runbook, architecture notes, and a walkthrough recording. Your team can operate the system without calling me.
You should book this if…
Founders whose AI-assisted build found real users and now falls over
Seed-stage teams with a prototype serving production traffic
Companies that inherited a system nobody on the current team wrote
German SMEs can often fund part of this
This kind of engagement is frequently eligible for BAFA consulting funding (up to 50%) and, in NRW, the MID programme. Public funding runs through 2026. You apply, eligibility depends on your company; I'll point you to the right programme on the call.
01My product was built quickly with AI assistance and now it keeps breaking. Can you fix it?
Yes, that is the most common reason people book this. Generating a working product got easy; keeping it running under real traffic did not. I do not judge how the code got written, I care about what it takes to make it survive. The audit in the first three days tells you honestly whether it needs hardening or a deeper rebuild, and you keep that assessment either way.
02What does production ready actually mean?
Concretely: you can deploy on a Friday without fear, a test fails before your users do, the database can be migrated and rolled back, an alert reaches a human when something is genuinely wrong, and you have restored from a backup at least once to prove it works. If any of those is missing, the system is running on luck.
03Do you rewrite my code?
Almost never. Rewrites are slow, risky, and usually unnecessary. I add the missing safety layers around what you have, fix the specific things most likely to break, and leave the product recognisable to the people who built it. If a rewrite genuinely is the right call, I will tell you that in the audit rather than quietly billing for one.
04How long does it take and what does it cost?
One to two weeks. The triage phase is the first three days, so you get the ranked risk list early. Larger or more tangled systems are scoped after the audit, and I tell you the number before the work continues.
05Do you work with my existing stack?
Yes. I work day to day in Kotlin/Spring Boot, TypeScript/Next.js, PostgreSQL, Docker, and Kubernetes, and I have shipped production systems on all of them. The reliability work itself is stack-agnostic: tests, migrations, monitoring, backups, and deployment discipline look the same everywhere.
Still unsure whether this is the right shape of work?
Book a call