Overview
Who it is for
The review is for the person who has to decide. The founder choosing between building a platform and buying one. The CTO being asked whether the monolith can survive another year. The product leader with a roadmap that needs a technical reality check before it goes to the board. The head of operations who has been quoted a replatform and wants to know if it is necessary.
It is for decisions with money and time attached, where the cost of being wrong is high and the people recommending the answer may also be the people selling it.
What we deliver
Two weeks with an architect, and a written plan you can defend:
- A clear statement of the decision and the constraints around it: budget, timeline, team, compliance, and what must not break.
- A read of the current state. Code, data, infrastructure, costs, and team capability, reviewed with the people who run them.
- Options, with trade-offs. Usually three: the minimal path, the recommended path, and the ambitious path, each with cost, timeline, risk, and what it rules out later.
- A recommendation, written plainly, with the reasons.
- An architecture diagram of the target state and the steps to get there.
- A phased roadmap broken into increments that each deliver something usable.
- A cost model covering build, run, and the difference between the options.
- Risks and mitigations, including the ones that are organizational rather than technical.
- A working session with your leadership to walk through the plan and answer the hard questions.
The plan is yours to carry out with us, with your own team, or with another vendor. It is written to survive that choice.
How the engagement runs
The review is a standalone two-week engagement with a fixed fee.
- Listen. A 60-minute call to understand the decision. A one-page scope within 48 hours that names the question the review will answer.
- Week one. Interviews with the people who build, run, pay for, and depend on the system. Read access to code, infrastructure, and bills. A map of the current state and the first draft of the options.
- Week two. The options are costed and tested against the constraints. The recommendation is written, the roadmap is phased, and the plan is reviewed with you before it is final.
- Delivery. The written plan, the diagram, the cost model, and a leadership session. If the plan leads to a build, the discovery sprint of that engagement starts from it rather than from zero.
One named architect does the review from start to finish.
Typical questions
Build or buy, and if buy, which, and what will we still have to build around it. Replatform now, in a year, or never. Monolith or services, and which parts first. Which cloud, and whether moving is worth it. How to scale a system that worked at one-tenth the volume. What a reasonable three-year roadmap looks like for a product with real customers and a small team. Whether the system a previous vendor built is salvageable.
Each of these has a sensible answer for your situation, and the review’s job is to find it and write it down in a way a board will understand.
What makes a plan defensible
A defensible plan shows its work. It names the options that were rejected and why. It puts numbers on cost and time, with the assumptions visible. It separates what is known from what is a bet. It tells you what the first increment is and what you will learn from it. And it is written in plain language, because the people who approve it are not the people who will build it.
If the plan recommends a build, custom software consulting and cloud architecture are where it usually leads.