Know the software
before you decide
We review a software product’s code, architecture, security and the way it’s delivered, then write up what we found and the evidence behind it, so you decide with the facts in front of you.
Thanks, we’ll be in touch soon.
{{ heroStatus }}
{{ heroSay }}
You’re in good company
A few of the companies we’ve worked with.
{{ wallSay }}
A decision that rests on software
When you invest in a software company, buy one, sell one or take charge of its engineering, most of what you’re deciding on is code you can’t see. A product can look finished and still be hard to change, costly to run or dependent on one person. It can also look plain and be well built and cheap to extend. A pitch can’t tell you which. Reading the software can.
That reading is technical due diligence: a careful look at the software before you commit to it.
What we review
The product as its engineers know it, from the code to the people who keep it running.
The code
How it’s organized, how well it’s tested and how hard it is to change, read by engineers and measured where a measure exists.
The architecture
How the parts fit together, where it will strain as use grows, and what ties it to one supplier.
Security
How sign-in, secrets and data are handled, and the known weaknesses in what it’s built from.
What it’s built from
Every open-source and third-party component listed, each with its license and whether it’s still maintained.
Where it runs
The hosting, what it costs to run, how it’s backed up, and whether a restore has been tried.
How changes reach users
Reviews, tests and releases: how long a change takes to reach users, how often it fails or comes back, and how fast it’s put right.
The data
What’s stored, where, who can reach it, and how a record is corrected or removed.
The people and what they know
Who has changed which parts, what’s written down, and what would leave with one person.
AI in the product and the code
The models and services it relies on, under which terms, and where AI tools wrote the code.
Acting on an older system the report describes? Legacy Modernization →
Security work in the code and the release process? Application Security →
Someone to look after it afterward? Support & Maintenance →
Every finding points to its evidence
A report your team, or the other side’s, can check line by line.
Each finding in the report says where we saw it, what it means for the product, what it would take to put right, and how sure we are. Anyone with the same access can follow it back and check.
The report also says what’s working, since that’s part of what you’re deciding on. It gives no score: a single number would hide the reasoning you need.
Where a public yardstick exists, the report uses it and names it: ISO/IEC 25010:2023 for what quality means in software, ISO/IEC 5055:2021 for weaknesses counted in the code, a published standard of security requirements for web applications, the DORA software delivery measures for how changes reach users, and the minimum elements CISA and its partner agencies published for the list of components.
DORA is a program run by Google Cloud, and its name is a trademark of Google LLC. Webair isn’t affiliated with the organizations that publish these yardsticks, and isn’t sponsored or endorsed by them.
Review of a booking product
A sample
Findings
- Finding 1:
Tests run on every change and cover the paths that take payment.
What it would take: Nothing.
Evidence 1 - Finding 2:
A key was deleted from the code but is still in its history.
What it would take: Small: replace the key.
Evidence 2 - Finding 3:
One engineer has made every recent change to billing.
What it would take: Medium: pair on it, and write it down.
Evidence 3 - Finding 4:
A component several layers down carries a license your counsel should read.
What it would take: Ask counsel first.
Evidence 4 - Finding 5:
A release needs a manual step that isn’t written down.
What it would take: Small.
Evidence 5
Evidence
Not reviewed
- The mobile apps: access didn’t arrive in time.
- Customer records: not needed.
- Seen:
- we saw it ourselves, in the code, the settings or the history.
- Told:
- the team told us, and the report says so.
- Not reviewed:
- what we couldn’t look at, and why.
What we ask for, and how it’s handled
A review needs to see the real thing, and you need to know who’s looking. A non-disclosure agreement (NDA) comes first. After that, access is read-only, given to named engineers, and removed when the report is delivered.
| What we ask for | What it’s for | How it’s handled |
|---|---|---|
| The source code and its history | To read how it’s built and how it has changed | Read-only, on your systems or a copy you control |
| The hosting accounts | To see how it runs, what it costs and how it’s backed up | A read-only role, removed at the end |
| The build and release setup | To see how a change reaches users | Read-only |
| Documents you already have | Architecture notes, incident write-ups and earlier reviews | Shared the way the deal shares documents |
| A few conversations | With the people who build and run it | Planned around their work |
| Customer records | Not needed | We look at how records are stored and protected, not at the records |
Whichever side of the table you’re on
Investing or acquiring
An engineer’s read of the product before you commit: what’s sound, what needs work, and what that work would take.
Raising or selling
The same review before buyers arrive, so you can fix what’s quick, plan what isn’t, and answer their questions with evidence.
Taking charge
For a new CTO or head of engineering: a clear account of what you’ve inherited, and where to start.
Whichever side you’re on, the review is independent: we have no stake in the decision, and we don’t review software we built.
Taking software back from an agency or a vendor? Support & Maintenance →
Start with the decision
We begin with one call: what you’re deciding, by when, and what you already know. From that we write a one-page scope: what’s in, what’s out, the access we need, and the date of the report. Work starts once you’ve agreed it, and in a deal, once the other side has too. It ends with the report and a call to walk you through it.
How the review is paid for: Pricing
Questions worth asking
How long does a review take?
It depends on the size of the product and how quickly access arrives. We agree the report’s date before we start, and plan the work back from it.
Who sees our code?
Only the named engineers doing the review, under an NDA signed before any access. Access is read-only. When the report is delivered it’s removed, any copies are deleted, and we confirm that in writing. We never name the companies we review, or the ones we review for.
Do you need our customers’ data?
No. We look at how records are stored and protected, not at the records themselves.
Is this a security test or a compliance audit?
No. It’s an engineering review, and it covers how security is handled in the code, the settings and the release process. It isn’t a penetration test, a certification or a compliance audit. Where a decision needs one of those, the report says so.
Is the report legal or financial advice?
No. It gives your lawyers and advisers the engineering facts they need, such as the list of components and their licenses.
Will you fix what you find?
Only if you ask, and as a separate decision. The report is written so any capable team can act on it. We don’t review software we built ourselves.
Can you review a product with AI in it?
Yes. We list the models and services it relies on and the terms they come under, how its answers are checked, and what it costs to run. AI Security & Governance →
Will AI tools read our code?
Only the tools you’ve agreed to in writing before the review starts. If you agree to none, none are used.
What does technical due diligence cost?
It depends on what the decision needs us to review and how large the product is. The first call is free. Your proposal sets out the scope, the price or rate, and how you pay, before any work starts. Pricing →
Let’s do it better
Tell us what you’re deciding, and by when. We’ll suggest a scope that fits.
Thanks, we’ll be in touch soon.
{{ ctaStatus }}