Software engineering · Architecture and due diligence
A straight answer before the money is committed
Assessment of a codebase and the estate around it, build versus buy worked through honestly, and the cost and risk of each path put in numbers. Frequently this is the entire engagement.
Where this starts
The decision is usually taken before anyone looks
Technology decisions of real size tend to be made on the strength of a vendor demonstration, an internal advocate or a board deadline, with the investigation following afterwards to support the decision already taken. By the time the difficulty is visible the contract is signed and the team is committed. What is missing at the point of decision is rarely opinion. It is somebody who has built the thing being discussed and will say plainly what it costs to run.
What we are usually asked to settle
- Whether to buy a product, extend what exists, or build
- Whether a system can carry the next three years or has to be replaced
- What a supplier actually delivered, measured against what was specified
- Why delivery has slowed, and whether the cause is the codebase or the process
- What a company being acquired is really carrying in its technology
- Whether an estimate from a vendor or an internal team is credible
Our position
We will tell you not to build something when buying it is the right answer. That is a harder sentence for a build firm to say, which is exactly why it is worth hearing from one.
What the work covers
Evidence rather than impressions
An assessment is only useful if it is specific enough to act on. We read the code, run the system, talk to the people maintaining it, and put numbers against what we find.
Codebase and architecture review
Structure, coupling, test coverage, dependency health and the places where change is genuinely expensive. Read rather than described to us, because a team describing its own system tends to describe the version it intended to build.
Build versus buy
The comparison done properly, including the integration and operating cost of the bought option and the maintenance cost of the built one, over a stated period rather than at the point of purchase.
Delivery diagnosis
Where the lead time actually goes. It is usually environments, review latency or unclear ownership rather than engineering skill, and those are fixable without changing the team.
Cost and scalability modelling
What the system costs to run at today’s volume and at the volume you are planning for, with the assumptions written down so that you can argue with them rather than inherit them.
Transaction due diligence
Technology, team and risk assessment ahead of an investment or acquisition, written for people who have to make a commercial decision rather than a technical one.
A costed route forward
The output is a sequenced plan with effort ranges and the decisions that have to be taken at each point, not a maturity score against a model nobody chose.
How it stays useful
An assessment that survives the quarter
Most reviews are accurate on the day they land and stale within three months. These are the things we leave running so the picture keeps itself current.
- Baseline
- The measurements taken during the review wired in as recurring checks, so the next conversation starts from current numbers rather than from another review.
- Dependencies
- Automated reporting on ageing and unmaintained dependencies, which is the most reliable early signal that a codebase is becoming expensive to change.
- Delivery
- Lead time, deployment frequency and change failure rate collected from your own systems, so progress against the plan is visible without anyone being asked.
- Cost
- Spend attributed to service and environment, so a scalability assumption can be tested against what actually happens rather than defended.
- Decisions
- Architecture decisions recorded where the work happens, so the reasoning survives the people who were in the room when it was made.
What you are left holding
- A written assessment with findings ranked by the cost of inaction
- A build versus buy comparison with operating cost included
- A sequenced plan with effort ranges and named decision points
- Delivery and cost metrics running against your own systems
- A briefing for the board or investment committee, in their language
Tell us the decision you are about to take
We will tell you what we would need to look at, how long it takes and what it costs. It is usually measured in weeks.