Most engagements start the same way: a working product, real users, a growing revenue line, and a codebase that feels like it's held together with string. The founders know they need to "clean it up" but every week they spend cleaning is a week they're not shipping.
The first 30 days are about buying time without losing speed.
Week 1 — Audit, not opinions
We read the code. We deploy it ourselves from a clean machine. We look at every dashboard you have and every one you don't. We ask what has woken anyone up in the last 90 days.
By the end of week one you have a written document: what is actually risky, what merely looks risky, and what we'd change first. No JIRA board, no architecture diagram for its own sake — just the list in priority order.
Weeks 2–3 — Fix the breaking points
Not the cleanup. The breaking points. Usually this is 3–5 things:
- A secret in the wrong place
- An unbounded query that will eventually take the site down
- A deploy process that nobody can reproduce
- A webhook handler that silently drops on failure
- Zero observability on the thing that makes money
We fix those. In production. With a paper trail.
Week 4 — Reliability, documented
Runbooks for the incidents we now expect. An on-call rotation that isn't just "ping the CTO." Error budgets. A working staging environment that mirrors production closely enough to matter.
The rule is simple: if it happens again, it shouldn't be the first time we've thought about it.
What we don't do in 30 days
Rewrites. Framework migrations. Microservices. New databases. Any project that improves the codebase at the cost of shipping speed. Those conversations happen in month two, when we know which parts of the codebase are worth investing in and which ones are about to be replaced by the next pivot.
The best engineering work is the work that compounds. In the first 30 days, the compounding comes from removing risk, not adding polish.