Product Strategy & Technical Due Diligence
Strategy & technical due diligence
Know what to build, and what you are buying, before the budget is committed.
- Discoverywhat to build
- Roadmapsequenced & costed
- Technical due diligencefor investors
- Architecture & risk reviewof what you run
- Build vs buyclear calls
Why teams bring us in
Three situations account for most of the calls we take.
The board wants a number nobody can defend
A funding request goes up, and the first question back is what it costs to get through the next two years. The engineering answer sits in three heads and one spreadsheet. We turn that into a costed sequence with the assumptions written out, so the number survives the second question.
The roadmap is a list of feature requests
Sales asked for one thing, the largest client asked for another, and the backlog grew into a queue with no thesis behind the order. Nothing in it maps to a business outcome. We re-cut the sequence against outcomes you can measure, and we say out loud what gets dropped.
The acquisition is priced on a demo
The product works in the meeting. What sits behind it might be a rewrite waiting to happen, a single contractor holding the payment logic, or a licence that follows the asset into your group. Our review reads the repository, the infrastructure, and the team shape, then scores what we find.
Discovery and framing
We spend the first stretch establishing what exists rather than what people remember.
Where the money and the risk sit today
We start with the parts of the system that carry money, customer data, and a regulator's attention. Interviews with engineering, operations, and compliance get cross-checked against the code and the incident history, because the story in the room and the story in the repository rarely match exactly. The output is a written map of what exists and what it costs to run.
The problem statement, agreed in writing
Teams often carry two or three competing versions of the problem, and the disagreement only shows up halfway through a build. We write one statement, name the user, the constraint, and the measure of success, then circulate it until the people who fund the work sign it. Short document. It kills a surprising amount of later rework.
Constraints that decide the design
Licence terms, data residency, an incumbent core banking contract, a payment scheme rule, the settlement window your operations team lives inside. These get logged early as hard constraints with a source attached, since a design that ignores one of them fails late and expensive. Items still unresolved go on the register as open questions with an owner.
Strategy and roadmap
The plan has to survive a budget conversation, so it carries outcomes, costs, and named trade-offs.
A roadmap tied to outcomes
Each block on the plan carries the outcome it serves, the measure that proves it, and a rough cost band. Where two blocks compete for the same quarter, the tie breaks on outcome rather than on who asked loudest. The plan stays short enough to read in one sitting, and we revisit it when the evidence moves.
Build versus buy, with the numbers shown
We model total cost of ownership across the options, three years out, including licence fees, integration work, the engineers you would need to hire, and the exit cost if the vendor disappoints. Vendor scoring runs against the same constraint register from discovery. You get the model as a spreadsheet you can re-run with your own assumptions.
Architecture direction, recorded as decisions
The direction gets written as architecture decision records, one per choice, each with the options considered and the reason the others lost. Six months later a new engineer can read why the ledger is event sourced instead of asking around. We keep the set small and tied to the roadmap blocks that depend on each decision.
Technical due diligence
Four areas where deals get repriced after the engineering read comes back.
Code and architecture review
A code and dependency audit covers structure, test coverage, the state of the build, and what the commit history says about how the team works. Dependency versions get checked against published advisories, and licence terms get read. Where the target was priced on a demo, this is the part that turns up the deferred work nobody mentioned in the meeting.
Scalability and cost ceilings
We estimate the scalability ceiling, the point where the current design stops holding transaction volume without a rewrite, and we put the cloud bill at that volume next to it. Load evidence comes from production metrics where they exist and from a reading of the data model where they do not. Both numbers land in the report.
Security and compliance exposure
Findings cover authentication, secrets handling, data segregation, audit trails, and how close the current control set sits to what a regulator would ask for. Licence and compliance exposure gets its own section, because an inherited copyleft dependency or a missing data processing agreement changes the price of the deal. We report engineering risk. Legal counsel reads it from there.
Team and key-person risk
One engineer often holds the reconciliation logic in their head, undocumented, with no second pair of eyes on it. We map key-person risk against the parts of the system that matter most, look at hiring history and attrition, and check how much of the knowledge lives in writing. Retention terms in the deal usually change after this section.
How we work
Evidence, delivered while it can still change the decision.
Presales engineering
The engagement is scoped to the decision you face, not to a template. A diligence for an acquisition and one for a partnership ask different questions.
Evidence over interview
We read the code, the pipelines, the incident history and the dependency tree. Interviews tell you what people believe, the repository tells you what is true.
Findings as you go
Anything that changes the decision reaches you immediately rather than in a final report two weeks later.
A verdict, in writing
Including a recommendation not to proceed, when that is what the evidence says.
Read the codebase before you price the deal
A short engineering assessment gives you a scored risk register and a written report your investment committee can question line by line.
What you get
Written assessment report
One document, structured so a non-technical reader gets the picture in the first two pages and an engineer gets the evidence in the rest. Findings carry severity, the reasoning behind them, and what it would take to fix. No slide deck standing in for the work.
Scored risk register
Each finding sits in a register with likelihood, impact, a remediation estimate in engineering weeks, and an owner. It sorts, so the board sees the top five without reading the appendix. The register stays useful after the deal closes as the basis for a remediation plan.
Roadmap with cost bands
A sequenced plan where each block names its outcome, its measure, and a cost band you can take into a budget conversation. Dependencies between blocks are marked, along with the ones that hinge on a hiring decision or a vendor contract still being negotiated.
Architecture decision records
The decisions we recommend, written one per file in your repository, each recording the options weighed and why the rest lost. Your team inherits the reasoning instead of the conclusion, which matters when the constraint that drove a choice changes two years later.
Where this works best
The most expensive engineering decisions are made before any engineering starts.
Talk to the team who would build itGood fit
An investment, an acquisition, or a platform decision large enough that being wrong about it is expensive.
Not a fit
A rubber stamp for a decision already made. We will write what we find, which is the point of asking.
Questions
The questions that come up most in the first call.
How long does a technical due diligence review take?
It depends on the size of the codebase and how much access we get. A focused review of one product with repository access and two or three engineer interviews moves quickly. A group with several acquired systems and no documentation takes longer, mostly because we spend the first stretch working out what exists. We scope it in writing before starting, with a fixed fee.
Do you give investment advice or a valuation?
No. Oxagile is an engineering vendor, so our report covers what the technology is, what shape it is in, and what it would cost to fix or extend. Those inputs feed your own valuation work. Your investment committee, your advisers, and your counsel make the call on price and terms. We stay on the engineering side of that line.
What access do you need from the target company?
Read access to the repositories, a walkthrough of the production environment, and time with two or three engineers who built the thing. Architecture diagrams and incident logs help when they exist. Where a seller limits access, we say in the report which findings rest on evidence and which rest on inference, so you know how much weight each one carries.
Can you do the strategy work without building anything afterwards?
Yes, and a fair share of this work ends there. The report and the roadmap are yours, written so an in-house team or a different vendor can pick them up. Some clients come back for the build once the plan is funded, which is fine, though the assessment is priced and delivered as its own engagement.
Our roadmap already exists. What would you change?
Often the sequence rather than the content. Most roadmaps we read are a queue of requests with no stated outcome per item, which makes trade-offs impossible to argue about. We attach an outcome and a measure to each block, mark the dependencies, and flag the items that duplicate something a vendor already sells. Sometimes the answer is that the plan holds.
Part of Lending
Credit decisions your team can make in minutes and defend for years.
Underwrite faster,
without the manual read.
Bring us the bottleneck, whether it is decisioning, document processing or servicing, and we'll scope the system that clears it.