“Our developers say it is finished.”
You commissioned an application but cannot tell whether it is safe to rely on, maintainable or built to the agreed requirements.
INDEPENDENT SOFTWARE ASSURANCE
You have software.
Can you trust what was built?
Perhaps your developer says the application is finished. Perhaps AI helped build it. Or perhaps you are about to rely on it for paying customers. Our privately commissioned software assurance examines the technical concerns that matter to your next decision.
WHEN CLIENTS CONTACT US
Which of these situations sounds familiar?
Software assurance is an independent assessment of the software and supporting evidence. It is not a public upload-and-scan service.
“We built it using AI. Is it ready?”
Your application looks good in a demonstration, but you want someone independent to investigate the risks before real customers rely on it.
“We are investing in someone else’s software.”
You need to understand what technical problems, maintenance costs or dependencies you could be taking on.
ILLUSTRATIVE SOFTWARE ASSURANCEILLUSTRATIVE ENGAGEMENT
A FAMILIAR SITUATION
You have paid for an application. It works in demonstrations. How do you know what you are actually relying on?
WHAT THE CLIENT WOULD RECEIVE
An evidence-led assessment of software condition
Depending on the agreed scope, a review can examine relevant code-quality, security and maintenance concerns, and investigate specific delivery questions using specifications or records the client provides.
WHY IT MATTERS
You can ask informed questions, prioritise what needs attention and decide whether to accept delivery, commission repairs or investigate further.
WHY INDEPENDENT REVIEW MATTERS
Problems can hide
behind a working demonstration.
Software can appear to work while carrying problems that are expensive to discover later.
For example, it might depend on an outdated component, have weaknesses in how it controls access, or be so difficult to change that a small improvement becomes a major expense. Those problems are not obvious to a non-technical owner.
Our role is to examine the available technical evidence and explain what the findings could mean: potential cost, operational disruption, customer exposure or dependence on a particular developer. We also distinguish what was checked from what still needs further investigation.
YOUR CODE AND INTELLECTUAL PROPERTY
Confidential source code is
not just another AI prompt.
Your source code can contain valuable design work, commercially sensitive logic and details about how your business operates.
Uploading a repository to a third-party AI service may disclose that material to another provider. Retention, access and model-training practices differ by product, contract and settings. Even where training is disabled, processing outside your organisation can raise confidentiality, contractual and intellectual-property questions.
Our default is not to send client source code to third-party large language models. We would consider an exception only at the client's explicit, documented request and after agreeing the specific tool, material, purpose and safeguards. Permission to assess software is not, by itself, permission to upload it to an AI model.
Our assessment approach is designed so language models, where appropriate and permitted, can help organise or explain carefully controlled analysis findings rather than being given the underlying repository. Findings and summaries may also be sensitive, so any such processing must fit the agreed confidentiality arrangements.
There is no public code-upload portal. We agree access, transfer, retention and authorised uses before receiving confidential materials.
COMMERCIAL REPORTING
Understand the implications.
Not just the technical warnings.
A list of code warnings rarely answers the question an owner actually has: what should I do next?
An assessment can explain which issues have credible evidence, how several weaknesses may interact, what could happen to the business if they remain unresolved, and which questions or corrective actions deserve priority.
The result is intended to be useful to decision-makers as well as engineers. It must show the limits of the review, rather than suggesting that a clean scan proves the software is safe.
CHECKING REPAIRS
A fix should be checked,
not simply accepted.
Correcting one problem can accidentally create another.
Engineers call this a regression. For example, changing a login system to close a security gap could unintentionally stop legitimate customers signing in. A repeated, agreed assessment can compare the software before and after a repair to look for remaining problems and new risks.
For businesses, that helps turn a promise that something has been fixed into a better-supported decision about whether the repair is ready to accept. Follow-up reviews assess defined versions at agreed points, not software continuously in the background.
PRIVATE, BESPOKE COMMISSIONS
How a software assessment works.
The work is individually priced and privately arranged. No public scan, instant guarantee or standardised package is offered.
01
Explain the concern
Describe the software, what worries you and the decision you need to make. No code is needed for the initial enquiry.
02
Agree scope and privacy
Set the questions, authorised materials, confidentiality arrangements, delivery and fee.
03
Examine the evidence
Investigate the agreed software state and identify significant, supportable findings and limitations.
04
Decide what comes next
Receive prioritised explanations and, if useful, agree checks of later repaired versions.
FOR SOFTWARE TRANSACTIONS
Buying or selling
a software business?
Our dedicated Technical Due Diligence service connects findings about the software itself to the commercial risks in an acquisition, investment or sale.
Where buyer and seller want to address findings constructively without direct buyer custody of proprietary source code, our buyer-commissioned collaborative TechDD option can provide an agreed opportunity for seller-led repairs and independent verification.
Our full TechDD platform is undergoing a major upgrade. We welcome enquiries and agree any current work and deliverables against available capabilities.
Explore Technical Due DiligencePRACTICAL QUESTIONS
Before you commission an assessment.
What an independent review can tell you, and what it cannot.
Our software works in demonstrations. Why have it independently checked?
A working demonstration does not establish maintainability, security or reliability under other conditions. An agreed assessment investigates material concerns and explains what the evidence supports and what remains unknown.
Do you assess software built partly or entirely using AI?
Yes, where an appropriate scope and current capability can be agreed. The question is the condition of the resulting software, not whether a human or AI produced it.
Will the report make sense to someone who is not a software engineer?
Reporting is intended to connect technical evidence with priorities, likely business consequences and uncertainties. It is not simply a list of scanner messages. The exact deliverables are agreed before work starts.
Can you check whether a developer has really fixed an issue?
A later, separately commissioned review can examine the updated software. It can also look for regressions, meaning faults or weaknesses introduced by a change that was supposed to fix something else. No retest can guarantee that every problem has been found.
Will you put our source code into a third-party AI model?
Not as a routine part of the service. Any exception requires a specific, explicit, documented client request and agreed handling safeguards. When appropriate and authorised, an AI model may help summarise controlled analysis findings rather than receiving source code.
Is this the same as Technical Due Diligence for an acquisition?
They are related but have different commercial purposes. TechDD focuses on risks relevant to an investment, purchase or sale. It can also offer an agreed collaborative buyer-seller process.
YOUR NEXT STEP
Not sure what condition your software is in?
Tell us what has been built, why you need reassurance and what decision you are facing. We will discuss a confidential scope before requesting source code.