Technical due diligence & prototyping
Independent assessment of existing systems, and rapid proofs of concept for new ones — founder-led engineering, no vendor agenda.
Last updated:Technical due diligence is an independent assessment of a software system's architecture, code quality, and risks — used to validate a build, inform an acquisition, or de-risk an investment. Revenant Systems delivers technical due diligence and rapid prototyping, from reviewing enterprise architecture to standing up a startup's first proof of concept.
Who commissions this, and when?
Founders validating their own build, boards sizing hidden risk, investors assessing a deal, and acquirers examining a target — anyone who needs an independent view of a system before money or reputation commits to it. The one engagement declined is the rubber stamp: the report says what the evidence supports, whoever that pleases.
What does an assessment cost?
Three published starting points, each fixed once scoped: a technical health review of architecture, code, and risk for your own board; transaction due diligence for an investment or acquisition, quoted higher where transaction-grade security testing or IP review is in scope; and a rapid working proof of concept. An AI-feature proof of concept is priced by the AI consultancy's feasibility sprint instead, from £4,500.
| Engagement | Price |
|---|---|
| Technical health review | From £8,000 |
| Transaction technical due diligence | From £15,000 Quoted higher where transaction-grade security testing or IP review is in scope. |
| Rapid proof of concept | From £10,000 |
Who makes the assessment?
Ian Compton leads the review, drawing on twenty years of software engineering and operational experience. Revenant Systems has no product to place and no stake in defending the target system. Findings are written for the commissioning team to act on; any implementation work is separately scoped and never assumed.
Ian Compton reads your enquiry personally. The usual next step is a free 20–30 minute technical fit call to check the problem, scope and likely budget.
Discuss an assessmentUK company and contracting entity · UK GDPR-aware delivery · Independent — nothing to resell · Reports written for your team to act on
What does technical due diligence assess?
Technical due diligence assesses whether a software system is sound: its architecture, code quality, scalability, security posture, and the risks that could threaten a roadmap or a deal. Technical due diligence produces an independent, evidence-based view for founders, investors, or acquirers.
Revenant Systems reviews systems it had no hand in building and no stake in defending, so the assessment reflects the codebase, not a vendor's incentives.
- Architecture and scalability review
- Code quality and maintainability
- Security and operational risk
- Infrastructure and cloud-spend review
- Team and delivery assessment
| Buyer | The question answered |
|---|---|
| Founder | Are we building this correctly? |
| Investor | Is this investable? |
| Acquirer | What exactly are we buying? |
| Board / CEO | What risk is hidden in the system? |
Can you prototype an idea before we commit to building it?
Yes — with a proof of concept: a focused, working build that tests the riskiest assumption before full investment. Revenant Systems builds rapid proofs of concept to validate a technical approach or a product idea, so teams can commit to a direction with evidence rather than guesswork.
- Validate the riskiest assumption first
- A working prototype, not slideware
- A clear build-or-stop recommendation
What's included
- Architecture and code review
- Risk and security assessment
- Written findings and recommendations
- Rapid proof-of-concept builds
Frequently asked questions
Who commissions technical due diligence?
Founders validating their own build, investors assessing a deal, and acquirers examining a target. In each case the output is the same: an independent, evidence-based view of the system's architecture, code quality, scalability, security posture, and the risks that could threaten a roadmap or a deal.
How independent is the assessment?
Fully. Nothing in the engagement depends on the outcome: there is no product to place and no delivery team whose utilisation a recommendation would protect. Where findings point to build work, that is scoped separately and never assumed.
What do we receive at the end?
Written findings and recommendations covering architecture and scalability, code quality and maintainability, security and operational risk, infrastructure and cloud spend, and team and delivery. Where a proof of concept is part of the engagement, you also receive the working prototype and a clear build-or-stop recommendation.
Can you assess a system nobody in-house understands?
Yes — that situation has its own fixed-scope package: the legacy system rescue assessment maps where the risk sits, what could take the business down, and what to stabilise first, delivered as a risk register and a first-90-days plan.
Does the assessment cover cloud costs?
Yes — infrastructure and cloud-spend review is part of the standard scope. Where spend is the primary concern, the fixed-scope cloud cost audit examines it in depth, from billing data down to the architectural decisions behind the largest line items.
Can you tell us what we own of software an agency built?
Yes, through a separate fixed-scope package. A health review judges the quality of the code and architecture; the technical ownership review establishes who holds the code, pipelines, and accounts, whether the product can be deployed without the supplier, and what to secure first.
Every engagement follows the same process — see how we work.
Need an independent view? Let's talk.
Get in touchIan Compton reads your message personally. The usual next step is a free 20–30 minute technical fit call to check the problem, scope and likely budget.