I'm 60. Self-taught for about 40 years. I build alone.
For the last 18 months I've been living inside a loop that most startup decks call "dogfooding", and then stop at "we use our own CRM."
That version never interested me much.
Classic dogfooding is useful. It just wasn't enough.
When a team says they dogfood, it usually means: someone on the squad opens the product twice a week and files tickets.
Fine. You'll catch UI bugs. You won't catch the real failure mode of solo work with AI:
every new session starts from zero, and you're the one who has to rebuild the context by hand.
If you code with Claude, Cursor, Copilot, you know the drill. Monday you explain the stack. Wednesday you re-explain the architecture decision. Friday you paste three files and hope the model remembers the trap you already fixed in March.
The product I needed wasn't "another todo list I also use." It was a system where my notes, my decisions, and the AI talking to me share the same memory.
So I built that system for myself. Then I used it to keep building it.
That's the loop.
The test that actually matters
I don't ask "does this feature look good in a demo?"
I ask: did today get harder or easier because of this tool?
If capture is slow, I feel it before lunch.
If project context is muddy, the AI starts inventing.
If secrets end up in chat because the "safe path" is annoying, I took the bad path myself, and I know the design is wrong.
No staging environment will teach you that as fast as living in it.
Stress-test: more than one kind of project
Something I didn't plan for: the same structure has to hold for different brains of work.
| Kind of work | What breaks if the model is weak |
|---|---|
| API / infra | decisions and traps disappear between sessions |
| Long writing | characters and chronology drift |
| Admin / life admin | you lose the thread and reopen the same PDFs |
If a system only works for "software tickets," it's a ticket app.
If it also holds for a novel draft and a boring administrative folder, the model is doing something deeper: structuring thought, not just listing tasks.
Also: a lot of days I use the structure without asking an AI anything. That was a surprise. The AI is useful. The memory is the product.
Make the loop leave traces
Dogfooding that only lives in your head evaporates.
What helped me:
- git commits that also create a journal line I can reread later
- a roadmap that isn't theater, it reflects what I actually shipped
- a backfill script that turns old
fixcommits into closed actions, so the history isn't just git noise
I'm not saying you need my scripts. I'm saying: if dogfooding doesn't leave structured traces, you're journaling in fog.
Honest, not performative
I don't mock the production VPS in tests. Real network. Real DPI drama from my ISP. Real "port 22 is weird today, so SSH over WebSocket it is."
Ugly. Useful. Exactly the kind of friction that never shows up in a polished launch video.
And boundaries matter: not every project should be visible to the AI token. Dogfooding includes respecting your own walls. A novel draft and a production API are not the same exposure level.
What I actually learned
The useful dogfooding for solo builders, in 2026, is rarely:
"I use my product sometimes."
It's closer to:
"My tooling is the nervous system of how I work with AI,and if that nervous system fails, my day fails."
I'm not here to sell you a stack. I'm here because this is how I stay coherent while building alone, late in a career that started long before "prompt" was a verb.
If you're solo, juggling contexts, and tired of re-explaining yourself to a model every morning, you're not imagining the problem. You're living the missing layer.
I'm still in that loop. Eighteen months. Daily. Still learning where it breaks.
0 Comments
Log in to join the conversation.No comments yet. Be the first to share your thoughts.