Technology Due Diligence
An independent review of software, architecture, team, security, scalability and technical debt before an investment or transaction decision.
Technology assurance
SaaS scale and data integrity review
A SaaS scale and data integrity review assesses whether a SaaS platform will scale and whether its reported subscription and revenue data reconciles with the underlying systems, covering architecture, resilience, security boundaries and data reliability.
Who uses this service
- Investors
- Whether the platform can carry the growth the plan assumes, and whether the subscription and revenue figures in the investment case reconcile with the underlying systems.
- Boards
- An independent view of resilience, single-point-of-failure risk and the technical debt position, before relying on management's account of the platform.
- Scale-up leadership
- Where the architecture and data will strain as usage grows, so investment can be planned before an outage or a reporting discrepancy forces the issue.
When to commission it
- An investment or funding round depends on the platform scaling, and that assumption has not been tested against the architecture and the engineering metrics.
- Reported SaaS metrics look unreliable, or the same measure is calculated differently in different systems and reports.
- A recent outage, or a concern about resilience and single points of failure, needs an independent assessment before it recurs at a larger scale.
- Subscription revenue does not reconcile with the product database, the billing system or the general ledger, and the cause is unclear.
- Rapid growth is straining the platform, and leadership needs to know what will break first and what investment is required.
Questions the review answers
Will the architecture scale to the growth the plan assumes, and what is the first constraint that will bind?
Do the subscription and revenue reports reconcile with the product database, the billing system and the ledger?
Where are the resilience and single-point-of-failure risks, and what is the effect of each on availability?
Are the security boundaries between tenants, environments and data stores sound?
What is the technical debt position, and what investment does it imply over the next 12 to 24 months?
Evidence normally requested
We request the evidence needed to test the technical position. The exact list depends on the matter.
- Architecture diagrams and a description of the main services, data stores and external dependencies
- Cloud accounts and configuration, including compute, storage, networking and identity settings
- Engineering and reliability metrics, including latency, error rates, deployment frequency and uptime records
- Subscription and billing data, including plan definitions, the product database and the billing system export
- Incident and outage records, post-incident reviews and relevant system logs
- Data model and pipeline documentation, including how subscription and revenue figures are calculated and moved between systems
- Security policies covering access control, tenant isolation, secrets management and change control
Method
Define the question and scope boundary
We agree the specific scalability and data integrity questions the review must answer, and record what is inside and outside scope so the work stays fixed and the output is usable.
Preserve and collect evidence
We collect the architecture, configuration, metrics and data extracts needed to answer the question, and record where each item came from so our steps can be explained later.
Test scalability and reconcile the data
We assess the architecture against the projected load, identify resilience and single-point-of-failure risks, and reconcile the reported subscription and revenue figures against the product database, billing system and ledger.
Rate risk and confidence
We classify each finding by risk and assign a confidence level of Confirmed, Supported, Indicative or Unknown, and we state the missing evidence behind any gap.
State the next action
We set out the practical next step for each material finding, including the investment or remediation it implies and who should own it.
What you receive
- Document
- Review report covering architecture, resilience and data integrity
- Intended reader
- The investor, board or leadership team relying on the platform, and their advisers where appropriate
- Risk classification
- Each finding is rated by risk, from material risk through to matters recorded for information only.
- Confidence classification
- Each finding carries a confidence level of Confirmed, Supported, Indicative or Unknown.
- Includes
- An executive summary stating whether the platform will scale, whether the data reconciles and the material risks
- An evidence appendix recording what was reviewed and what each item showed
- Data reconciliation notes setting out how the subscription and revenue figures compare across systems, with the differences found
- An action plan setting out each recommended step, its priority and who should own it
- Verbal briefing
- A verbal briefing to the instructing party is included, held after the written report is delivered.
Typical timing
Typically 2 to 4 weeks
Commonly excluded from this matter
- Broad technology due diligence: see Technology Due Diligence
- Code ownership and licensing: see Digital IP & Software Provenance
- Remediation and platform engineering: see Fractional CTO / CISO
Potential add-ons
The review covers the full agreed scope; it is bounded by the evidence made available and does not warrant that every discrepancy will be found. Where the decision needs more, the engagement can extend to include:
- Technology-perspective valuation of the business or platform: viability, value drivers and rebuild cost, as an input to a commercial valuation
- Penetration testing and deeper security assessment
- Reconciliation across additional systems or historical periods
- Full technology due diligence: architecture, security, team and technical debt
Definition
Clients sometimes describe the data reconciliation work as a data audit or a revenue audit. The engagement is an independent technical review. It is not a statutory audit and it is not a financial audit of the accounts.
Independence and reliance
We act as an independent reviewer. We do not hold a stake in the outcome, and we report what the evidence supports, including where it does not support the account given by management.
We handle evidence so that its integrity is preserved and our steps can be explained later. We record what we reviewed, where it came from and what it showed, and we state the limitations behind each conclusion.
We do not remediate or rebuild the platform we review. Keeping the review separate from remediation removes the incentive to overstate a problem in order to win the follow-on work.
Related services and reading
Fractional CTO / CISO
Senior technology leadership, risk and vendor governance, and board reporting on a defined engagement, kept separate from work we later assure.
Methodology
How we define scope, preserve evidence and assign confidence levels to each finding.
Independence
How we manage conflicts, handle evidence and keep the review separate from remediation.
Discuss a matter
Provide a short outline of the decision, transaction or dispute. Do not submit confidential source code, credentials or personal information through the form.