How To See Inside An Acquired Codebase In Five Days

The engineer who is the only one who knows

Imagine a CIO who started her new job three weeks ago. The company she joined had just closed on a mid-market distributor, and the deal team's technical checklist had rated key-person risk as low: 14 contributors across the codebase. On Monday, the finance lead asks her a simple question: who maintains the nightly job that calculates customer rebates? She checks the repository. One contributor, Dennis, has written nearly every line of that module over eleven years. He gave notice on Friday. Nobody had asked about rebates during diligence, because rebates were not on the checklist. Fourteen people had touched the codebase. One person understood the part that moves money.

This story is fictional, but the struggle is not. This example highlights many issues that our clients have shared with us throughout the years.

A contributor count measures who committed code, not who understands it. Key-person risk is a question about specific systems and the specific people behind them, so this method ties every finding to a system, a business process and a named person.

This article draws on our experience running Blueprint.IQ engagements. Blueprint.IQ is Sparq's AI-assisted code review service for acquired and inherited software. It reads a repository's current files and produces ranked findings, a draft map of the system and AI-assisted summaries of what each major module does in business terms. It does not build the repositories it examines. Instead, each engagement starts by setting up a development environment with all the SDKs and frameworks the code needs, and by asking the client about their plans for the application, including modernization goals and developer experience needs. Everything below reflects what we have seen work.

This article covers how the sprint is run, what comes out of it, and what it cannot tell you. Blueprint.IQ takes 4 to 6 hours to produce findings for a single repository. Multiply that by the number of repositories in scope to estimate total time. The classic "five days" framing holds for a reasonable number of repositories; a larger scope takes longer.

What five days gets you, and what it does not

Total time depends on how many repositories are in scope: for a reasonable number, findings fit within roughly five days, and a larger scope takes proportionally longer. What those hours produce are findings, a ranked shortlist and a draft map. Validation (confirming findings with the engineers and business owners, confirming that the development environment setup gaps have been resolved, verifying that generated summaries are correct) continues after findings are delivered.

Answer these questions before you read any code

A codebase review without a stated destination produces a list of observations, not a ranking. The same finding can sit at opposite ends of the priority list depending on the plan: a monolith is a critical blocker if the strategy calls for splitting services within twelve months, and a minor footnote if the system is being retired after migration. An end-of-life framework is urgent on an internet-facing revenue system and far less pressing on an internal tool scheduled for replacement. A missing test suite matters enormously if the team needs to refactor aggressively and barely at all if the code is being frozen. The questions below give reviewers the yardstick for deciding what matters before they start reading.

Answering these questions late creates rework. Findings get re-ranked after the fact, recommendations are revised once constraints surface, and the review team ends up revisiting conclusions that would have been framed correctly from the start. The questions take a short, focused session to answer. The cost of skipping them shows up later.

We put these same questions to the client at the start of every Blueprint.IQ engagement, but they work for any team, internal or external, reviewing an acquired or inherited codebase, and they can be answered in a single working session with the deal team, the CIO or CTO and the business owner.

Setup -- these define the target the code will be judged against.

• What frontend approach is envisioned?
• What should deployment look like (cloud, containers, hosting)?
• Which architecture patterns should the system move toward?
• Which developer experience improvements matter most?
• Any hard constraints on the target?

Strategic roadmap -- these define the business context and the limits on what any recommendation may do.

• What business objectives does this system support?
• Which numbers do its funders watch?
• What do users complain about or work around?
• What is the organization's position on AI?
• Can anything else reach this system's data today?
• Any hard limits on what it may do?

Any question the team cannot answer before the review begins should be written down as an open assumption in the review itself. That way the reader knows which findings depend on that assumption and which conclusions could change if the answer turns out to be different.

Run it as parallel workstreams, not a straight line

Ready to start the codebase review? We recommend a sprint that holds five workstreams run side by side and feed each other. The day labels below reflect a typical single-repository or small-scope engagement. Later work sends you back: a secret found late in the engagement reveals an integration missed earlier; a business owner's correction re-ranks a CVE from a prior workstream.

• Repository inventory (starts day 1, revisited throughout). Goal: enumerate repositories and read current file contents for language, framework and structure. Key-person mapping (identifying which engineers understand which modules) needs a separate review of commit history and conversations with the team. Output: repository register with stack and structure; key-person map assembled by human reviewers from commit history and interviews.
• Integration mapping (days 1 to 3, reopened as new evidence arrives). Goal: trace the API calls, queues, database links, scheduled jobs, scripts and file exports that each repository makes, and compare with whatever architecture diagram exists. Blueprint.IQ identifies the integrations and outbound API calls a repo makes; it does not determine which other programs or repositories call into it. Tracing callers is a separate manual step with the engineers who own those systems. Code alone also shows what is wired, not what is live: integrations that exist in code may be dead, and integrations that happen through manual file transfers or vendor-run processes will not appear. Output: system and data-flow map marked documented vs found only in code vs unconfirmed.
• End-of-life and vulnerability exposure (days 2 to 4). Goal: inventory frameworks, runtimes and libraries with versions, match against end-of-life dates and CVE databases, then prioritize by severity, internet exposure and reachability. Also include open-source license review: flag copyleft licenses, missing or unclear licenses and unusual third-party code, as an input for legal review not a legal opinion. Output: ranked EOL, CVE and license register.
• Secrets detection (days 3 to 4). Goal: scan current files, configuration and infrastructure-as-code for keys, tokens, passwords and certificates. Treat hits as candidates: each needs checking whether the credential is still active, and rotation is planned before networks are connected. Separately, check commit history for committed secrets. Output: list of exposed secrets with location and rotation steps.
• Business-logic capture and owner review (days 3 to 5, continues after). Goal: AI-assisted summaries of what each major module does in business terms (pricing, approvals, calculations, exceptions), linked to business processes. These summaries are a draft that accelerates understanding. They can be wrong or miss context, especially where logic is spread across modules, configuration or the database. Each summary for a revenue- or customer-critical process is reviewed with the business owner and a senior engineer before anyone relies on it. Output: business context documentation and code health scorecard (architecture, security, developer experience, tech stack, infrastructure).

Can it build and run?

Reading code is not the same as running it. Blueprint.IQ does not try to build the repositories it examines, but it does set up a complete development environment for each in-scope system, with every SDK and framework the repo uses installed and configured to support the technologies in question, so the analysis runs against the real toolchain. Gaps found while assembling that environment (unpinned or undocumented SDKs and versions, dependencies on retired or unavailable services, setup that exists only in someone's head) are recorded as findings. Our accelerator also works to understand the client's intentions for the application, including modernization plans and developer experience requirements, so that findings and recommendations are shaped by where the system is headed, not only where it stands today.

Start with the 5 to 10 findings that matter

A full run can produce 70 to 100 findings, and a list that long is a cost to the reader. The executive view is the 5 to 10 that change a decision.

Each finding is scored on: (1) business criticality of the system it touches, (2) likelihood and severity of harm (exposure, exploitability, active credentials), (3) cost and time to fix, (4) dependence on a single person or vendor, (5) whether it blocks integration.

The remaining findings live in an appendix, grouped by system.

Connect every system to a business process

A finding without a process attached cannot be ranked. Ask for a named business owner per key process at scoping, and make that person an active participant: a working session on day 2 or 3 to confirm which systems are revenue- or customer-critical, and a review on day 5.

For each key system, record:

• System (the application or job)
• Business process it supports
• Critical to (revenue or customer)
• What breaks if it is touched
• Business owner
• Key person (who actually understands it)

This record is where key-person risk becomes visible: a system that is critical and depends on one person goes to the top of the list.

Pre-close and post-close are different jobs

Findings pre-close are based on partial access and should be labelled that way.

Before day one: scope and safety

• Read-only access in an isolated non-production environment.
• Agree what is out of scope (customer data, production credentials).
• Name the business owners and the key engineers to interview.
• Data handling: say where code goes when AI processes it, which providers, that code is not retained and not used for model training, and that the code stays within the agreed environment.
• Treat every finding as a recommendation for senior developer review, not an automatic change.
• Production systems are not touched.

What this won't tell you

• Org health: morale, attrition risk, whether the team will stay, how decisions get made.
• Vendor contracts: licenses, renewal dates, termination terms, change-of-control clauses.
• Data quality: code shows how data is handled, not whether the data in the tables is accurate or complete.
• Manual processes outside the code: spreadsheets, vendor-run jobs, tribal workarounds.
• Runtime behaviour and performance under load.
• Anything in repositories you were not given.

Pair the sprint with interviews and a contracts and data review.

After the sprint: fix, retire, modernize or rebuild

What it does to price, escrow and sequencing

Findings can support a price adjustment, a specific escrow or holdback tied to remediation, indemnity for known issues such as an undisclosed license problem, or conditions to close. Remediation cost estimates should be ranges with stated assumptions. Integration sequencing follows risk: rotate secrets and patch critical exposure first, then connect networks, then consolidate. These terms are for the deal and legal teams to decide; the sprint provides the evidence.

A sample 30/60/90-day plan based on our experience

How this compares to a manual code audit

Want to see what Blueprint.IQ would find in a codebase you are about to inherit? Talk to us about Blueprint.IQ.