Running agile delivery inside a fixed budget
Fixed budgets and iterative delivery are compatible if scope is the variable. Fixing all three is what causes trouble.
ZooBieDoo Infotech Engineering TeamRead
Key takeaways
- Code quality is remediable; knowledge concentration is not.
- Key-person risk is visible in commit and review data.
- Licensing and provenance findings are cheap to check and material.
- A useful report ranks findings and includes the counter-argument.
It is mostly not about the code
Founders preparing for diligence tidy the codebase, which addresses a fraction of what is assessed. Code quality is remediable with money and time, both of which an acquirer has.
What is harder to remediate, and therefore more consequential, is concentration of knowledge, licensing exposure and a delivery organisation that cannot ship without specific individuals.
Key-person risk moves numbers
The question asked early is: if one named person left tomorrow, what stops working, and how long until it is understood again?
This is visible in commit distribution, code review participation, on-call history and documentation. It is usually apparent in the data before anyone says it aloud.
Licensing, provenance and scaling economics
- Dependency and licence audit — copyleft licences in proprietary distribution, abandoned upstream packages.
- Code of uncertain provenance, including AI-assisted contributions and how they are reviewed.
- Unit economics — does cost per customer fall with scale, or rise?
- Multi-tenancy — retrofitting it onto a single-tenant design is among the most expensive remediations there is.
What a useful report contains
Findings ranked by severity with evidence and indicative remediation cost. A ninety-day plan for a new owner. An assessment of the team and its concentration. And a recommendation that includes the case against it.
An assessment that argues only one side is not an assessment. The boundary matters: diligence should report what the technical evidence supports, not advocate for the transaction.
Preparing your own organisation
Companies expecting investment or acquisition benefit from assessing themselves first, because the findings are far cheaper to address before someone else finds them.
- Document the architecture and the significant decisions behind it.
- Run a dependency and licence audit and resolve what you can.
- Reduce key-person concentration through documentation and shared ownership.
- Ensure access, secrets and infrastructure are managed rather than personal.
- Be ready to describe known debt honestly, with a plan.
Acquirers price uncertainty more harshly than known, quantified problems. Concealment discovered during diligence damages trust across the whole transaction.
Frequently asked questions
Typically two to three weeks for a mid-size codebase, depending on how ready the documentation and access are. Data-room readiness is usually the limiting factor.
Architecture documentation, dependency and licence inventory, access for read-only code review, incident history, and honest answers about known debt. Concealment found later is worse than the debt itself.
No. Every codebase has findings. What matters is that they are understood, costed and not concealed acquirers price uncertainty more harshly than known problems.
