Architecture & technical review
Short, sharp engagements where the deliverable is a decision: a written second opinion on an architecture, an API design read, or technical due diligence on a codebase before money moves.
Sometimes the need is not a build but a decision. These engagements are deliberately easy to start and easy to end, and the deliverable is a document rather than a branch.
What this looks like
- Architecture review: a written, specific second opinion on a stack, a migration plan or a build-versus-buy question — including the option of leaving things as they are.
- API and protocol design: REST against tRPC against gRPC, versioning, pagination, idempotency, and what the choice will cost in two years.
- Technical due diligence: reading a codebase and reporting what a buyer or an investor should know about it, in language a non-engineer can act on.
- A read on whether a plan survives contact with its own scale, and which assumption is the load-bearing one.
How the review is delivered
A written document with findings ranked by what they will cost, each one traceable to a file or a measurement rather than a feeling — followed by a call to argue about it. Vague reassurance is not the product.