A source code and engineering assessment in ten business days: what is wrong in the code and what it costs to fix, who the product depends on, what the open-source tree exposes, and how the team performs against the market. A qualified reviewer confirms every finding before it reaches the report.
ValidatedEvery finding confirmed by a reviewer23 findings
P0 0
P1 3
P2 9
P3 11
Illustrative run. The tools find; a reviewer decides.
business days from read-only access to the readout
10
engineers in the benchmark the team is compared with
120,000+
lines of source code leave the environment the owner approves
0
Three reasons to look inside the code.
A deal adviser needs evidence for a client. An investor needs a price. An owner needs to know what a buyer will find. The assessment answers each of them from the same evidence.
Reports that drop into your deliverable
Written to be used directly in your client report, not reworked into it, and delivered under your timeline.
Runs alongside the wider diligence
Ten business days from access, in parallel with commercial and financial work, so both land together.
Evidence you can stand behind
The benchmark is third-party attributable, and every code finding carries its evidence, references and a reviewer’s sign-off.
Contracted with your firm
We work for you, under your terms, and the reviewers are named and approved before access is granted.
Is the code worth what is being paid?
Quality and maintainability against industry benchmarks, with the structural defects behind the score.
What will the technical debt cost?
Debt costed in person-days per finding and rolled up into one indicative figure for the model.
Who could walk out with the product?
Ownership by module, bus factor, and the share of the code written by people who have already left.
What does open source expose us to?
A full software bill of materials, licence and copyleft exposure, and known vulnerabilities in the dependency tree.
Before a raise or a sale
Find and fix what a buyer’s technical diligence will find, before it turns into a price discussion.
Before a new team takes over
Hand the codebase to a new partner or in-house team with its risks, owners and debt on paper.
After a fast, AI-assisted build
Check what was really built: generated code, test gaps, security, and the parts only one person understands.
Before the board asks
An independent view of the engineering asset, in terms a board and an investor can act on.
Two kinds of evidence, one answer.
Comparative evidence shows how the team performs against the market. Diagnostic evidence shows what specifically is wrong and what it costs to fix. Each can run on its own.
Engineering benchmark
Output, quality and rework scored from the full commit history and placed against 120,000+ engineers by sector and company size. Built on research from Stanford University. Objective and third-party attributable, not our opinion.
A deep audit of the source code: deterministic tools, program-graph analysis and manual expert review across architecture, code quality, security, open source, testing and DevOps. Specific, evidenced and costed to fix.
Built on top of both: key-person dependency. No platform produces it as a standard output, so we construct it from contributor-level attribution and per-module ownership.
How each question is answered
Question
Benchmark
Code
What you get
Code quality and maintainability
A quality score placed in an industry quartile, plus the structural defects behind it
Technical debt and remediation effort
Debt in person-days per finding, rolled up into one indicative cost
Key-person dependency
Ownership per module, bus factor, and exposure to people who have left
Open-source IP risk
A full software bill of materials, licence classification, copyleft and attribution exposure
Open-source vulnerabilities
Direct and transitive CVEs, end-of-life components, a prioritised upgrade path
Rework and delivery efficiency
Churn and rework against the benchmark: an early sign of process and specification problems
All six answered: five with primary evidence, and key-person dependency built from both.
Primary evidence
Contributing evidence
Not covered
Benchmark your engineering, on its own or as the first layer.
For a company that wants to know what its teams, its delivery partners and its AI tools actually deliver. Scored from the code itself, against 120,000+ engineers worldwide, with 24 months of history backfilled from Git.
Effective output against your industry
Your position against peer companies, quartile by quartile, by team and seniority.
Output mix
New features, rework, refactoring and removed code, month by month.
Waste rate
The share of effort that is reworked or removed. Healthy is below 30%.
Code quality, 0 to 10
Maintainability over time, against a global median of about 7.
Teams and partners side by side
Which teams and delivery partners lead or lag, and where the gap comes from.
AI adoption and its effect
Who uses AI, how maturely, and whether output rose or only activity did.
90%of tech professionals use AI at workGoogle DORA, 2025
−19%experienced developers were slower with AI, while believing they were 20% fasterMETR randomised trial, 2025
15–20%typical net gain from AI coding tools once the extra rework is subtractedStanford research, n = 2,562
Inventory first: 43% of one codebase was generated code.
Headcount says nothing about how big a codebase is. Before any analysis we count effective lines, without generated code, vendored dependencies, binaries and duplicates. That number fixes the scope and the fee.
572,440lines
Generated, 43%Tests
572,440 lines across 4 repositories and 4,994 files. This is the number most quotes are built on.
243,761 lines of generated ORM migrations and designer code: 43% of the raw total, set aside from sizing and from review.
46,888 lines of test code, counted on their own and reviewed for coverage, not for size.
281,791 effective lines. Sizing on the raw number would have overstated the scope by about 2×.
Backend, .NET 8 / C#153,9972,382 files
Frontend, TypeScript / React119,8562,129 files
Infrastructure, Terraform6,684131 files
AI search, Python1,25418 files
Anonymised output from a prior assessment, shown for the shape of the output and the sizing logic, not as a price reference.
Six areas, including the ones nobody asked about.
Architecture, security and DevOps are rarely on the request list. We include them because in a transaction that is where the expensive surprises sit.
Architecture
System design and boundaries, how modules and services fit together, data and integration flows, and drift from the intended design.
Code quality
Complexity, duplication, coupling and cohesion, test volume and coverage, and technical debt costed in person-days.
Security
Application security, secrets and credentials, infrastructure, containers and pipelines, against OWASP ASVS.
Open source and IP
Direct and transitive dependencies, known vulnerabilities, licence classification and supply-chain risk.
People and ownership
Code-ownership concentration, bus factor by module, exposure to people who have left, and the contractor and in-house split.
Testing and DevOps
Test strategy and gaps, build reproducibility, pipelines and releases, and readiness to run in production.
Where the debt actually costs you.
Complex code nobody touches can wait. Simple code that changes every week is fine. The risk sits where complex code changes often and matters to the business, so that is where the remediation plan starts.
Billing and the payment webhooks lead: complex, changed every week, and where revenue is calculated.
Illustrative data. Tools such as SonarQube express debt as remediation minutes; we validate and calibrate those estimates rather than present them as fact.
Who the product depends on.
No assessment platform outputs this as standard, so we build it: every commit attributed to a person, ownership measured module by module, and the exposure to people who have already left. Choose who leaves, and see what is left uncovered.
ModuleBus factor
Billing1Covered
Pricing rules1Covered
Auth and sessions1Covered
Payment webhooks1Covered
API gateway1Covered
Data import1Covered
Reporting1Covered
Tenant admin1Covered
UI shell1Covered
Search1Covered
A module is at risk when the people still on the team hold less than half of its code. Bus factor: the fewest people who together hold more than half. Illustrative data. In an assessment every Git identity is mapped to a real person, and contribution is measured by content, not line count.
Every finding is validated, and arrives with its fix.
AI does not set the final severity. A qualified reviewer confirms the evidence, the impact and the remediation before a finding enters the register, and each one comes with an effort estimate, an owner and a deadline.
F-017Severity: HighP1Validated by a reviewer
Payment webhook signatures are not verified
Where
Payments service, webhook handler
Reference
CWE-347, OWASP API Security Top 10
Scenario
A forged callback can mark an unpaid invoice as paid.
Business impact
Revenue leakage and audit exposure across every tenant.
Fix
Verify the provider signature and timestamp before processing, and reject replays.
Relationships in the code are parsed into a knowledge graph, so questions about reach, blast radius and hotspots are answered by traversal rather than opinion. Graph, tool output and human review together carry a finding.
Nine analyses run over the graph
Structure
Circular dependencies
Fan-in and fan-out
Critical components
Change risk
Blast radius of a change
Architecture drift
Churn and complexity hotspots
Exposure
Cross-service data flows
Reachable vulnerabilities
Unused or orphaned code
Tooling includes Joern, CodeQL, Tree-sitter, Graphviz and SonarQube, with our own validation on top.
How a security finding is reached
Automated static analysis and secret scan
Entry points and sensitive sinks
Control-flow and data-flow tracing
Manual check that it can be exploited
Business-impact assessment
CWE and OWASP mapping
Remediation guidance
OWASP ASVS is the baseline for technical security controls where it applies.
Ten business days from access to readout.
Both layers run in parallel and land together, alongside the wider diligence. Day 0 starts when read-only access and the security approach are confirmed.
012345678910+1 month
Engineering benchmark
Secure setup
Data collection and identity mapping
Benchmarking and analysis
Insights and report
Dashboard and questions
Code assessment
Scope and security approval
Inventory and build baseline
Automated scans
Graph analysis
Manual deep dive
Validation and prioritisation
Reporting and secure deletion
By the end of this dayReadout. Access revoked, and deletion of the code confirmed in writing.
What you receive
For the deal team or the board
Executive assessment report
Benchmark: quartile position against industry and global peers
Remediation roadmap with total effort and indicative cost
Management readout deck
For the engineers
Detailed technical report
Findings register in Excel and CSV: severity, priority, references, effort, owner
Key-person dependency analysis
Architecture and dependency diagrams
For compliance and closing
Software bill of materials in CycloneDX and SPDX
Open-source licence and vulnerability matrix
Raw tool outputs on request
Written confirmation that the code was deleted
Acceptance is the delivery of the agreed artefacts and the readout: never a minimum number of findings, and never a promise that no vulnerabilities exist.
Done inside a live capital raise.
Technical due diligence for a deal adviser on a cybersecurity scale-up raising growth capital. Every Git identity was mapped to a real person and team; output, quality and rework were scored across 24 months; and teams and individuals were placed in quartiles against the benchmark.
A read-out and dashboard the deal team could stand behind, delivered on scope and accepted in full. Names removed.
engineering contributors analysed
250–350
of commit history backfilled
24 months
engineers in the benchmark dataset
120,000+
The code stays where its owner wants it.
Built to answer the owner’s objection before it is raised: the code never leaves a controlled environment, and its deletion is evidenced.
The owner chooses where it runs
Inside their own VPN, virtual desktop or private cloud, an audit workspace they control, or an isolated environment of ours.
Read-only, named and revocable
Access is read-only, limited to named reviewers, logged, and can be withdrawn at any time without notice or explanation.
Nothing leaves without approval
No code goes to an outside service without written approval. On request, the assessment runs with no external AI model at all.
Deletion, confirmed in writing
Copies, derived databases and working files are deleted at close-out. Our delivery partners hold ISO 27001 and SOC 2 Type II.
To begin, the minimum is a read-only access token to the repositories.
What it is not
A source code assessment is not a penetration test, a legal opinion or a full production-security audit. Each of these can be scoped separately:
Penetration testing and dynamic testing
Cloud and infrastructure configuration audit
AI model performance, fairness and bias validation
Remediation of what we find
Re-assessment after remediation, to evidence closure
Engineering monitoring after the deal
Licence risk is identified and classified; the legal opinion stays with counsel.
A fixed fee, sized by the inventory
The fee is set by effective lines of code, repositories, languages and deployable services, never by headcount. If the codebase turns out materially larger, we agree a change before the work expands, never an invoice afterwards.
To scope it, we need
Repository count, rough size and language mix
Dependency manifests, which can be shared before access
An architecture diagram or a list of deployable services
Whether the product runs its own AI model or calls an external one
Contributors, with role and contractor or employee status
Checking one live AI application rather than a platform? The Express Audit takes about a week. See the Express Audit
The questions partners ask first.
Straight answers. Ask us anything else on a call.
Can the benchmark or the code assessment run on its own?
Yes. The engineering benchmark can run on its own for a company that wants to know what its teams, partners and AI tools deliver, and the code assessment can run without the benchmark. Together they answer more questions, as the map above shows.
Does the code leave the owner’s environment?
No, unless the owner approves it in writing. The assessment can run inside their own VPN, virtual desktop or private cloud, access is read-only and can be withdrawn at any time, and copies are deleted at close-out with written confirmation.
Is it a penetration test or a legal review?
Neither. It reviews the source code, architecture, dependencies and how the team works. Penetration testing, a cloud configuration audit and a legal opinion on licences or IP can be scoped separately.
How is the fee set?
Fixed, against the effective size of the codebase found by the inventory: repositories, effective lines of code, languages and deployable services. A materially larger codebase means a change agreed before the work expands.
Who signs with the client?
You do, when you are the adviser. We contract with your firm, and the reports are written to go straight into your deliverable.
Know what is in the code before you sign for it.
Tell us what you are buying, funding or taking over, and when you need the answer. We will size it from the inventory and come back with a fixed fee.
If you accept, HubSpot sets cookies for analytics, our chat and the booking calendar. If you reject, the site works the same without them. You can change this any time under Cookie settings.
