Building in public is one of those practices that looks like a marketing strategy and is actually an operating discipline. The weekly post on X. The monthly MRR update. The "what I'm working on" thread. The launch thread. Each one is a small commitment to surface your real work to people who'll either learn from it or roast it. Done well, it accelerates the business. Done badly, it's a parallel writing job that competes for time with the actual product. The thing that distinguishes the indie hackers who sustain it from the ones who burn out on it is whether the public posts are downstream of a real operating record or whether they have to be conjured fresh each time. If you're conjuring, you're spending the night before the post in a Slack of one trying to remember what you actually shipped this week. If the record is held, the post is a synthesis of material that's already there. A working notes setup puts the operating record in one place and lets the agent help you write the public version of it. The same operating-log-into-output pattern shows up in [how first-time founders use AI notes to move faster](/guides/founders-ceos/first-time-founders-move-faster/) and [AI for small businesses](/blog/ai-for-small-businesses/) — different audience, same rhythm. ## A vault shaped like the indie hacker's actual life The shape that holds up is one top-level page per ongoing thread — `the product`, `customers`, `revenue`, `building in public`, `experiments`, `support` — with sub-pages for the granular detail. Capy supports unlimited page nesting, so a side project that grows three concurrent experiments and a handful of customer cohorts can fan out cleanly without forcing structure on day one. Plain markdown matters because the agent can read across the vault when you ask "what did I actually ship this week, what moved on revenue, and which customer interviews surfaced something interesting." The agent walks the relevant pages and gives you a continuous picture grounded in your actual material — which is the source for the next public post. ## A weekly operating log that becomes the next post The expensive habit in building in public is treating the weekly post as the writing surface. You sit down on Friday afternoon, blank page, "what did I do this week?" Six hours later you have a 200-word post and you've forgotten three things worth mentioning. Inverting this: the weekly operating log is the source. Every weekday, drop two-line entries onto a `weekly log` page — what you shipped, what broke, what you learned, what a customer said. Then on Friday, ask Capy to read the week's entries and draft the public post in your usual structure. You edit, ship, and move on. The post isn't an act of creative recall; it's a synthesis of a record that already exists. The cost of the post falls to whatever editing your specific voice needs. ## Customer interviews that compound across months Indie hackers tend to do customer interviews irregularly — a burst when launching, a burst when something's broken, occasional one-offs in between. The interviews are valuable individually and ten times more valuable in aggregate, but the aggregate picture rarely gets assembled because the interviews live in scattered notes. Record each interview in Capy. The transcript comes back with speaker diarization — labels like `Speaker 1: …` so you can tell what you asked and what they said. Park the recording on the customer-interviews page. After every five or six interviews, ask Capy to read across them and surface the three most-recurring problems, the two most-recurring praise points, and any verbatim quotes worth using in product copy or a post. The interviews stop being one-offs. The aggregate picture becomes a recurring input to the next public post about who your customer actually is — grounded in their actual sentences, not in your retelling. ## A revenue page that holds the why, not just the number Most indie hackers track MRR somewhere — Stripe, a Baremetrics dashboard, a spreadsheet. The number is one thing. The *why* — which customers churned this month, which signed, which of your experiments moved the metric, which marketing channel paid back — is usually nowhere. A `revenue` page holds the monthly MRR number and a narrative paragraph for each month: who churned and why if you know, who signed and where they came from, which experiments moved the metric, which didn't. Drop in screenshots from your dashboards. PDFs of monthly Stripe statements auto-convert to markdown via docstrange so they're searchable text the agent can quote. When you write the monthly MRR update for the public, ask Capy to draft it from the revenue page. The post has the number and the story behind the number. Six months in, you can ask the agent "trace what's actually moved MRR over the last quarter" and get an honest answer grounded in the page rather than your impression. ## Experiment tracking that survives forgetting Indie hacker experiments — pricing tests, landing-page variants, channel tests, feature toggles — get run and forgotten. The result lives in a screenshot on your phone, a Slack message to nobody, or your memory. Three months later, you re-run a similar experiment because you can't remember what the last one taught you. An `experiments` inline database with rows for date, hypothesis, what changed, the result, and what you'd do next. The database lives directly in the markdown page via the `:::database:::` directive — alongside the prose context. After each experiment, ask Capy to draft the row from the source page; you edit and confirm. (The same database-of-decisions habit is the spine of [annual planning and goal setting](/guides/founders-ceos/annual-planning-goal-setting/).) Six months later, when you're considering whether to test a new pricing tier, you ask Capy to read the experiments database and surface every prior pricing experiment with its result. The decision is grounded in your own past work, not in a recurring "I think we tried that?" ## Drafting the next post from the last few A lot of building-in-public writing is structurally similar to writing you've done before. The "month X recap." The "lessons from launch" thread. The "here's what's working" post. Each one is bespoke in content and almost identical in shape. Drop the constraint of the next post on a page. Tell Capy: "draft a launch-day thread for the new feature, structured the way my prior launch threads have been, grounded in the experiment results from the experiments database and the customer quotes from the interview synthesis." You get a draft that sounds like *your* threads — because it was grounded in your actual material — and you spend the saved time on the parts that genuinely are new: the specific feature framing, the call to action. The agent acting on the draft directly is the [Cursor-for-documents](/blog/claude-code-for-documents/) idea applied to your public-build cadence. The same shape works for the next monthly recap, the next "lessons learned" thread, the next "here's what I'm working on" post. ## Replies and DMs that turn into the next post Building in public generates a lot of reply traffic — questions on X, DMs about the product, comments on Hacker News. Most of those responses contain the seeds of future posts: a recurring question is a post, a recurring objection is a post, a recurring praise pattern is a post. A `public conversations` page captures the patterns. After a week of replies, drop notable threads on the page (or screenshot them in). Ask Capy to read across the page and surface the three most-recurring questions you got this month, the two most-recurring objections, and the one praise pattern that's worth turning into copy. The next month's public posts are partly downstream of last month's public conversations. The capture cost is small; the compounding is real. ## Voice consistency without being a slave to a style guide Building in public works better when your voice is consistent across posts. The default failure mode is voice drift — you sound like one person in the launch thread and a different person in the monthly recap because each was written in a different mood under different deadline pressure. Park a `voice` page in the vault that captures your actual voice in concrete terms: phrases you use, words you don't use, the rhythm you favor, the kinds of jokes you'll make versus the kinds you won't. When you ask Capy to draft the next post, point the agent at the voice page along with the source material. The drafts come back closer to your actual voice on the first try; the editing pass shrinks. This isn't a style guide written in the abstract. It's an operating note about how you actually sound when you're at your best. ## What this isn't Capy isn't a scheduling tool, isn't an analytics platform, and isn't a substitute for the actual building-in-public practice — the showing up, the honesty, the engagement. The vault holds the *operating record* that the public posts are downstream of: the weekly log, the customer interviews, the revenue narrative, the experiment results, the public conversations. Without the practice, no notes setup helps. With the practice, the right notes setup makes the practice sustainable. It's also single-user by design. The indie hacker owns the vault. Outputs ship to the public as posts, threads, and updates through the channels you already use. The shape fits the solo operator who's building and writing about it, not a team that needs to share the operating record. ## A small first test The cheapest way to see whether this fits is to take last week — a week that already happened — and rebuild the operating log retroactively. Pull together what you shipped, what broke, what customers said, what moved on revenue. Ask Capy to draft this week's recap post from the page. If the draft is closer to ship-ready than the recap you actually wrote (or didn't write) at the time, you've got a sense of what running the next month in this shape would do. [Try Docapybara free](/accounts/signup/). Load one week's operating log and see what the agent does with the source for the next post.