Solo builders don't need documentation. They need memory

Most software documentation is written for people who are not you.

• READMEs are for strangers landing on your repo.
• PRDs are for teams.
• PR descriptions are for reviewers.
• CHANGELOGs are for users.
• Status updates and roadmaps are for stakeholders.
• Architecture docs are for the engineer who joins next year.

But if you're building with AI, as a solo founder, indie hacker, designer, vibe coder, or one-person software team — most of that is theater. You don't need more documentation.

You need a way to remember what future-you will forget.

The writer changed

For most of software history, humans wrote docs for other humans. That's why the conventions look the way they do. Those docs make sense when the audience is other people.

But AI changes the economics of documentation.

When you work with Claude Code or Codex, AI is already producing artifacts about your project constantly: summaries, plans, implementation notes, comparisons, explanations, prototypes.

The writer does not get tired. The writer does notget. The writer is happy to update the same page fifty times a day.

So the question changes.

It is no longer:

What documentation is worth a human's effort to write?

It is:

What documentation is worth future-you's attention to read?

That is a completely different question.

And for solo builders, the answer is much smaller than the docs folder we inherited from team software.

The distinction that matters is not Markdown vs HTML. It is not team docs vs solo docs. It is not even human-written vs AI-written.

The distinction that matters is:

coordination artifacts vs memory artifacts

Two different kinds of project artifacts.

Coordination artifacts exist because multiple humans need to get on the same page. They make one person's thinking legible to another person.

• READMEs.
• PRDs.
• PR descriptions.
• Status reports.
• Slide decks.
• Onboarding docs.
• Changelogs.

All coordination work.

They are the tax you pay for working with other people. Done well, they are worth the tax.

Memory artifacts exist for a different reThey exist because one person's working memory leaks over time. They make past-you's thinking legible to future-you. They capture the things the codebase cannot tell you:

• where the project is right now,
• what you were trying to do,
• what you already tried,
• what you decided,
• what you deliberately cut,
• and what was half-finished when you stepped away.

That is the real documentation problem for people building with AI.

Not:

"How do I explain this project to a stranger?"

But:

"How do I reload my own context after three days, three weeks, or three months away?"

Most existing dev tooling is built around coordination artifacts. That made sense when documentation was expensive to write and usually justified by a team. Humans only write docs when there is an audience worth writing for.

Solo builders often have no such audience.

So they either don't write docs at all, or they let AI generate long coordination-style docs that no one actually reads.

They lose context easily. Then, they return to a side projthe first hour rebuilding a mental model they already had last week.

Traditional docs are not wrong. They are for a different audience.

A README is great when strangers will land on your repo. A changelog is great when users track your releases. An architecture doc is great when someone else has to onboard.

The mistake is using those formats by default when you are alone, when no one will ever read them, and when the actual reader is just future-you trying to remember what mattered.

The new minimum

If the audience is future-you, the docs can be very small.

They have to be small. Long docs do not get read, and getting read is the whole point.

The shortest list I can defend is two documents. Maybe three when something complex is in flight.

The first is State.

One page per project. Overwritten by the AI at the end of every session.

Three sections:

• Just shipped — the last few things that landed.
• Up next — ordered, with the top item being what you would start on right now.
• Open threads — questions, blockerse ends, half-finished thoughts.

This is the homepage of the project. If you open it at 7 AM after a week away, this is what loads.

It is overwritten, not appended, because freshness matters more than history. A stale "current state" page is worse than no page at all. Every glance becomes: is this still true?

Overwriting kills the doubt.

The second is Decisions.

Append-only. Each entry is tiny: date, decision, alternatives considered, reason in one sentence.

"Chose SQLite over Postgres — Postgres was overkill for this project."

"Killed the email digest — engagement data did not justify the maintenance cost."

You do not read Decisions every day. You search it when something feels off and you are trying to remember why you made a choice. It saves you from relitigating settled tradeoffs at 2 AM.

The optional third is Plan.

Only when a multi-day piece of work is in flight. Milestones, risky parts, and a rough approach. When the work ships, the Plan is deleted or compressed into a Decisions entry.

Thole list.

State. Decisions. Sometimes Plan.

No giant docs folder. No performative README for a private project. No changelog no one reads. No architecture doc that goes stale before the code does.

Docs only earn their place when they capture: where you are in time, what you were thinking, what you decided, and what future-you is likely to forget.

The Catch

There is one catch though. AI is naturally too helpful.

Ask it to summarize your project and it will produce a wall of text. Ask it for state and it will add extra sections. Ask it for a plan and it will become comprehensive. It will nuance everything. It will explain everything.

It will make the artifact feel useful while quietly making it unreadable.

That breaks the whole model.

A memory artifact only works if it stays small enough to read.

So the AI needs constraints.

• Produce only these artifacts.
• Use this schema.
• Keep the length under two phone screens.
• Do not add sections.
• Do not nest bullets.
• Write short, concrete sentences.
• Optimize for a tired person reading on a six-inch screen.
• Of course, use html, not markdown.

I do not think the future of solo-dev documentation is a bigger docs folder. I think it is two tiny living artifacts, written by AI, read on your phone, and updated at the edges of your workday.

One tells you where the project is. One tells you why it got there. Everything else is probably coordination theater.

If you're building with AI, I'd love to hear your thoughts on this.