Technology Assessment for B2B SaaS
Familiarity hides problems. An outside view of what's really there.
Years ago I flagged an architectural problem I thought would make a product hard to sell. The advice wasn't taken. The first serious prospect, a partner who planned to sell the product as well as use it, spotted the same issue during their evaluation. The deal fell through, and the product was abandoned.
The problem was cheap to fix when I raised it, and fatal by the time the prospect saw it. I've spent over twenty years building software for organisations from startups to the BBC, much of that time exploring unfamiliar codebases and helping people make hard decisions about what to do with them. That work spans media, fintech, real estate, health and safety, and a range of other SaaS products. I've worked hands-on with machine learning since 2021, and more recently with agentic AI.
An independent technology assessment brings that outside view to established B2B SaaS companies that know they need to modernise but are struggling to turn that into a plan. Conducted over three to six weeks, it gives leadership a clear picture of the technology, the decisions that need making, and the evidence to make them hold. It applies the same scrutiny a sophisticated buyer's technology due diligence would, without the compressed timescale of a transaction.
Why commission one
These are the situations that most often prompt an assessment.
An independent view
A CEO wants an outside picture of the technology organisation, without relying solely on what filters up internally.
A proposed rewrite
Management is being told a major rewrite or modernisation programme is necessary, and wants it validated independently.
Growth concerns
The business has grown, and leadership is concerned the platform may constrain the next stage.
Key people moving on
Key technical people are leaving or approaching retirement, taking hard-won knowledge with them.
Technical debt
Debt has built up over years, and it's unclear where investment should be prioritised.
A future transaction
Investment, acquisition, or sale is likely at some point, and it's better to know now what due diligence would find.
What gets assessed
The scope adapts to the situation. A full assessment covers the areas that most often decide whether technology supports the next stage of growth, drawing on the domain, the product and codebase, the team, the company's history and future plans, revenue streams, known risks, and the pain points that prompted it.
Product, architecture, and scale
How the system is structured, whether those foundations can support where the business is heading, and what it would take to carry the growth the plan assumes.
Codebase and technical debt
Code quality and the debt that's accumulated. Which parts genuinely threaten the business, and which are merely untidy.
Security
How customer data and systems are protected in practice, covering access control, secrets handling, and security hygiene. A review of posture and practice, not a penetration test.
Infrastructure and resilience
Deployment, monitoring, backups, and incident handling. Whether the product is run on solid process or on goodwill and memory.
Engineering practices and delivery
How work moves from idea to production, and whether the pace and predictability of delivery match what the business needs.
Team, knowledge, and governance
Where the critical knowledge sits, how much walks out of the door if one person leaves, and whether decisions and ownership are written down.
Technology costs
What the platform costs to build and run, and where spend is out of line with the value it returns.
AI features and claims
Where AI exists in the product or sits on the roadmap, what it genuinely does, how defensible it is, and where further investment is justified.
What the report delivers
A long technical audit helps nobody. Everything in the report serves three questions. What should change, why it matters, and what should happen first.
Baseline
A realistic picture of the product, platform, and team.
Risks
The issues that really matter, separated from the background noise every codebase carries, and what each means for revenue, customers, cost, or growth.
Recommendations
What to do, in what order, and where modest investment would make a disproportionate difference. Effort and cost estimates for the significant items are realistic enough to plan around. Decisions are written down with the evidence and reasoning behind them, so they stay made.
An assessment might conclude that development and source control should move to GitHub, setting out why it matters, the risks it addresses, and the broad direction. Repository structure, branching, and CI/CD get worked out later, once the direction is committed to.
Where a recommendation carries significant uncertainty, such as a proposed rearchitecture or a new AI capability, I can build a proof of concept to validate the idea before serious investment.
How it works
It starts with a short interview about where leadership thinks the business is and where it needs to get to. Uncertain answers are fine, and common. The destination shapes the assessment, since a platform preparing for sale needs scrutiny in different places from one preparing to scale. From there it runs in four stages, and it's designed to be light on the team being assessed.
Discover
Read-only access to the code, and to whatever else tells the real story. The issue tracker, cloud accounts, monitoring, and any documentation that exists. Alongside that, conversations with the people who build and run the platform, and with whoever holds the history.
Assess
Most of the work happens independently, away from the team. Their direct involvement across the whole engagement usually amounts to a few days, spread across interviews and walkthroughs, so delivery carries on.
Decide
Findings are tested with the people who run the platform before anything is put in writing. Where something needs a decision, it's made with the person who owns it and recorded with the reasoning behind it, so it stays made.
Recommend
The report, followed by a walkthrough with leadership and anyone else who needs to be in the room. Enough time to work through the findings, the order of the priorities, and the questions they raise.
After the assessment
The assessment settles what should change, why it matters, and what should happen first, with the decisions recorded. What it deliberately leaves open is the how.
Some companies take the report and deliver with their own team. Others want experienced judgement alongside them while they work through it, with hands-on implementation where it helps. That's the advisory engagement, and it picks up exactly where the assessment stops.
Where the experience comes from
Hands-on engineering and product work with organisations like these.
Getting started
The first step is a short, confidential conversation about the business and what's prompting the question.