A startup's pivot history is one of those records nobody keeps and everybody needs. The board asks "remind me how we got from the original idea to the current ICP," and you give a polished four-minute version of a fourteen-month story. A new senior hire asks why the original product didn't work, and you tell them the version you've told fifty times before — most of which is true, some of which has been smoothed for repeat use. Six months later you're trying to decide whether to pivot again, and the question "what did we actually learn last time" has no honest answer because the record was never written. A working notes setup doesn't make pivots painless. It holds the actual sequence — the data behind each change, the conversations that triggered the shift, the version of the product before the change, what worked and what didn't — so the next pivot decision is grounded in your real history instead of the version you've smoothed for retelling. The same record-keeping discipline backs [how to document company culture in your notes app](/guides/founders-ceos/document-company-culture-notes/) and [annual planning and goal setting](/guides/founders-ceos/annual-planning-goal-setting/). ## A vault that mirrors the company's actual lineage The shape that holds up is one top-level page per "version of the company" — `v1: scheduling app for hairdressers`, `v2: scheduling for small clinics`, `v3: clinic ops platform` — with sub-pages for product, ICP, GTM, pricing, customer voice, and the pivot decision itself. Capy supports unlimited page nesting, so a long-running company that's been through five shape changes fans out cleanly without forcing you to flatten the history into a single timeline doc. Plain markdown matters here because the agent can read across the lineage in one query. When you ask "what does our customer voice page say about the pricing complaints we got in v1, v2, and v3," Capy walks the vault and gives you a continuous narrative grounded in the actual material — not your reconstruction of it. ## Capture the prior version's product, not your memory of it The mistake every pivoted founder makes is letting the prior product fade into "yeah, we used to do X." Six months in, X has become a one-sentence summary that loses the texture — the actual feature set, the actual onboarding flow, the actual UI choices. Two years in, you're explaining v1 to a new hire and you can't remember whether the original onboarding had three steps or five. When you pivot, before the prior version disappears, capture it: a `product as it was` page with screenshots, the actual marketing copy that was live, the help-center articles, the pricing page, the changelog. PDFs and images attached to the page; long-form artifacts dropped in directly. PDFs auto-convert to markdown via docstrange so they're searchable text the agent can quote. Future-you can ask "what did our pricing page say in v2" and get the actual answer instead of a guess. This is the cheapest insurance you can buy against the long tail of "wait, what did we used to be?" ## The data behind the pivot, in one place Every pivot has data behind it — the cohort retention curve that flattened, the activation rate that wouldn't move, the support ticket volume that wouldn't fall. The data lives in Looker, Mixpanel, Amplitude, the CRM, and a dozen one-off SQL queries. Six months after the pivot, the dashboards have moved on; the queries are unrecoverable. A `data behind the pivot` sub-page on the prior version captures the screenshots, the exported CSVs, the SQL queries you ran, and the analyses you wrote at the time. Drop them in. Ask Capy to read across the page and write a one-paragraph summary of what the data actually said — at the time, not in hindsight. Two pivots later, when you're trying to remember what "the data was bad" actually meant, the answer is on the page. You can show it to a board member, a new senior hire, or a future investor without reconstructing it from rotting dashboards. ## The conversations that triggered the shift Pivots are often triggered by a small number of conversations: a customer interview that landed differently, a board call where someone reframed the question, a co-founder talk on a Sunday walk that changed the shape of the bet. These conversations are the actual decision-relevant material and they tend to live in nobody's notes. For pivots in motion: record the conversations you can. Capy transcribes recordings with speaker diarization (labels like `Speaker 1: …` so you can tell who pushed and who agreed), and parks the recordings on the right page. For conversations you can't record, write the recap in the moment — even three sentences — onto a `conversations that mattered` page on the version you're leaving. Six months later, when somebody asks "why did we decide to leave the SMB market," the answer isn't a polished narrative. It's the actual transcript of the conversation where the call got made — with the speakers labeled. ## A pivot decision page with the rationale intact The decision to pivot deserves its own page. Not a one-line "we pivoted in March 2026," but a structured record: the problem we were trying to solve, the options we considered, the option we picked, the reasoning, and the things we explicitly chose not to do. A useful structure for the page: current state of the company at the time of decision, the symptoms that triggered the rethink, the three or four directions we considered, the direction we picked, the bets we made about what would change, and the things we predicted would happen in the next six months. Drop the actual analyses and conversations on sub-pages and link to them. (The same decision-with-rationale habit is the spine of [annual planning and goal setting](/guides/founders-ceos/annual-planning-goal-setting/).) Six months later, the page becomes one of the most valuable artifacts in the company. You can compare the bets you made to what actually happened, the symptoms you identified to whether the new direction resolved them, and the predictions you made to the actual outcomes. This is how you learn from a pivot rather than re-experience it. ## A customer voice page that follows the pivot One of the most lossy things about a pivot is the customer voice from the prior version. The interviews you ran, the support tickets you read, the sales calls where the prospect said "I love it but…" — that material captures what was actually wrong with the prior shape, in customers' own words. Most of it gets lost. Customer-voice capture is also the spine of [how first-time founders use AI notes to move faster](/guides/founders-ceos/first-time-founders-move-faster/) — the early-stage version of the same loop. A `customer voice` sub-page per version of the company captures the verbatim quotes, the recurring complaints, the recurring praise, and the patterns across them. Recordings of customer interviews go directly on the page. Ask Capy to read across the page and surface the three most-recurring complaints and the two most-recurring delight points, and how they shifted across versions. When you're considering whether to pivot again, this page is the answer to "what was the customer telling us, actually." You can compare across versions to see whether the new ICP is hearing the same complaints under a different name — which usually means the underlying product problem hasn't moved. ## A "what we learned" page per version The final piece is the lessons. Not the polished version you tell at conferences, but the honest list of "things we now believe about this market that we didn't believe at the start." A `what we learned` page per version, written when you leave the version, captures the actual lessons. What surprised you about the customer. What surprised you about the channel. What was harder than you expected. What was easier than you expected. What you'd warn the next founder against. Ask Capy to draft the first version from the customer voice page, the data page, and the conversations page; you edit it down to what's actually true. This is the page you reach for when you're considering the next pivot, when you're hiring a senior person who'll need to understand the company's history, or when you're writing the YC update and want to ground the lessons in something concrete. ## What this isn't Capy isn't a substitute for the painful reflection that has to happen at a pivot. The lessons aren't generated by the agent; they're generated by you, looking at the record honestly. The vault makes the record holdable so the reflection has something to anchor on. It's also single-user by design. The founder owns the lineage. Outputs ship to the board, the team, and future investors as briefs and updates; the working record stays in one person's hands. The shape fits the founder who's actually living the pivots, not a team of analysts retrospecting. ## A small first test The cheapest way to see whether this fits is to pick the most recent shift in the company — even a small one, like an ICP narrowing or a pricing change — and write the version's `what we learned` page in retrospect. Drop the data you have, the customer voice you remember, the conversations you can reconstruct. Ask Capy to draft the lessons page from the material. If the page is sharper than what you currently say in the polished retelling, you've got a sense of what holding the record properly would do for the next pivot. [Try Docapybara free](/accounts/signup/). Load one prior version of the company and see what the agent does with the lineage.