Independent technical judgment for important business decisions.
For investors, boards and executives who need a clear, honest answer about technology - from people who build these systems rather than only review them.
ProjectData provides technical due diligence, architecture reviews, technology and AI strategy, technology investment reviews, and fractional CTO support. Engagements are advisory: we form a view, explain the reasoning, and say plainly where we are uncertain.
What we are asked to assess.
Most engagements start with one question that a spreadsheet cannot answer: is this technology worth what is being paid for it, and will it survive the plan?
-
Technical due diligence
An independent assessment of a target's technology, engineering organisation and the investment required after close - written for an investment committee, not for engineers.
-
Architecture reviews
Whether the current architecture supports the next stage of the business, what will break first, and what it would cost to address before it does.
-
Technology strategy
Build-versus-buy decisions, platform direction, sequencing and the technology investment a business plan actually implies.
-
AI & data strategy
A realistic view of where AI and data create value in a specific business, what the current data foundation supports, and which initiatives are not yet feasible.
-
Technology investment reviews
Assessment of large technology programmes in flight: whether the plan is credible, whether the spend is proportionate, and what the realistic completion picture looks like.
-
Fractional CTO / technology advisor
Senior technical judgment on a recurring basis for founders, boards and portfolio companies that need it regularly but not full time.
What a technical review examines.
Depth is set by the decision at stake and the access available. Scope is agreed before we start.
- Architecture
- Structure, coupling, key design decisions and whether they fit how the business actually makes money.
- Scalability
- Where the system breaks as volume, users or data grow - and what that costs to fix in time and money.
- Technical debt
- What has accumulated, what it costs in delivery speed today, and which parts are genuinely worth servicing.
- Cloud infrastructure
- Environment design, operating cost and cost trajectory, resilience and dependency concentration.
- Engineering organisation
- Capability, structure, key-person risk and whether the team can deliver the plan being underwritten.
- Delivery process
- How changes reach production, how often they fail, and how quickly problems are detected and resolved.
- Data architecture
- What data exists, how it is modelled and governed, and whether it can support the commercial plan.
- Security posture
- A high-level practitioner view of practices and evident risks - not a formal audit, certification or penetration test.
- Roadmap realism
- Whether the stated plan is achievable with the team, architecture and budget available.
- Investment requirement
- The technology spend the next stage implies, separated into necessary, deferrable and optional.
What you get, and what you don't.
What you get
- A written assessment with a clear position, not a scored checklist
- The reasoning behind each conclusion, so it can be challenged
- Explicit statements of uncertainty and what access would resolve them
- Findings separated by severity and by what they would cost to address
- A direct conversation with the reviewer, not an account manager
Advisory questions.
What does a technical due diligence review cover?
Typically: architecture and how well it fits the business model, scalability and the cost curve behind it, technical debt and what it would take to service, cloud infrastructure and operating cost, the engineering organisation and key-person risk, delivery process and release reliability, data architecture and how data is used commercially, high-level security posture and practices, roadmap realism against the stated plan, and the technology investment required to reach the next stage.
We do not perform formal security audits, penetration testing or regulatory certification, and we do not present our findings as any of those.
How is this different from a consultancy's technology assessment?
The reviewer is a practitioner who builds these systems rather than a generalist working from a framework. The output is a judgment - what we would be comfortable with, what we would not, and what we would want changed - supported by evidence, not a maturity score.
We also state clearly where we could not form a view, and what access would be required to form one.
Can you work under a deal timeline?
Usually. Scope, access to the team and the depth required determine how long a review takes. We will tell you at the outset what can credibly be assessed in the time available, and what would need a longer engagement.
Do you work with portfolio companies after an investment?
Yes. Post-investment work usually takes one of two shapes: a specific remediation or build programme, or ongoing advisory and fractional CTO support for a team that needs senior technical judgment without a full-time hire.
Where we have acted as diligence advisor on a transaction, we discuss the conflict question openly before taking on continuing work.
Need an independent view before a decision?
Tell us what is being decided and by when. We'll tell you what can credibly be assessed in that time.