Decision Debt Is Killing Your Series A: How Missing Architecture Decision Records Cost More Than Technical Debt

You are six weeks into your new CTO role at a Series A company. The product works. Engineers ship. The stack is reasonable. But something is wrong and it takes you a few weeks to name it.

Every time you ask a “why” question, you get silence or mythology. Why is the job queue built in-house when BullMQ existed? Nobody remembers. Why does the auth service own the billing domain? The original engineer left. Why is Postgres used for time-series event data that has 400 million rows? Someone says “we just always did it that way.” Why is the AWS account structure a single account with environment prefixes instead of separate accounts per environment? “Good question. We should fix that someday.”

This is not technical debt. The code works. It might even be clean. What you have inherited is decision debt.

Three Types of Debt, One That Nobody Names

Engineering teams talk constantly about technical debt. Less often about cognitive debt. Almost never about decision debt. These are three distinct problems and conflating them makes all three harder to fix.

Technical debt is code quality. Unrefactored classes, missing tests, tight coupling, inconsistent error handling. It is visible in the codebase and shows up directly in maintenance cost and velocity.

Cognitive debt is system complexity that exceeds the team’s mental model. You have services nobody fully understands, interactions nobody can trace, failure modes nobody can predict. It is the “how does this actually work” problem.

Decision debt is the absence of durable reasoning artifacts. Not the debt in the code. The debt in the architecture’s rationale. The fact that your AWS account structure, your secrets management approach, your deployment model, your data model choices, and your authentication strategy all had reasons when they were made. Those reasons are gone. What remains is an outcome without a story.

The distinction matters because the remediation is completely different. Technical debt requires refactoring. Cognitive debt requires documentation and knowledge transfer. Decision debt requires retroactive archaeology: reconstructing the reasoning from what is left and writing it down before it degrades further.

Why Decision Debt Compounds

Technical debt compounds through accumulating interest: the longer you wait, the more code builds on top of the bad pattern. Decision debt compounds differently. It compounds at trigger events.

Leadership transition. A new CTO, VP Eng, or staff engineer joins and asks “why.” If the answer is not available in writing, they either make a suboptimal decision with incomplete context, or they spend weeks doing archaeology. The former is expensive silently. The latter is expensive visibly.

Compliance audit. SOC 2 auditors ask why certain security architecture choices were made. They want to see evidence of intentional, documented design, not just configuration that happens to be correct. A security architecture with no decision record is auditor bait. The audit takes longer, costs more, and sometimes requires retroactive work to prove intent.

Series A due diligence. This is where decision debt becomes a financing event risk. Technical investors running diligence will ask pointed questions: Why this database? Why this deployment model? Why this service boundary? If the engineering team shrugs, the investor hears “this was built without architectural judgment.” That is a flag. It does not necessarily kill the deal, but it invites deeper scrutiny, longer diligence, or a lower valuation.

IPO preparation. At this stage, decision records are not optional. Audit committees require documented reasoning for infrastructure choices with regulatory impact. Any company that has not built this practice by Series B is going to spend significant engineering time on retroactive archaeology under regulatory pressure.

The pattern is always the same: the absence of documented reasoning is invisible until a moment where it becomes suddenly, acutely visible. And those moments arrive at exactly the times when you can least afford them.

What Decision Debt Looks Like in Practice

Here is a concrete example of a decision without documentation and the cost it creates.

At an early-stage company, an engineer chose to run all background jobs inside the same Node.js process as the API server, using an in-memory queue. It was fast to build, worked fine at the traffic they had, and cost nothing to operate. When the company reached Series A and the new CTO asked why they were not using a durable job queue, nobody could answer. Was it deliberate? Was it an oversight? Was there a reason they rejected external queues? Unknown.

The new CTO spent a week investigating, reading old code comments, asking engineers who were present at founding. The answer turned out to be: it was a deliberate early choice made to avoid operational overhead, with the intent to revisit at scale. That context would have taken thirty seconds to write down. It took a week to reconstruct.

With a one-paragraph ADR, the new CTO could have read the decision in two minutes and made an informed choice about whether the original reasoning still applied. Instead, they discovered the hard way that they were also running scheduled tasks and email sends in the same process, that failures in one caused cascading failures in others, and that the “temporary” choice had three years of dependent code built on top of it.

The ADR Format for Retroactive Documentation

When doing retroactive ADR work, the standard forward-looking ADR template does not quite fit. You are not describing a decision being made. You are reconstructing a decision that was made, often with imperfect information.

Here is a TypeScript-typed structure you can implement as a markdown template in your repository:

interface ArchitectureDecisionRecord {
  id: string;           // ADR-0001, sequential
  title: string;        // Short noun phrase: "In-process job queue at launch"
  date: string;         // ISO 8601: the original decision date if known, else "~YYYY-QN"
  status: "accepted" | "deprecated" | "superseded" | "under-review";
  supersededBy?: string; // ADR ID if applicable
  deciders: string[];   // Names or roles of original decision-makers
  context: string;      // What was the situation? What constraints existed?
  decision: string;     // What was actually chosen?
  rationale: string;    // Why this option, not the others?
  alternatives: string[]; // Options that were considered
  consequences: {
    positive: string[];
    negative: string[];
    risks: string[];
  };
  revisitTrigger?: string; // What condition should prompt reconsideration?
}

For retroactive ADRs, the context field carries most of the value. The context for the job queue example above would read:

At launch in Q3 2022, the team was two engineers with an 8-week runway to first paying customer. Infrastructure overhead had to be minimal. AWS SQS and Redis-based queues added operational complexity the team could not maintain. The initial job volume was below 100 per day.

That one paragraph turns a confusing legacy choice into a reasonable early decision made under constraints. It also immediately signals to a new engineer: the constraint was operational overhead at low volume, not architectural preference. When volume changes, reconsider.

The 10-15 Decision Audit: Where to Start

If you are the Series A CTO who has inherited a codebase with zero decision records, you cannot document everything at once. The goal is to capture the decisions with the highest compounding cost if they remain undocumented.

Work through these categories systematically. Each one represents a class of decision that investors, auditors, and new engineers ask about.

Infrastructure and deployment model. Cloud provider choice, account/project structure, region selection, deployment mechanism (containers vs. serverless vs. VMs), CI/CD pipeline design.

Data architecture. Primary database selection, secondary stores (cache, search, analytics), event storage approach, backup and recovery model.

Service boundaries. Monolith vs. microservices decision and what drove it, how domains were split if they were split, inter-service communication pattern (REST, gRPC, message bus).

Authentication and authorization. Auth provider choice (built vs. bought), session management model, RBAC design, API key strategy.

Security architecture. Secrets management approach, network security model, encryption-at-rest decisions, data classification scheme.

Observability stack. Logging aggregation approach, metrics platform, tracing approach, alerting model.

Third-party dependencies. Key vendor selections that create lock-in or significant cost (payment processor, email provider, feature flags, analytics).

For each category, write one ADR. If the original reasoning is genuinely unknown, say so explicitly in the rationale field:

Rationale is reconstructed from code history and interviews with founding engineers. Original decision context is not fully recoverable. Reconstruction confidence: medium.

Honest uncertainty in a decision record is better than false certainty. An auditor or investor who reads “we do not fully know why this was chosen, but here is what we do know” trusts the documentation more, not less, because it is accurate about its own limits.

Running a Retroactive ADR Sprint

The most effective way to close a large decision debt backlog is a structured sprint rather than letting it happen organically. Organic documentation almost never happens.

A typical ADR sprint for a team that has been operating for two to four years runs over three weeks.

Week one: inventory and triage. List every major technical decision domain from the categories above. For each, rate urgency: is this domain actively asked about in onboarding, audits, or planning discussions? Is it a due diligence risk? Is it about to change? Score each 1-3. The top 10-15 highest-scoring items become ADRs. The rest go into a backlog with a realistic expectation that they will not be completed this quarter.

Week two: archaeology and drafting. For each priority item, assign one engineer who was present at the decision or who has worked most closely with the area. Give them two hours to draft the ADR. The draft does not need to be final. It needs to contain the context, the decision, and the best reconstruction of the rationale. If they cannot fill in the rationale, mark it explicitly as “reconstructed” or “unknown.”

Here is a lightweight bash script for scaffolding new ADR files consistently:

#!/bin/bash
# scaffold-adr.sh — create a new ADR file with sequential ID
DOCS_DIR="./docs/decisions"
LAST_ID=$(ls "$DOCS_DIR"/ADR-*.md 2>/dev/null | sort | tail -1 | grep -oP '\d+' | tail -1)
NEXT_ID=$(printf "%04d" $((${LAST_ID:-0} + 1)))
TITLE_SLUG=$(echo "$1" | tr '[:upper:]' '[:lower:]' | tr ' ' '-')
FILENAME="$DOCS_DIR/ADR-${NEXT_ID}-${TITLE_SLUG}.md"

cat > "$FILENAME" << 'EOF'
# ADR-XXXX: [Title]

**Date:** YYYY-MM-DD
**Status:** under-review
**Deciders:** [names or roles]

## Context

[Situation, constraints, and pressures at time of decision]

## Decision

[What was chosen]

## Rationale

[Why this option; what alternatives were considered and rejected]

## Consequences

**Positive:** [benefits realized or expected]
**Negative:** [costs or limitations accepted]
**Risks:** [what could go wrong; what would trigger reconsideration]

## Revisit Trigger

[Condition under which this decision should be reopened]
EOF

echo "Created: $FILENAME"

Week three: review and cross-reference. Each draft ADR gets a thirty-minute review with at least one other engineer who was not the author. The goal is not to relitigate the decision but to validate that the context is accurate and the rationale is legible to someone without inside knowledge. Cross-reference decisions that depend on each other: if ADR-0003 (single AWS account) only makes sense in the context of ADR-0007 (infrastructure-as-code strategy), link them explicitly.

Tradeoffs: Approaches to Decision Documentation

Approach	Cost	Coverage	Discoverability	Audit-readiness
Inline code comments	Very low	Low (code-specific only)	Poor (buried in files)	Poor
Confluence/Notion pages	Medium	Medium	Medium (hard to link to code)	Medium
ADRs in repo (/docs/decisions)	Low-medium	High (all domains)	High (version-controlled, searchable)	High
RFC process (separate from ADRs)	High	High	High	High
ADR tool (adr-tools, log4brains)	Low	High	High (generates site)	High

For a retroactive sprint on a startup codebase, ADRs in the repository are the right default. They live in version control, they are co-located with the code they describe, and they have no infrastructure dependency. Tools like log4brains can generate a browsable decision log from the markdown files, which is useful when sharing with auditors or during due diligence.

What Due Diligence Actually Asks

Series A technical due diligence has a predictable structure. Investors running diligence will typically spend two to four hours with the engineering team, then review any technical documentation provided. The questions that come up most often, based on the pattern across dozens of evaluations, follow a clear shape.

They are not asking whether you made the right choices. They are asking whether you made deliberate choices. The difference matters. An ADR that says “we chose a monolith deliberately, because at our scale the operational overhead of microservices outweighs the isolation benefit, and we plan to extract services when throughput in a specific domain forces it” is a better signal than no record at all, even if an investor would have made a different call.

The ADR answers the implicit meta-question: do the people who built this understand what they built and why? A team that can answer that question with written artifacts is a team that can be trusted with growth capital.

Making It Stick After the Sprint

A retroactive sprint closes the backlog. It does not install a practice. For the practice to persist, two lightweight mechanisms matter.

First, add ADRs to your pull request template. Not as a required field, but as a prompt:

## Checklist
- [ ] Tests updated or added
- [ ] Does this decision need an ADR? (new library, infrastructure change, service boundary, auth pattern)

The checkbox does not force an ADR. It forces the engineer to ask the question, which is enough to catch 80% of the decisions that should be documented.

Second, do a five-minute ADR review in your monthly architecture sync. Each team that made a notable decision in the last four weeks reports on it briefly. If no ADR was written, the sync is the reminder. If an ADR was written, the sync is where it gets cross-team visibility.

These two mechanisms cost almost nothing. They prevent the backlog from rebuilding.

The Actual Cost of Skipping This

Decision debt is almost never the thing that kills a company. But it reliably makes every expensive moment more expensive.

The Series A CTO who spends four weeks doing archaeology instead of building the roadmap. The SOC 2 audit that takes two extra weeks because the security architecture has no documented intent. The due diligence that surfaces three unexplained legacy choices and costs two points of valuation. The senior engineer who joins, cannot get answers to their “why” questions, and leaves after ninety days.

None of these are fatal in isolation. Cumulatively, they represent a real drag on the company’s ability to move. And they are entirely preventable with a few hundred words of plaintext per major decision.

The archaeology is not hard. You already know most of the answers. You just have not written them down yet.