Is this system ready to be changed at AI speed?
AI assistants raise the pace of change. Whether a system can take that pace depends on more than its code: on what verifies a change, ships it, runs it, protects its data and keeps the knowledge alive. The scan measures one system in its environment against what you need from it, and shows the few moves that close the gap.
Good code is not enough
A system can have a sound architecture and a clean security audit and still be fragile, because everything around the code is missing: the tests that catch a broken change, the pipeline that ships it, the backups that protect the data. AI does not fix that. It raises the speed at which it matters.
Change outruns the safety net
When assistants write more of the code, output rises faster than the capacity to review it. What used to be caught by a careful colleague now has to be caught by a mechanism, or it is not caught.
One score hides the weak spot
A code-quality score says whether the code can be changed at reasonable cost. It does not say whether you would know that a change broke something, or whether you could restore the data afterwards.
Not every system needs the same
A ten-user internal tool does not need what a revenue platform needs. Without a stated need, teams over-invest in one place and leave the system that matters exposed.
One result, in plain language
Where the system stands
A level from one to five in each of seven dimensions: Code, Verification, Delivery, Operations, Data, Security and Knowledge. Each level says what quality currently depends on: luck at the bottom, built-in feedback at the top.
What it needs, set by you
The level each dimension requires follows from how critical the system is and what you need from it. The result is the gap, per dimension, between where the system stands and where it needs to be, so a strength never averages away a weakness.
The few moves that close the gap
What is in place, what is missing, and a short, ordered list of moves, in a compact report written for the person who owns the system and decides where to invest.
The result follows the AI Readiness Maturity Model, which is designed so that two systems, or the same system a year apart, read on the same scale.
From a first conversation to a result you can act on
A standard scan with a fixed shape, so it stays light on your side: two conversations, read-only access to the repository, and a short list of questions in between.
An hour to set the scope and the need
We explain the scan, agree where the system begins and ends, and you tell us what you need from the system. Rating the needs takes about two minutes and uses no jargon.
Measured, assessed, interpreted
Maintainability Cloud, our deterministic, benchmark-based instrument, measures the code. Our assessor builds on that to evaluate the system around it, its history and its configuration, with AI scanners as tools.
A short list only you can answer
Some things cannot be seen from the outside. You confirm them, and they count, marked as stated by you. What stays unknown never counts as a pass.
A working session on the outcome
We walk you through the result in a session of an hour to an hour and a half: what you told us, where the system stands, and the moves we would make first.
People who own a system and a decision
- Executives and system owners
- Whether a system can carry what the business depends on it for, and where the next investment goes.
- CTOs and engineering leaders
- Whether a system can take the pace before AI assistance is scaled across it, and what to put in place first.
- Founders and small teams
- Whether a system built quickly, often with AI, is ready to carry real customers, data or revenue.
- Investors and boards
- Whether a system that matters is as sound as it is presented, backed by evidence and stated in business terms.
- Organisations with their own standard
- Whether a system meets your own engineering policy, which can set the minimum level per dimension.
Start with one system
Pick the system you would least like to be surprised by. Tell us what it does and who depends on it, and we will plan the intake, under NDA.
Before you start
How does the scan reach its result?
As a starting point, code quality is measured with Maintainability Cloud, our deterministic, benchmark-based instrument. Its in-depth insights are the basis for the further evaluation by our assessor, who looks at the six dimensions around the code (Verification, Delivery, Operations, Data, Security and Knowledge) and uses a range of AI scanners along the way. All findings are weighed against our evaluation framework, the AI Readiness Maturity Model, and compared with what you need from the system. The report explains the level the system reaches in each dimension. Every level is grounded in evidence and can be traced back to it.
Is it only useful when applying AI?
No. The model behind the scan was developed for organisations that are adopting AI in development, but none of it depends on AI being used: a team that writes every line by hand gets the same picture of what sustains its system.
How is this different from a maintainability score?
A maintainability score tells you about the code. The scan takes that score as its starting point and tells you about the system: whether a change would be verified, shipped, run and recovered safely, set against what this particular system needs.
How does it differ from a Software Risk Assessment?
The scan is standardised: one system, one fixed method, one compact result. It looks at the system in its environment, not at the organisation around it. A Software Risk Assessment puts the evaluation in its organisational context: the decision at stake, the people and teams involved, the history and the constraints, through interviews and document review, typically for a larger or more complex problem situation. That context is not part of the scan. An assessment can include a scan where the access to the code allows it.
What do you need from us?
An hour for the intake, read access to the system’s repository including its history, answers to a short list of questions, and the results session. The history matters: part of the evidence is only visible there. We never need write access, production access or production data.
Can we repeat it?
Yes, and that is the intention: levels are meant to move. A repeat scan after the agreed moves is how you check that they did. For the code itself, Software Portfolio Assurance measures every week.