Software engineering · Architecture and due diligence
A clear answer before you commit the money
We assess your code and the systems around it, compare building with buying honestly, and put figures on the cost and risk of each option. Often, this is the whole engagement.
Where this starts
Big decisions are often made before anyone looks closely
Large technology decisions are often made on the strength of a vendor demonstration, an enthusiastic colleague or a board deadline. The investigation then happens afterwards, to support a decision that has already been made. By the time problems appear, the contract is signed and the team is committed. What is usually missing at the moment of decision is not opinion. It is someone who has built this kind of system and will say plainly what it costs to run.
What we are usually asked to decide
- Whether to buy a product, extend what you have, or build something new
- Whether a system can support the next three years, or needs to be replaced
- What a supplier actually delivered, compared with what was specified
- Why delivery has slowed down, and whether the cause is the code or the process
- What technology risks a company being acquired is really carrying
- Whether an estimate from a vendor or an internal team is realistic
Our position
If buying is the right answer, we will tell you not to build. That is harder for a firm that builds software to say, which is why it is worth hearing from one.
What the work covers
Evidence, not 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 who maintain it, and put figures against what we find.
Code and architecture review
We look at how the code is structured, how closely its parts depend on each other, how well it is tested, the health of its dependencies, and where changes are genuinely expensive. We read the code ourselves, because teams tend to describe the system they meant to build rather than the one they have.
Build or buy
We compare the options properly over a stated period, not just at the point of purchase. That includes the cost of integrating and running a bought product, and the cost of maintaining one you build.
Diagnosing slow delivery
We find where the time really goes. It is usually waiting for environments, slow code reviews or unclear ownership, rather than a lack of engineering skill, and these can be fixed without changing the team.
Cost and growth modelling
We calculate what the system costs to run today and at the volume you are planning for. We write down our assumptions, so you can challenge them rather than simply accept them.
Due diligence for investment and acquisition
We assess the technology, the team and the risks before an investment or acquisition. The report is written for people making a commercial decision, not a technical one.
A costed plan
You receive a plan in a clear order, with a range of effort for each step and the decisions needed along the way. It is not a maturity score against a model that nobody chose.
How it stays useful
An assessment that stays accurate
Most reviews are accurate on the day they are delivered and out of date within three months. We leave the following in place, so the picture stays current.
- Baseline
- The measurements we take during the review become regular automated checks. The next conversation starts from current figures, rather than needing another review.
- Dependencies
- Automated reports show which third-party components are ageing or no longer maintained. This is the most reliable early warning that the code is becoming expensive to change.
- Delivery
- Lead time, release frequency and the rate of failed changes are collected from your own systems. You can see progress against the plan without having to ask anyone.
- Cost
- Spending is broken down by service and environment. Assumptions about growth can be checked against what actually happens, rather than argued over.
- Decisions
- Architecture decisions are recorded where the work happens. The reasoning is kept even after the people who made the decision have moved on.
What you are left with
- A written assessment, with findings ranked by the cost of doing nothing
- A comparison of building and buying, including running costs
- A plan in a clear order, with effort ranges and the key decision points
- Delivery and cost measures running against your own systems
- A briefing for your board or investment committee, in plain business language
Tell us about the decision you are about to make
We will tell you what we would need to look at, how long it would take and what it would cost. It is usually a matter of weeks.