The assessment framework
What gets looked at, and the reasoning behind it.
This is the detail behind the independent technology assessment. It sets out the situations that prompt one, the areas examined and why each matters, and how findings are separated from the background noise every codebase carries.
It's a superset rather than a script. No engagement covers all of it to the same depth. The weighting is agreed at the start, because a platform being prepared for sale needs scrutiny in different places from one preparing to triple its customer base. The point of writing the whole thing down is that anything skipped is skipped deliberately.
Why an assessment gets commissioned
Each of these sends the work somewhere different. The situation decides where the depth goes.
New leadership
Someone has taken responsibility for a platform they didn't build. The first job is establishing what's there and where the knowledge sits, since a change at the top often prompts departures.
Delivery has lost credibility
Releases keep slipping and there's no agreement on why. The work is separating the code from the process, the team, and a plan that may never have been achievable.
A proposed rewrite
A major rewrite or modernisation programme is being proposed. The question worth settling first is whether the current system genuinely can't reach where the business is going, or whether the difficulty lies in the process around it.
Growth concerns
The business has grown and leadership is concerned the platform will constrain the next stage. Growth usually breaks on one specific ceiling, and whether unit economics improve with volume matters as much as whether the platform stays up.
Key people moving on
Key technical people are leaving or approaching retirement. There's a deadline attached, so the priority is identifying what only they know while they're still available to ask.
Technical debt
Debt has built up over years and it's unclear where investment should go. The list of it usually exists already. What's missing is which items actually cost money, tied to delivery drag, defects, or spend.
A future transaction
Investment, acquisition, or sale is likely at some point. Deals stall over ownership, security, and compliance far more often than over code quality, and those take the longest to put right.
AI claims under question
AI features exist in the product or sit on the roadmap, and leadership wants to know what's genuinely there. Whether the data behind it is proprietary usually decides whether any of it is defensible.
The twelve areas
Each area is examined for what it means commercially. An observation that can't be tied to revenue, customers, cost, or growth doesn't reach the report.
Product, architecture, and scale
Architecture decides what the business can do next and how much each thing costs to do. Limits on growth show up here first, and they're the most expensive findings to act on late.
- How the system is decomposed, and whether the boundaries follow the domain
- Where state lives, and how many places hold the same fact
- The multi-tenancy model, and how tenants are isolated
- Age and support status of core frameworks, runtimes, and databases
- Current load against the load the plan assumes in two to three years
- What scales horizontally and what has a single ceiling
- Degree of per-customer customisation, and whether changes need a developer
- What the next few things on the plan cost architecturally
Codebase and technical debt
Code quality matters where it slows delivery, hides defects, or blocks something the business wants. The work is separating debt that costs money from untidiness that doesn't.
- Size, age profile, and how many generations of style are present
- Churn hotspots, and whether they line up with where defects appear
- Where tests exist, what they cover, and whether the suite is trusted
- Dependency currency, known vulnerabilities, and whether an upgrade path exists
- How long a small change takes end to end, and how often changes cause defects
- Areas the team avoids, and why
- Which debt sits on the path of the next twelve months of work
Data and compliance
Data is the hardest thing to change and the easiest to get wrong legally. Problems surface late, through a customer security review, a regulator, or a migration that can't be done cleanly.
- Schema quality, and where the same fact is stored in more than one place
- Whether customer data can be cleanly separated per tenant, extracted, or deleted
- What personal data is held, where it sits, and under what lawful basis
- Retention periods, and whether they're enforced or aspirational
- Personal data in logs, analytics, backups, and non-production environments
- Certifications held or being pursued, and whether they're maintained
- Volume and cost of customer security questionnaires
- Whether the business can answer its own questions from its data
Security
Security failures are existential for B2B SaaS in a way most other technology risks aren't. This is a review of posture and practice, not a penetration test.
- Who has production access, how it's granted, and how it's removed
- Multi-factor authentication coverage across cloud, source control, and email
- Whether any credentials sit in source control, current or historical
- Authorisation, particularly anything allowing access across tenants
- Dependency vulnerabilities, and how they're tracked and acted on
- Network exposure, and what's reachable that shouldn't be
- Logging and alerting, and whether a breach would be noticed
- Past incidents, and what happened to findings from previous tests
Infrastructure and resilience
This decides whether the product runs on process or on one person's memory. The consequences are downtime, data loss, and a recovery that takes longer than customers will tolerate.
- Whether infrastructure is defined as code or was built by hand
- How long it would take to rebuild the environment from scratch
- Deployment, how many steps involve a person, and whether rollback has been used
- What's backed up, where it's stored, and when a restore was last tested
- Stated recovery objectives against demonstrated ones
- Monitoring coverage, and whether it watches what customers care about
- On-call arrangements, runbooks, and what follows an incident
- Availability history against what customers were promised
Engineering practices and delivery
Delivery pace and predictability are what leadership feels directly. Many complaints about the technology turn out to be complaints about how work reaches production.
- Branching, code review, and how often continuous integration is red
- The mix of automated and manual testing, and where confidence really comes from
- How work is chosen, sized, and tracked
- Lead time, deployment frequency, and change failure rate where measurable
- The split between new work, support, and maintenance
- What gets dropped when a deadline approaches
- Time from a new starter's first day to their first meaningful change
- Use of AI coding tools, and what governs it
Customer-facing quality
The parts of technology customers experience directly. Defect rates, performance, and support load shape renewals more than anything on the architecture diagram.
- Defect volume, trend, and how many reach customers
- Recurring defects with a known cause and no fix
- Support themes, and how many tickets need a developer
- Whether a small number of customers consume most of the effort
- Performance on key transactions as customers experience it
- Accessibility where it's contractually or legally relevant
- Effort to onboard a new customer, and how much of it is engineering work
- Feature requests blocked by technical limits, and the revenue attached to them
Third-party and supplier dependency
Dependencies concentrate risk outside the company's control. The consequences are cost shock, forced migration, or a supplier failure that becomes a customer-facing outage.
- Which suppliers and services the product cannot run without
- What breaks, and how quickly, if each one disappears
- Contract terms, notice periods, renewal dates, and price escalation
- Whether any supplier holds credentials or infrastructure the company can't reach
- Outsourced or offshore development, and where knowledge and IP sit
- Cloud provider concentration, and what portability would realistically cost
- For each critical dependency, what the replacement would be
Licensing and intellectual property
Ownership problems are cheap to prevent and expensive at the point of a transaction or a customer legal review. Nothing breaks until someone looks.
- Open source licences in the dependency tree, particularly copyleft in distributed code
- Commercial licence compliance, and seats bought against seats used
- IP assignment for employees, contractors, and agencies
- Code written before incorporation, or by founders while employed elsewhere
- Ownership of anything built jointly with a customer or partner
- Domains, trademarks, and accounts, and who holds the registrations
- Contractual commitments that constrain technology, including escrow and hosting location
- Rights over customer data, particularly for training models
Team, knowledge, and governance
In a small software business the sharpest risk is usually people rather than code. Knowledge concentration is the most common material finding, and it's rarely visible to leadership until someone resigns.
- Bus factor for each critical system, named explicitly
- What's documented, what's accurate, and what exists only in conversation
- Whether anyone has successfully handed over a critical system before
- Who makes technical decisions, and whether the reasoning is recorded
- Whether leadership gets an honest picture of the technology
- Retention risk, including people approaching retirement
- Recruitment reality for the technologies in use
- Technology risk reporting, and any policy governing AI use
Technology costs
Spend out of line with the value it returns is one of the few findings that pays for the assessment on its own. The bill also records what's actually running, which nothing else does.
- Total spend split between people, cloud, licences, and suppliers
- Cloud cost by service, and the trend over the past two years
- Cost per customer, or per unit of usage, where it can be derived
- Idle resources, unused environments, and duplicated tooling
- Licence seats bought against seats used
- Engineering time going to support and maintenance
- Whether unit economics improve or worsen with scale
- Cost of AI features, and sensitivity to provider price changes
AI features and claims
AI is where the gap between what's described and what exists is widest. The purpose is establishing what genuinely runs, what it's worth, and how defensible it is.
- What's in production, what's in trial, and what's on slides, kept separate
- The real mechanism, whether a hosted model, retrieval, fine-tuning, or rules
- How many customers use it, how often, and whether it's on by default
- Whether outcomes are measured, or the claim rests on demonstrations
- What evaluation exists, and how a drop in quality would be detected
- What happens when it's wrong, what the customer sees, and who is accountable
- Whether the data behind it is genuinely proprietary
- What customer data leaves the system, and whether contracts permit it
- Cost per user or transaction, and dependency on a single provider
How findings are rated
Every codebase carries a large volume of things that could be better. Reporting all of them dilutes the handful that matter, so each finding is rated before it goes anywhere near the report.
Material
Threatens revenue, customers, cost, or the growth plan within roughly twelve months. Goes in the report with a recommendation and an indicative effort.
Watch
Real, but not yet worth acting on. Named in the report alongside the condition that would make it material, so it can be picked up at the right moment rather than forgotten.
Noise
Recorded in working notes and left there. This is most of what any assessment finds.
Alongside the rating, each finding carries how confident I am in it. Something seen directly in code, configuration, or data is stated as evidenced. Something consistent with several independent accounts is stated as indicated. Something asserted in an interview and not verified is labelled as exactly that, so nobody acts on it as though it were established.
What sits outside the scope
Named at the start so expectations are set. Where any of these is needed, I'll say so and point towards a specialist.
- Penetration testing and formal security certification
- Line-by-line code review
- Financial and commercial due diligence
- Legal advice, including definitive positions on licensing or data protection
- Detailed implementation design, which belongs in the advisory engagement that follows
What the report contains
Three sections, in this order. Everything else stays in working notes.
Baseline
A realistic picture of the product, platform, and team.
Risks
The material findings, each with its evidence and what it means for revenue, customers, cost, or growth. Watch items listed separately.
Recommendations
What to do, in what order, with effort and cost for the significant items realistic enough to plan around. Decisions recorded with the reasoning behind them, so they stay made.
Getting started
More on the engagement itself, including how it runs and what it costs in team time, is on the assessment page. The first step is a short, confidential conversation about the business and what's prompting the question.