WhyChose
2026-06-12 · ~14 min read

The startup founder's ADR starter pack: 12 decisions every early-stage company should document in the first year

The average early-stage startup makes more load-bearing decisions in its first twelve months than at any other point in its life. And it documents almost none of them. Not because founders are careless — because the pace of year one makes documentation feel like overhead on a problem that's already been solved. By the time the documentation pressure becomes visible, the founding team has turned over, the architecture is three years old, and nobody can answer why the system was built the way it is.

Most early-stage teams write ADRs for the wrong decisions. They document the ones that feel important at review time — the framework selection, the ORM choice, the deployment model — and skip the ones that are hardest to reconstruct later: the ICP decision that shaped two years of product development, the pricing structure that was locked in during a Tuesday AI chat session, the authority structure between co-founders that was "obvious to everyone" until it wasn't.

This post is a starter pack: twelve specific decision categories ordered by the cost of not having them. Not the twelve most interesting decisions, or the twelve most technically significant ones. The twelve where the absence is most expensive — where the team reaches fifteen people and there's no record of the reasoning that shaped everything that followed.

You don't need to write all twelve in year one. You need to have them in your documentation by the time the founding team's shared context starts to fade — which, for most companies, is somewhere between month 18 and month 30.

Why these twelve, and why this order

The ordering principle is compounding cost. Some decisions have long tails — they shape everything downstream and are essentially invisible until someone joins the team who can't answer "why does this look like this?" Other decisions expire relatively cleanly. The twelve categories here are ordered by how long the absence compounds and how expensive the reconstruction is when it finally becomes necessary.

The ordering is also a departure from how most ADR guides approach startup documentation. Typical advice focuses on technical complexity as the selection criterion: document the hardest technical decisions. That's reasonable for mature engineering teams. For early-stage companies, the highest-cost undocumented decisions are often the non-technical ones — the ICP choice, the pricing structure, the co-founder authority arrangement — because those decisions leave no code artifacts at all. The reasoning is exclusively in the founding team's heads and in their AI chat history.

For the full decision log view — what the first year looks like across all decision types, not just the twelve — the startup decision log post covers that terrain. This post is the starter pack: the twelve to prioritize.

The twelve categories

1. Tech stack foundational choices

The primary language, web framework, client-side approach, and API model. Not the individual library selections — the choices that everything else builds on and that are expensive to reverse.

The reason this is first is compounding. A tech stack decision from month three of a startup will still be in production in year four. Engineers joining in year two will ask "why this stack?" — and without a record, they'll get a reconstructed answer that omits whatever constraint was actually decisive. The "why not [framework]?" conversation happens fresh every time someone new joins.

The honest constraint for most founding-team stack decisions is familiarity. The CTO knows Python; the startup builds in Python. That's a legitimate constraint — learning curve is real, early velocity is critical, and the familiar tool almost always wins when the alternatives are roughly equivalent. But when the ADR says "Python was chosen for its data science ecosystem" instead of "Python was chosen because it's what the founding engineer has six years of production experience with," the record misleads future readers about when to revisit. The familiarity constraint expires when team composition shifts. The ecosystem constraint expires on a different schedule. Document the real one.

2. Ideal customer profile decision

Who are you building for — and equally importantly, who did you decide you're not building for?

The "not building for" decision is almost always undocumented. It usually happens when a plausible-looking user arrives and the founder internally concludes that this isn't the customer the company is optimizing for. The conclusion is correct, the reasoning is sound, and it never gets written down. Three months later, without the record, the team is earnestly debating whether to build the feature that was implicitly declined.

ICP decisions are also the most frequently re-litigated decisions in early-stage companies. Every new team member, every investor conversation, every sales call is implicitly an ICP pressure test. The documentation doesn't prevent the re-litigation — but it means the re-litigation happens against the original reasoning rather than against an inferred position that accumulated via tribal knowledge. Those are different conversations with different outcomes.

The record here has an unusual shape. The Decision field isn't just "our ICP is X" — it's "our ICP is X and we considered Y and Z and here's why they didn't fit." The alternatives section is what makes the ICP record useful. Without it, the record says who you're building for without explaining who you decided not to build for, and the latter is often more consequential.

3. First pricing structure

Freemium, free trial, paid only, usage-based, per-seat — and the specific price point and tier architecture.

This decision is almost always made primarily in AI chat. The founder evaluating "should I charge $9 or $19 for the pro tier?" is working through a real trade-off in a Claude or ChatGPT session: conversion rate vs. revenue per account, willingness to pay for the ICP, competitive anchoring. The deliberation is rich. The output is a price on a landing page with no record of how it got there.

The cost of undocumented pricing decisions is that the reasoning for the structure disappears while the re-litigation continues indefinitely. Pricing gets revisited quarterly. But the revisitation happens from first principles every time, without the constraints that shaped the original choice. "Why do we have three tiers?" — nobody knows. "Why is enterprise unlocked at $49 and not $29?" — nobody knows. Each re-evaluation spends the first thirty minutes reconstructing what was already decided instead of evaluating what should change.

The pricing record also benefits from an explicit review trigger. "Re-evaluate at $10k MRR or 100 paying customers, whichever comes first" turns a floating decision into one with a defined revisit condition. Without the trigger, the pricing gets re-debated at every all-hands. With it, the team can say "we haven't hit the trigger yet" — not to avoid the conversation, but to anchor it to the signal that was originally identified as meaningful.

4. Database and persistence choices

Primary database, ORM choice or explicit no-ORM decision, key-value store, file storage approach.

This is the decision category with the highest engineer-joiner friction in early-stage companies. "Why Postgres and not MySQL?" "Why no ORM?" "Why Redis for the queue instead of a proper queue service?" These questions aren't architectural concerns — they're orientation questions from people trying to understand the system. Without a record, they consume thirty minutes of senior engineer time that could be two minutes of reading.

Database decisions also have the most expensive undo path of any technical decision in this list. The tech stack can in principle be replaced incrementally; the database is load-bearing under everything, and migration cost grows with data volume. Documenting the original constraint — "Postgres was chosen because the founding engineer had deep Postgres expertise and we had 6 weeks to launch" — tells future engineers both what was decided and when the constraint expires. When the team grows and Postgres expertise is no longer scarce, the expiry condition is met and the record can be marked for review.

5. Auth and identity approach

Self-built auth vs. managed identity provider, session handling model, and whether passkeys or legacy credential flows are in scope from the start.

This decision sits at the intersection of security, compliance, and vendor lock-in in a way that no other early-stage decision does. The SOC 2 audit question for CC6.1 (logical access controls) requires documented reasoning for authentication decisions. Doing that reconstruction eighteen months after the choice — when the people who made it may have left, when the original deliberation exists only in someone's AI chat history — is substantially harder than documenting it at decision time.

The vendor lock-in dimension is also worth naming explicitly. Choosing Clerk or Auth0 or Supabase auth is a dependency decision as much as a technical one. The ADR's Consequences field should name the lock-in surface: "migrating away from [provider] requires re-implementing session handling and updating every authenticated endpoint." That's not a reason not to choose a managed provider — the development velocity benefit is often decisive — but it's the honest consequence that the team should know they accepted.

6. Founding team authority structure

Who has final authority over which category of decision: technical architecture, product prioritization, business and commercial, hiring, compensation.

This is the decision most founding teams explicitly resist documenting. "We'll figure it out together" is a common early-stage position that works reasonably well when the founding team is two people who trust each other. It stops working when the company is eight people, when decisions are being made faster than any two people can consult, and when the first real co-founder disagreement surfaces a gap in the implicit authority map.

The authority structure record doesn't have to be a rigid org chart. It can be a simple statement of which decisions each co-founder has clear authority over, with the acknowledgement that contested decisions require explicit alignment. What it prevents is the situation where the founding team has an implicit understanding that diverges in exactly the moment when an explicit one is needed — and there's no record of what the original agreement was.

The cost of undocumented authority structure is trust erosion, not operational failure. The company doesn't break. But co-founder relationships fray under repeated implicit authority disputes, and the repair cost is high. A three-paragraph record written in month two is the cheapest version of co-founder alignment available.

7. First hire prioritization

Why this role before the alternatives that were equally plausible.

The hiring decisions worth documenting aren't "who was hired" — the person's presence is the artifact, and their employment record tells you who was hired. What doesn't survive without documentation is why this role was prioritized over the alternatives: why a designer before a second engineer, why a sales hire before a second product person, why a customer success role before a technical writer.

These decisions encode a product thesis and an execution theory. "We hired a designer in month 4 because our conversion rate problem was primarily a trust and polish problem, not a product-market fit problem" is a real claim about what the company believed at that point. The claim may be right or wrong — but it's the reasoning that shaped what the first several hires looked like. New team members can't infer it from the org chart. They need the record.

The case for documenting non-technical decisions in the same log as technical ones is most visible in the hiring category. The hiring record belongs alongside the tech stack record and the database record — not in a separate HR system where it won't be found when an engineer is trying to understand why the team is structured the way it is.

8. Infrastructure and deployment approach

Managed vs. self-managed, which cloud provider, container orchestration decision (or the explicit decision not to use containers), CI/CD pipeline choice.

The infrastructure decision almost always contains a hidden constraint that isn't stated: the founding engineer's familiarity with the chosen provider. AWS vs. GCP vs. Azure is a real trade-off with real cost and capability differences — but in practice, most early-stage companies choose the cloud the CTO has used before. That's the correct choice. Document it.

"We chose AWS because the CTO has five years of AWS production experience and the onboarding time to GCP would have cost us two sprints" is a complete and honest record. It tells the team when to revisit (when AWS pricing becomes meaningfully different from alternatives at scale, or when GCP capabilities in a relevant domain become decisive). It doesn't pretend the choice was made for reasons it wasn't.

The CI/CD pipeline decision is worth separating from the broader infrastructure record because it has a different ownership pattern and a different revisit cadence. The cloud provider decision is sticky; the CI/CD choice is reviewed every time a developer joins who has strong opinions about their toolchain. A record that says "we chose GitHub Actions because we're already on GitHub and the zero-setup integration was worth the loss of build cache flexibility" answers the GitHub Actions vs. CircleCI vs. Buildkite question once, not every six months.

9. Open source vs. closed source

Whether the core product, the extractor, the SDK, or the documentation tooling is publicly available — and under what license.

This decision is usually made by default. The founding team creates a private repository, moves fast, and never explicitly evaluates whether open-sourcing any component would serve the business. That's fine — private is the correct default for most early-stage companies. But "we evaluated open-sourcing and decided against it" is a different document from "we never evaluated it," and the difference matters when someone asks three years later why the product isn't open source.

The license decision — MIT vs. Apache vs. a commercial license — has downstream implications for the community building, the competitive dynamics, and the enterprise sales motion that are hard to reverse. The ADR for this should name the alternatives that were considered and the constraint that was decisive. "We chose MIT because the open-source extractor layer needs to be forkable by enterprise security teams who require audit rights" is a different constraint from "we chose MIT because the founding team has open-source values." Both are valid. They imply different review triggers.

10. Monetization model

Freemium, free trial, paid only, usage-based, per-seat — and the structural commitment to that model rather than the specific price point.

The pricing record (category 3) covers the specific pricing decision. This record covers the monetization architecture: the commitment to freemium as a growth model rather than direct sales, the decision to use seat-based pricing rather than usage-based, the choice to offer an annual discount from the start. These are structural choices that affect the entire customer acquisition motion and are substantially harder to reverse than a price change.

The failure mode this record prevents is the "when did we decide to do freemium?" conversation. Companies that have been running a freemium model for eighteen months frequently can't answer that question with precision. Nobody made an explicit decision — the free tier just accumulated features while the pricing page acquired a Free column. Documenting the monetization model when it's decided — not inferred from the pricing page — gives the team a clear record of what was deliberate and what was default.

11. Key deferral decisions

The explicit choices to not build something yet, with the trigger conditions that would cause the decision to be revisited.

Deferral decisions are the most invisible decision type in any startup. They look like absences — there's no mobile app, no enterprise tier, no international expansion — and absences don't have obvious documentation surfaces. But most visible absences in a functioning early-stage product are deliberate. The founding team had a reason for not building the mobile app: the ICP uses desktop, mobile would require maintaining two codebases at a stage where shipping velocity matters more than surface area, the decision should be revisited when a cohort of mobile-first customers exceeds 20% of the waitlist.

That reasoning is in the founder's head, or in a ChatGPT session from six months ago, or in a Slack thread that nobody will find. When a new team member joins and asks "why isn't there a mobile app?", the answer is a reconstruction. When an investor asks, the answer is a reconstruction. When the trigger condition is actually met — when mobile-first customers are 25% of the waitlist — nobody knows to check whether that condition was the one the founding team had in mind.

The deferral record has a simple structure: what was deferred, why, and what trigger would cause revisitation. Three sentences. The record for the mobile app decision might read: "We decided not to build a mobile app in year one. Our ICP uses desktop tooling and the dual-codebase maintenance cost is too high at our current team size. Revisit when mobile-first users exceed 20% of active accounts for two consecutive quarters." That record turns an absence into a decision. The absence had a constraint. The constraint has an expiry condition. Now the absence is legible.

12. The first explicit "no" to a paying customer

The first time a customer asked for something and the company declined because it wasn't what the product is building toward.

This is the most underrated record type in the starter pack. The first "no" is the ICP sharpener — the moment when the implicit ICP decision becomes explicit in a real commercial interaction. It tells you not just who you're building for, but who you were offered and turned down, and why. That's more specific and more actionable than any generic ICP statement.

The record for the first no should include the shape of the request, why it was declined, and what the declination implied about scope. "A B2B customer with 500 employees asked for SSO and advanced admin controls in month 6. We declined to build it and recommended they evaluate [competitor]. The constraint was focus: building enterprise features at this stage would have shifted the product's surface area away from the individual-engineer ICP and required hiring for a different support motion than we have capacity for. Revisit at $500k ARR when we have a dedicated sales motion." That record tells every future team member what the company believed it was and was not at that point in time. The incoming CTO who wants to understand why the product doesn't have SSO has the reasoning, not just the absence.

The minimum viable record for each

The full Nygard ADR format is the right target for technical decisions with long consequence tails. But the minimum viable record for each of the twelve categories is three sentences — and three sentences written in ten minutes beats a comprehensive ADR that never gets written.

The template: "In [situation], we chose [decision] over [alternatives]. The constraint was [real driver]. This means [what it enables] and [what it closes off, if any]."

For the tech stack decision: "In month 2, with a two-person founding team and a 6-week runway to first customer demo, we chose Next.js for the web layer over Remix and vanilla React. The constraint was the CTO's familiarity with the Next.js deployment model and Vercel's zero-config deploy for initial velocity. This means we get fast initial shipping but should evaluate whether the RSC complexity is worth it when we consider a mobile client."

For the ICP decision: "We're building for individual software engineers and small engineering teams (2–6 people) who work primarily in AI chat for technical deliberation. We considered B2B enterprise as the primary ICP and declined — the procurement cycle is incompatible with the build velocity we need, and the individual engineer experiences the core value proposition more directly. Revisit the enterprise motion when we have 1,000 individual users with demonstrated retention."

That's it. Two paragraphs per decision, twelve decisions, twelve records. The full log can be written in a focused Saturday afternoon from memory, or reconstructed in a few hours using the AI chat extraction pass.

The AI chat extraction pass

The twelve categories in this starter pack are exactly the decision types that year-one founders work through in AI chat. Pricing deliberation, tech stack evaluation, ICP exploration, architecture choices, hiring sequencing — these are the problems founders bring to ChatGPT and Claude at all hours when they're trying to think through a hard choice. The deliberation sessions exist. They're recoverable if the chat history is available.

The extraction pass is the fastest way to populate the starter pack from a standing start. Export your ChatGPT conversation history and Claude exports from the past year — both are available as JSON from the platform settings. Run the WhyChose extractor on the export. The extractor surfaces the sessions that contain decision signals: option comparisons, explicit trade-off evaluations, directional conclusions. Match each output session to one of the twelve categories. Write the three-sentence record from the deliberation context.

The extraction output often gives you better ADR inputs than memory would. The deliberation session contains the real constraint — the one you actually named in the conversation, not the more defensible-sounding one you'd reconstruct from memory. "Honestly I think we should just use Postgres because that's what I know and we don't have time to evaluate alternatives carefully" is the real constraint. It's in the chat. It's honest. It belongs in the ADR. Extracting from the original session rather than writing from memory produces the record that avoids the false-constraint problem that compounds through every subsequent decision that cites it.

For decisions that predate your AI chat history, or where the deliberation happened in a meeting with no written record, write the record from the decision log template from memory. The three-sentence minimum is achievable even for old decisions. The founding team can usually reconstruct the real constraint for decisions made eighteen months ago — it's the specific supporting evidence that fades, not the actual reason.

The quarterly founding-team review

Once you have the starter pack, the maintenance protocol is simple: quarterly, ninety minutes, founding team only. Three questions for each record.

Is this still operative? For most records, the answer is yes and the review takes thirty seconds. Occasionally the answer is "actually we changed this implicitly six months ago and the record doesn't reflect it." When that's the case, update the record or write a superseding one. The record that reflects current reality is the record that's useful to the next engineer who joins.

Has the constraint changed? This is the question that catches the most expired decisions. The tech stack constraint was "founding engineer's familiarity" — is that still the binding constraint now that there are four engineers with different backgrounds? The pricing constraint was "$9 felt right for individual engineers" — does that still hold at the current customer profile? Constraints expire. The review is how you catch the expiry before it causes a downstream problem.

Is there a downstream decision that should be revisited because this one has changed? Some decisions are independent. Others are load-bearing: the ICP decision is cited in the hiring decisions, the pricing structure decision is cited in the monetization model decision, the auth approach decision is cited in the compliance documentation. When a foundational record changes, the decisions that depended on it may need to change too. The quarterly decision review is where that dependency check happens systematically rather than reactively.

The ninety-minute quarterly cadence is sustainable precisely because the starter pack is bounded. Twelve records. Three questions each. Most questions have quick answers. The review catches the small number of cases where an answer has actually changed — and catching those early is far less expensive than discovering them when someone is six months into implementing something that runs against a constraint that quietly expired.

The record you write now vs. the conversation you have in two years

Every one of the twelve categories in this starter pack represents a conversation that will happen eventually. The founding team's ICP reasoning, the pricing structure's original constraints, the authority arrangement between co-founders — these will all be re-examined as the company grows, as new people join who weren't present for the original decisions, as circumstances change enough that the original choices look wrong or mysterious from the outside.

The question isn't whether the conversation will happen. It's whether it will happen with a record or without one. Without a record, it's a reconstruction exercise, and reconstructions are slower, less accurate, and more likely to produce the defensible-sounding answer rather than the true one. With a record, the conversation starts from the original reasoning and evaluates what has changed. That's a different conversation — faster, more accurate, and less likely to relitigate what was already settled.

The twelve records in this starter pack are twelve conversations that will happen well rather than twelve conversations that will happen poorly. Written now, from deliberation context that's still fresh, they save an average of several hours each when they're needed. The twelve records together take one focused afternoon to write, or a few hours to extract from AI chat history. The return on that afternoon compounds for as long as the company exists.

Further reading