Picking Up the Scent

The CTO’s message was three lines: “I need someone to tell me the truth about our stack. Board meeting in four weeks. Can you start Monday?”

She wasn’t looking for a consultant to validate her decisions. She was looking for someone to pick up a scent that months of financial due diligence hadn’t found: the real state of the engineering behind a Series B fintech company processing eight figures in monthly volume. The dashboards were green. The investors were happy. But she’d been around long enough to know that green dashboards and healthy systems aren’t always the same thing.

I said yes. What I found in two days changed how she talked about engineering to her board.

Preparing for your own review? Start with the Technical Due Diligence Red Flag Checklist, then follow the trails below for context.

The Pointer Assessment: An Engineering Risk Map

Every technical due diligence engagement is different. The stack, the stage, the pressures all vary. But after dozens of assessments, I’ve developed a repeatable methodology: five trails that reliably expose the real state of engineering health. I call it The Pointer Assessment, the diagnostic phase that turns evidence into a prioritized risk map and remediation discussion. A good pointer doesn’t chase every noise in the field. It locks onto a scent and follows it to the source. These five trails do the same thing for a codebase.

Trail 1: Follow the Prints — Deployment and Pipeline Health

Deploy frequency, pipeline health, the gap between what leadership claims and what the git log actually shows. If a team says they ship weekly but the deploy history tells a story of monthly batches followed by scrambles, something’s wrong. The prints don’t lie: the commit history, the CI pipeline, the release tags. Follow them and you’ll know whether the team can actually ship.

Trail 2: Sound the Alarm — Recovery and Incident Readiness

Everybody has a disaster recovery plan. The question is whether they can execute it under pressure. Rollback capability, incident response muscle memory, the production-is-down drill. When something breaks at scale, do they have a tested playbook, or do they have a phone tree and a prayer? This trail separates teams that have drilled for disaster from teams that have only planned for it.

Trail 3: Run with the Pack — Onboarding and Knowledge Distribution

How long before a new hire ships meaningful work? Is the knowledge in documentation or locked inside one person’s head? Can someone who didn’t write the code understand it well enough to change it safely? A team that can absorb new engineers and scale without fragmenting is a team that can grow. One that can’t is carrying a risk nobody’s pricing.

Trail 4: Find the Fence — Architecture Headroom and Scaling Limits

Architecture headroom, database strategy, the next ceiling. Every system has a fence — a boundary it can’t grow past without significant rework. The question is whether the team knows where the fence is, how close they are to it, and what it will cost to move it when the time comes.

Trail 5: Flush the Undergrowth — Hidden Technical Debt

This is the trail that matters most. Tech debt that never made it to a roadmap. The “don’t touch that” zones. The things engineers whisper about in standups but never escalate. Every codebase has undergrowth: problems hiding beneath the surface, slowly spreading. Flush it out, and you know what the team isn’t tracking. Miss it, and you’re buying blind.

Red Flags That Kill Deals

At the Series B fintech, the first three trails of the engineering-health review looked reasonable. Follow the Prints showed semi-automated deploys. Sound the Alarm revealed incident response that existed, if untested. Run with the Pack indicated onboarding was slow but improving.

Then I ran Find the Fence and Flush the Undergrowth, and the scent led somewhere nobody expected.

Manual production deploys. The CI pipeline built and tested the code, but the final step, pushing to production, was a shell script run from one engineer’s laptop. He’d been doing it for two years. Nobody else knew the sequence. If he got sick on deploy day, the company couldn’t ship.

PCI scope creep. Card data was appearing in places it shouldn’t: application logs, a staging database that wasn’t behind the same controls as production, an analytics pipeline that ingested raw transaction payloads. The team didn’t know the data was there. They’d never audited the full data flow.

No tests on the money path. The core transaction processing code — the part that moved actual money — had zero automated tests. Validation was manual: an engineer would run a few test transactions and eyeball the results. At eight figures in monthly volume.

These aren’t character flaws. They’re what happens when you ship fast under pressure with a small team. But for anyone evaluating this company (board members, investors, acquirers), these are deal-killers until they’re fixed. The CTO suspected some of this. My job was to confirm it and quantify what remediation would cost.

Yellow Flags: Negotiation Leverage

Not everything I found was a red flag. Some findings were yellow: not deal-killers, but quantifiable risk that affects how the company is valued.

Single-database architecture. Everything (users, transactions, ledger entries, audit logs) lived in one PostgreSQL instance. It worked today. At their current growth rate, they’d hit a performance ceiling in roughly eighteen months. Migrating under load is expensive and risky. That’s a line item on a remediation budget.

Key-person dependencies. Two engineers effectively owned the payment gateway integration and the reconciliation system. Both were senior, both were happy, but neither had documented their work in a way that someone else could maintain it. The scent of institutional knowledge was fading but not yet cold, still recoverable, but only if you act before those engineers move on.

Stale dependencies. Fourteen packages were more than two major versions behind, including two with known security advisories. Not urgent, but measurable remediation cost: roughly three to four engineering weeks.

What “Good” Looks Like

Here’s where most technical DD content gets it wrong. They describe a perfect engineering organization and imply everything else is broken. That’s not useful. “Good” is stage-dependent.

Seed / Series A: Duct tape is expected. Good means conscious trade-offs: the team knows what shortcuts they took and has a rough plan for when to fix them. Bad means surprised faces when you point out the shortcuts.

Series B: CI/CD should exist and work. There should be some test coverage on critical paths, especially anything touching money or sensitive data. PCI scope should be understood, even if not perfectly contained.

Growth / Pre-acquisition: Operational maturity. Incident playbooks that have been tested. Deployment that doesn’t depend on one person. Documentation that a new hire can follow without a tour guide.

Good doesn’t mean perfect. Good means the team knows where the problems are, has a credible plan to address them, and can articulate both to a board or an acquirer.

The Two-Hour Codebase Tour

When time is short and stakes are high, here’s the sequence I follow. You’re not reading the codebase. You’re tracking through it.

First 15 minutes: git log. Deploy frequency, number of contributors, PR sizes, branch lifetimes. History tells you more than code. A team that deploys daily with small PRs has different health than one that deploys monthly with thousand-line merges, regardless of what the code looks like.

Next 15 minutes: the build. Clone the repo, build it, run the tests. What breaks? How long does it take? Can you do it from the README alone, or do you need tribal knowledge? If a senior engineer has to walk you through the build, that’s a signal.

Next 30 minutes: follow the money. Pick the most critical transaction path and trace it end-to-end. Where does data enter? How is it validated? Where is it stored? How are errors handled? Look for hardcoded assumptions, missing error paths, and coupling between domains.

Next 30 minutes: the edges. Authentication, authorization, data storage, logging. Where does sensitive data live? Is it encrypted at rest? In transit? Are there secrets in the codebase? What gets logged, and does any of it contain PII or card data?

Final 30 minutes: operations. Dockerfile, CI config, alerting rules, monitoring dashboards. Can the team see when something is wrong before customers tell them? Is the infrastructure reproducible, or is production a snowflake?

Two hours won’t give you certainty. But it will give you a map of where to dig deeper, and in due diligence, knowing where to dig is most of the value.

Technical Due Diligence Red Flag Checklist

Use this as a starting map, not a pass/fail scorecard. For each item, record the evidence reviewed, the finding, and who owns the next step. Missing evidence means unverified, not proof of failure; a demonstrated failed recovery or exposed card data is a confirmed finding. Assess its impact against the company’s stage, obligations, and critical business paths.

  • Trace a real deployment. Compare recent release history with the claimed cadence. Ask who can deploy and roll back; investigate any step dependent on one person’s laptop or memory.
  • Ask for recovery evidence. Review the latest restore or rollback drill and incident follow-up. A written plan without an execution record leaves recovery capability unverified.
  • Follow the money path. Trace a transaction from entry to settlement or reconciliation. Inspect automated tests for validation and error handling; record any critical behavior that relies only on manual checks.
  • Map sensitive-data flows. Follow card data and PII through services, logs, staging, and analytics. Check the controls at each destination and investigate any copies outside the documented scope.
  • Test knowledge transfer. Ask a non-author to build from the README and explain a critical integration. Identify systems that still depend on one engineer and the documentation or pairing needed to reduce that dependency.
  • Check scaling assumptions. Request workload measurements and the evidence behind capacity forecasts. Record shared-database dependencies and the next likely bottleneck; an unsupported forecast is not proof that the system cannot scale.
  • Inspect dependency risk. Review outdated packages and known security advisories for applicability. Ask for an owner and a remediation estimate rather than treating version age alone as a deal-killer.
  • Turn findings into decisions. Separate confirmed high-impact risks from evidence gaps and planned improvements. Capture business impact, remediation effort, and unresolved questions for the board or investment discussion.

The checklist tells you where to pick up the scent; technical due diligence follows the evidence across those boundaries. If you’d like a second pair of eyes, let’s discuss your findings—including what you still need to verify.

The Fintech Difference

Technical DD in fintech differs from general software assessment. The trail that financial DD can’t follow is the one that costs the most.

Regulatory compliance debt is invisible on balance sheets but costs millions to remediate. A startup that’s been operating outside PCI scope, unknowingly storing card data in logs and processing it through uncontrolled environments, faces a remediation timeline measured in months and a cost measured in engineering-years.

Data lineage matters in ways it doesn’t in other industries. Can the company prove where every piece of sensitive data goes? The answer can’t be “we think it stays in the database.” Can they trace it through every service, every log, every analytics pipeline?

And there are licensing and certification transfer risks that affect deal timelines. Acquiring a company with a payments license is only valuable if that license transfers cleanly. Technical findings can complicate or delay that transfer.

The PCI issue at the Series B company wasn’t in any risk register. The team didn’t know it was a problem. The CTO was glad we found it before the board did, and before a potential acquirer’s diligence team did.

Key Takeaways

Technical DD is a hunt, not an audit. Checklists miss what matters most. The real findings come from following the trail: through git history, through data flows, through the gap between what leadership believes and what the codebase shows.

A useful engineering risk map is systematic. Five trails — Follow the Prints, Sound the Alarm, Run with the Pack, Find the Fence, Flush the Undergrowth — each exposing a different dimension of engineering health. Follow all five, and you have a credible picture.

Red flags versus yellow flags: Red flags are deal-killers. Unaddressed, they represent existential risk. Yellow flags are negotiation leverage: quantifiable issues that reprice the deal or extend the remediation timeline. Knowing the difference saves everyone time.

Stage-appropriate expectations: A Series A company with duct tape isn’t broken. A growth-stage company with duct tape is. The right assessment is calibrated to stage, not to some abstract ideal.

The fintech multiplier: Regulatory compliance debt, PCI scope, data lineage, and licensing transfer risk make fintech DD harder, and more consequential, than general software assessment. The issues nobody tracks are the ones that kill deals.

The Pointer Assessment is our diagnostic phase: an evidence-based risk map to guide priorities. The Chase is hands-on remediation alongside your engineers. The Unleashing transfers ownership through pairing, documentation, and practice running the work independently. Need an honest picture of your technical landscape? Let’s talk about what the codebase is really telling you.