The architecture that got you here is why everything takes three sprints.
Every growing system reaches a point where the design that made early progress fast becomes the thing slowing it down. I work inside your team to unpick that, without a rewrite nobody has time for.
| Signal | Severity | Usually means |
|---|---|---|
| Endpoints fine at 10k rows, not at 10M | High | Access patterns, not hardware |
| Every feature touches four services | High | Wrong service boundaries |
| Cloud bill outgrowing traffic | Moderate | Architectural, not a discount |
| Deploys need a maintenance window | Moderate | Coupling in the data layer |
| One region, and nobody has tested failover | Unknown | Untested resilience |
Scaling is usually a coupling problem wearing a performance costume
The instinct when things get slow is to add hardware, then a cache, then a queue. Sometimes that is right. More often the endpoint is slow because it is doing eleven things across four services, and no amount of infrastructure fixes a design that requires eleven things.
The same is true of delivery speed. When a small feature needs changes in four repositories and a coordinated release, the bottleneck is not your team's velocity — it is where the boundaries were drawn.
This work is hard to do from outside. Naming the real constraint means seeing what gets deprioritised in planning and what everyone works around without mentioning it, which is why I do it from inside the team.
What I actually do
- Find the actual constraint — usually a handful of access patterns, not the whole system — before touching anything
- Redraw service boundaries so a change lands in one place, rather than splitting things further and adding network calls
- Fix the database layer: indexing, query shape, N+1s, and the read patterns behind your slowest endpoints
- Introduce event-driven patterns and change-data-capture where synchronous calls are the coupling
- Design multi-region and failover properly, including actually testing it
- Attack the cloud bill where it is architectural rather than a pricing conversation
What you end up with
- Measured improvement on the endpoints that matter, with before and after numbers
- An architecture your team can extend without a coordination meeting per feature
- Your engineers knowing why each change worked, because they made them with me
- A written view of what to do next and what to leave alone
How the work runs
| Stage | What happens |
|---|---|
| First two weeks | I read the code, the dashboards and the incident history, and tell you where the real constraint is. |
| Ongoing | A day or two a week inside your team: design, pull requests, pairing, review. |
| Throughout | Your engineers do the work with me. The capability has to stay when I stop. |
| Wind down | We agree an end point rather than drifting into a permanent arrangement. |
Questions people ask
Why embedded rather than a review?
Because the useful information is not in the code. It is in what the team works around, what keeps slipping, and which constraint everyone has stopped mentioning. You only see that from inside.
Will you rewrite our system?
Almost never the right answer. A rewrite trades a known set of problems for an unknown set, and takes longer than anyone estimates. I would rather fix the three things causing most of the pain.
What stack do you work in?
Go, Python, PHP and Java services on AWS. MySQL, Postgres, MongoDB, DynamoDB. Kafka, RabbitMQ, SQS, Debezium. If you run something adjacent, the principles carry.
How long does this go on?
Usually a few months at a day or two a week. We agree an end point up front — the work is finished when your team does not need me for it.