The startup decision log: what the first year looks like when you build with AI

Here's the thing nobody tells you when you start building alone: every conversation you have with an AI assistant is also a decision log entry that you will never write down.

You ask Claude whether to use Stripe or Paddle for your first payment integration. You get a good answer, you think through it, you decide. You close the tab. Six months later you're debugging a tax calculation edge case and you cannot remember whether you chose Paddle specifically because of its VAT handling or whether that was an afterthought. The deliberation is gone. What's left is the code and a vague sense of "I think there was a reason."

Solo founders use AI chat for decisions differently than engineering teams do. There's no whiteboard, no architecture meeting, no Slack thread where someone accidentally documents the reasoning by asking a clarifying question. The AI chat session is the entire deliberation surface — and it closes when the decision is made.

What does a year of that look like when you extract it? What categories dominate? Which decisions turn out to be the ones you most needed to document? And what does the extraction pass tell you about the shape of a solo founding year that you couldn't have seen from inside it?

The mechanics: exporting a year

Running the WhyChose extractor on a year of solo-founder AI chat exports is different from running it on an engineering team's output. The volume is high — a founder who uses ChatGPT and Claude daily for twelve months typically has 800–1,400 conversation sessions — but the decision density per session is lower than in engineering-specific sessions. Founders use AI for drafting, research, debugging, and customer email rewriting, not just deliberation. The extraction pass filters for sessions where a decision was made: sessions that contain alternatives considered, a constraint that drove the choice, and a conclusion.

The ChatGPT export gives you a conversations.json file. The Claude export gives you a conversations.json with a flatter structure. Both run through the same extractor pipeline. For a year's worth of output, expect 35–60 extracted decision records — not 1,400, because most sessions are not decision sessions. The ones that are tend to cluster: the pre-launch month typically has more extracted decisions per week than any other period in the first year.

Before you run the extractor, it's worth doing one thing the tool can't do for you: use your git commit history or launch notes to anchor the timeline. A decision record that says "chose SQLite over Postgres" is useful. A decision record that says "chose SQLite over Postgres in March because we had no DBA experience and the expected write volume was under 10K rows per day" is the one that tells your first engineer why the schema is structured the way it is six months later. The extractor gives you the decision and the alternatives; you need the date anchor to give the record its durability.

The five categories that dominate a founding year

Extracted founding-year decision logs tend to cluster into five categories. Understanding the distribution matters because different categories have different documentation urgency — and different consequences when they go undocumented.

1. Stack and tooling decisions (30–40% of extracted records)

The most frequently extracted category, by volume. Founders revisit stack decisions throughout the first year — not because they change them often, but because the deliberation is high-stakes and the AI chat is where it happens. You evaluate four database options in February. You revisit the choice in May when a feature request changes the access pattern. You revisit it again in September when you're thinking about a second market.

The paradox of the stack decision category: it's the most extracted but the least underdocumented, because the same decisions appear across multiple sessions. The extractor will find three separate records discussing the same database choice — the February evaluation, the May revisit, and the September check. The most useful output is a synthesis: what was the final constraint that closed the question, and what conditions would reopen it?

The founding-year stack decisions that matter most to document are the ones that felt temporary when you made them. "We'll use SQLite until we need concurrent writes" is a decision with a trigger. Most founders don't write down the trigger. Six months later, the first engineer asks "are we expecting to need concurrent writes?" and the founder says "probably not in the near term" because they've lost the original frame. The decision has become permanent by default rather than by deliberate choice.

2. ICP definition decisions (20–25% of extracted records)

The most consequential underdocumented category. ICP decisions — who is this built for, and specifically who is it not built for — accumulate throughout the founding year in a way that's easy to miss because they don't feel like decisions. They feel like observations. "This works for solo CTOs more than it works for heads of engineering at larger companies." That's a decision. That's a scoping call that will shape pricing, feature prioritization, and messaging for the next eighteen months. It happens in a ChatGPT session at 11pm when you're thinking through a confusing sales call, and then it disappears.

ICP decisions have a compounding structure: each one constrains the next. "We're building for engineers who already write ADRs" implies "we're not building for teams who need to be convinced ADRs are worth doing." Both of those are decision records. The second one — the exclusion — is the one that's almost never extracted, because founders state exclusions as negatives ("this isn't for X") rather than as deliberate scope calls. Decisions that never get written down are disproportionately exclusion decisions, and ICP exclusions are the most load-bearing exclusions a founder makes.

When a co-founder or first advisor joins and starts proposing features, most of the friction comes from undocumented ICP decisions — not because the founder forgot what the product is for, but because the implicit model of the user that drives the founder's feature instincts isn't visible to the new person. A half-dozen extracted ICP records, assembled into a one-page document, closes that gap faster than any product brief.

3. Pricing and packaging decisions (15–20% of extracted records)

Pricing decisions are the category where extraction is most surprising. Most founders believe they've thought through their pricing carefully. The extraction pass shows how many pricing iterations there were before the current one — and, more usefully, why each iteration was rejected.

The record that matters most isn't the current price; it's the reasoning behind the prices you didn't ship. "We considered $19/month but it felt like it would attract users who treat it as a toy — we wanted price to select for serious buyers." That's not in your pricing page. It's not in your analytics. It's in a ChatGPT session from two months before you launched, and it explains why you shouldn't drop the price to $9/month just because a user asked. The constraint is preserved in the rejection reasoning, not in the final choice.

Packaging decisions — what's in each tier, what the tier boundaries mean — have the same structure. The free tier limit is usually a considered decision that sounds arbitrary in retrospect. "Free tier is capped at one export because we need a forcing function to get users to commit — the activation problem is real and a generous free tier would let users circle the product without ever extracting anything." That's the reasoning. It's in an AI chat session. It's not on the pricing page. When a new advisor suggests "make the free tier more generous to grow the top of funnel," the founder has to reconstruct the reasoning from scratch instead of pointing at the record.

4. Scope deferrals — "not building this yet" (15–20% of extracted records)

The category with the highest cost-per-undocumented-decision. A scope deferral is a decision to deliberately not build something, with a condition under which you'd revisit it. It's the most common founding decision and the least recorded.

"We're not building a native mobile app until we have 200 weekly active users" is a decision record. It has a constraint, a trigger for revisiting, and a reasoning: mobile distribution cost is not justified at this volume. Without the record, the constraint fades and the trigger disappears. Six months later, a user asks for a mobile app. The founder says "it's on the roadmap" without surfacing the original condition. An advisor says "mobile is table stakes in this space." There's no record to point to that says "we considered this, here is the threshold."

Scope deferral records are the document type that product decision logs treat as first-class — not just what you built, but what you deliberately didn't build and why, with explicit conditions for changing the answer. The founding year contains dozens of these. Most are made in AI chats. Almost none get written down.

The extraction pass surfaces them from phrasing: sessions where the founder evaluates an option and concludes "not now because X" rather than "not ever" tend to produce deferral records. The extractor flags these separately from permanent decisions because they have a different half-life — they should be reviewed against a condition, not archived as closed.

5. Positioning and messaging decisions (5–10% of extracted records)

The smallest category by extracted volume but the one that most often surprises founders when they see the output. Positioning decisions feel like creative work — you're finding the right words — not like architectural decisions with lasting constraints. But the underlying reasoning is structural: "we lead with the export-and-extract framing rather than the 'sync your AI tools' framing because the sync framing implies ongoing commitment, which is the thing our ICP is allergic to after being burned by tools that required setup maintenance." That's a constraint. It drives the copy, the onboarding flow, the feature prioritization, and the comparisons you make against competitors.

The positioning sessions also tend to contain the clearest articulations of the ICP insight the founder has developed over months of customer conversations and user behavior. A founding year's positioning decisions, assembled in order, tell the story of how the founder's understanding of the problem evolved — from the initial framing to the current one, with the customer evidence that drove each shift. This is the document you want before you bring on your first growth hire or talk to a growth investor. It's currently distributed across sixty AI chat tabs.

The pattern that shows up in every first-year extraction

After running the extraction pass, founders reliably identify the same structural insight: the decisions you made in the first three months are the ones that are most load-bearing and least documented.

Early-stage decisions feel provisional. You're figuring things out. The stack choice, the ICP focus, the pricing structure — these all feel like drafts. You'll revisit them when you know more. The extraction pass shows that most of them were never revisited. The "provisional" framing was the frame you used to avoid the commitment of writing them down, and the outcome is that they became permanent by drift rather than by choice.

This is the new-CTO onboarding problem in its founding-stage form. A new CTO joining a company that has twelve months of undocumented founding decisions has to reconstruct them from code, pricing pages, customer conversations, and the founder's memory. The extraction pass converts the AI chat history into a reconstruction source — not a complete record, but a starting point that's far better than nothing, and the only way to recover deliberation that happened before anyone thought to write it down.

The second pattern: the decisions you're most certain about are often the ones with the least surviving reasoning. The extractor finds ambiguous decisions frequently — sessions that end without a clear conclusion, that evaluated options without picking. It also finds decided decisions: sessions where the founder walked through options and arrived at a clear "we chose X because Y." The decided decisions are often the ones the founder now treats as obvious. "Of course we chose SQLite, it was obviously right for our scale." But the session shows it wasn't obvious — there were four alternatives evaluated and the constraint that closed the question was specific. The certainty is retrospective. The record preserves the uncertainty that existed when the call was actually made, which is the part that makes it useful to someone encountering the decision later.

The first-hire onboarding case

The most common trigger for a solo founder to run an extraction pass isn't retrospective curiosity. It's the arrival of a first hire, co-founder, or technical advisor who starts asking "why did we do it this way?"

An engineer who joins a solo-founder startup in month twelve walks into a codebase shaped by a year of deliberation they weren't party to. The decisions that produced the architecture, the pricing, the ICP focus — these are background context the founder carries implicitly and the new hire has to construct from first principles. The onboarding wiki can describe what the product does. The decision log template can give the new hire the format. Neither can reconstruct the year of reasoning without a source.

A first-year extraction pass, assembled into a decision log with 15–25 records in five categories, changes that onboarding conversation. The new hire reads the ICP decisions first — they understand who the product is built for and who it is not. They read the scope deferrals — they understand what's on the roadmap and what's deliberately off it, with the conditions that would change those calls. They read the stack decisions — they understand not just what was chosen but what was evaluated and why it was rejected. The "why did we do it this way?" questions start from a much higher baseline.

The extraction also serves the founder. Going through a year's decisions in sequence is a clarifying experience that doesn't happen any other way. You see where your ICP thinking evolved, where pricing iterations accumulated, which scope deferrals you've mentally upgraded to permanent decisions without noticing. The act of reading your own deliberation across twelve months reveals the decision log you already wrote — scattered across chat tabs — and reassembles it into something you can actually use.

How to run the extraction pass

The practical steps, in order:

Export both platforms you use. Most founders use both ChatGPT and Claude. Export both. The ChatGPT export is in Settings → Data Controls → Export Data. The Claude export is in Settings → Account → Export Data. Each produces a conversations.json file. Run the extractor on each separately; the output will have some overlap (the same decision discussed in both platforms) that you'll triage in the next step.

Set a date anchor before triaging. The extracted records don't include dates from the conversation metadata by default — the extractor focuses on decision content, not session timestamps. Before you start triaging, pull your calendar or git log for the year and identify two or three date anchors per quarter: what were you building in Q1, when did you launch, when did you make the first hire decision. This takes fifteen minutes and makes the extracted records dramatically more useful because you can place each decision in context.

Triage by category and permanence. Sort extracted records into the five categories above. Then mark each as either closed (the decision is made and not up for revisitation under foreseeable conditions) or conditional (the decision has an implicit trigger for revisitation that you should make explicit). Conditional decisions become your deferral log — the set of things you deliberately chose not to build and the conditions under which you'd change that answer.

Write the ICP records first. These are the highest-leverage records for onboarding a new team member. Take the ICP-adjacent extracted content and write four to six records: who is the primary user, what job they're trying to do, what competing approaches they've already tried and rejected, who is explicitly outside the ICP and why. These records will serve as the foundation every future positioning and feature conversation should start from.

Identify the three decisions your first hire would ask about immediately. This is the practical test for the extraction output. If a strong engineer joined your team tomorrow, what are the three questions they'd ask in the first week that you'd have to answer from memory? Write records for those three first. They're the highest-priority gaps because they represent the assumptions that currently require the founder's presence to access — and the founder's presence won't always be available.

The full extraction and assembly process takes three to four hours for a year's worth of output. The result is a 20–30 record decision log that didn't exist yesterday and now serves as the founding document for everything that comes after it. For a solo founder preparing to scale — first hire, first investor, first co-founder conversation — it's among the highest-leverage three hours you'll spend.

The compounding effect

There's a version of this that gets easier over time. A founder who runs the extractor quarterly — not annually — captures decisions while the context is still accessible. The quarterly pass takes an hour, not four hours. The output is tighter: 5–8 records per quarter rather than 35–60 for a year. The triage is easier because you remember what you were building.

The quarterly cadence also surfaces deferral decisions before they drift into permanent ones. A scope deferral from three months ago, reviewed against its trigger condition, is a deliberate reconsideration. A scope deferral from eighteen months ago is a zombie decision — never explicitly closed, no longer relevant to how you're thinking, but silently shaping what you're building because the original "not yet" is now indistinguishable from "not ever."

Every founding team eventually hits the moment described in the new-CTO onboarding problem — a moment where someone in the room can't answer a foundational question about why the product is the way it is. For solo founders, that moment comes earlier, and it comes in a different form: it comes when the founder themselves can no longer explain the reasoning behind choices they made twelve months ago, because they made those choices in chat tabs that are now closed.

The first-year extraction pass doesn't prevent that moment. It converts it from "I don't know why we made that call" to "the reasoning is here — let me find the record." That's a different kind of organization. Not one with perfect documentation, but one where the deliberation that actually happened has a chance of being recovered.

The decisions were made. The reasoning was real. The question is whether it survives long enough to be useful.