Two weeks, and a written plan your own team can act on.
A software architecture review with a fixed scope: we read your stack properly, then hand you a document that ranks what is wrong by what it is costing you.
Fixed price, 2 weeks · the document is yours whether or not you hire us afterwards
This is the cheapest way to find out whether you need us at all, and it is a real deliverable rather than a sales call with slides. Two weeks: we read the code, the data model, the infrastructure and the deploy path, talk to the people who work in it every day, and write down what we find.
What you get back is a document in plain language — one your CTO and your board can both read — with the findings ranked by what they cost you rather than by how interesting they are, and a plan in three horizons. It is written so your own engineers can execute it without us, because most of the time that is the correct outcome.
The other three engagements here — automation, building the product, and the data platform — often start here, but none of them has to.
Who this is for.
Two weeks is not long, which is what makes the entry criteria matter.
A good fit
- A CTO who wants a second opinion before committing to a rewrite, a migration or a hiring plan, from someone with no stake in the answer.
- A founder without an engineering background who has inherited a codebase and cannot tell whether the estimates coming out of it are honest.
- A board or an investor who wants a technical read on a company before signing something.
- A team that already knows what is wrong and needs it written down by someone from outside so it can be prioritised against everything else.
- You are about to spend a lot on engineering and would like to know first which part of the money is going to be wasted.
Not a good fit
- You want the document to confirm a decision that has already been made. We will write what we find, and if that is inconvenient it is still what you get.
- You cannot give us read access to the repository and an hour each with two or three of the engineers who work in it. Without those, a review is an educated guess and not worth buying.
- There is no code yet. There is nothing to review — start with building the product instead, where the first week is a scoping session anyway.
- You need a formal security audit, a penetration test or a certification. This is an engineering review by engineers; those are regulated exercises with their own specialists.
- You want a fixed price for the fixes at the end of it. The plan says what the work is; estimating it properly is the first thing the plan makes possible, not something the review pre-empts.
What usually prompts one of these.
Six arguments that a document from outside settles faster than another meeting.
The rewrite argument
Half the team wants to rebuild, the other half wants to refactor, and nobody has written down what the rebuild would actually cost or what it would buy. The argument runs again every quarter and nothing moves.
Estimates that keep slipping
Every feature takes three times as long as it should and nobody outside the team can say why. Usually there is a specific reason, it is structural, and it is visible in a week of reading.
The cost line growing faster than usage
The infrastructure bill is rising and nobody can point at what is driving it. This is one of the few findings that pays for the review outright.
The bus factor
One person knows how the deploy works, or why that service exists. Everyone knows it is a risk; nobody has ever put a number on it or a plan against it.
The scaling question you cannot answer
What happens at ten times the traffic, and which part gives first. Guessing is expensive in both directions — over-building costs money now, under-building costs a weekend later.
Diligence before a deal
Somebody is about to buy, invest in or merge with a codebase, and needs a technical read that is not written by the people who built it.
What you get.
One document and one conversation. Both are yours; neither depends on hiring us.
A written document, in plain language
Written to be read by a CTO and by a board member, without two versions. Jargon appears where it is load-bearing and is explained where it is not.
Findings ranked by cost
Ordered by what each one is costing you in money, in time or in risk — not by how interesting it was to find. The order is the most useful part of the document.
A plan in three horizons
This month, this quarter, this year: what to do, roughly what it takes, and what each one buys. Written so your own engineers can pick it up and start.
The risks we would not ignore
Named individually, with what happens if you do ignore them. Short list, deliberately — a list of forty risks is a way of having no opinion.
Numbers where they exist
Build times, bundle sizes, query plans, the cost breakdown. Where something can be measured we measure it rather than describing it, because a number survives a disagreement and an adjective does not.
What is working
Explicitly. A review that only lists problems gives you no way to tell which decisions to keep, and teams deserve to know which parts of their work were right.
A read-out call with your team
We walk through the document with the engineers, not only with whoever commissioned it, and answer the objections in the room. Some findings change in that call.
How the two weeks run.
Calendar time, not effort spread over a quarter. It starts on an agreed Monday and the document arrives on the second Friday.
Access and context
Read access to the repository, whatever documentation exists, and an hour each with two or three engineers. What you are trying to do commercially matters as much as the code.
The reading
The code, the data model, the access rules, the infrastructure, the deploy path, the dependencies and the monitoring. This is the bulk of the work and it is unglamorous.
The measuring
Build times, query plans, bundle sizes, the cost breakdown — whatever can be turned from an opinion into a number in the time available.
Writing, then the read-out
The document is written, sent, and then walked through with your team. You own it from the moment it is sent.
Why our reading is worth two weeks of your budget.
Because it is the same reading we do on our own code before a breaking change, and ours has been in production for six years.
Every judgement in one of these documents comes from having had to live with the equivalent decision. We have shipped migrations across thousands of live FireCMS installs without breaking them, and we have built the technology behind medicalmotion since 2019 — a product where the questions come from insurers and reviewers, not only from users.
That is also why the review is not a sales instrument. The question it answers is not “can we build this?” but “who is going to be maintaining this in four years, and will they curse us?” — and quite often the honest answer is that your own team can do the work, which is what the document is written for.
Questions we get asked.
Including the one about whether we are just going to sell you a rewrite.
What do you need from us?
Read access to the repository, an hour each with two or three engineers who work in it, and access to whatever monitoring and billing exists. Documentation is welcome and rarely decisive.
Do we have to hire you afterwards?
No, and the document is written on the assumption that you will not. It is a plan for your own team, in your own team’s hands. If you do want us to execute part of it, that is a separate engagement with its own scope.
Are you going to tell us to rewrite everything?
Usually not. A rewrite is the most expensive answer available and it is right less often than it is proposed. Where it is right, the document says what it would cost and what it would buy, so the decision is made on numbers rather than on frustration.
Is two weeks calendar time or effort?
Calendar. It starts on an agreed Monday and the document arrives on the second Friday. The work is concentrated in the first week and a half; the last two days are writing and the read-out.
Will you sign an NDA?
Yes, before we are given access to anything. Send yours or ask us for one.
What if we disagree with a finding?
The read-out call is for exactly that, and some findings do change there — your engineers know things the code does not say. What we will not do is remove a finding because it is awkward.
The other three ways in.
Every engagement here starts with a fixed scope and a milestone plan.
Tell us what’s stuck.
Tell us what you are about to decide and what makes you unsure. Two paragraphs is enough to say whether a review is the right purchase or whether you already know the answer.
We read everything and reply within one business day.