Dogfood-Driven Realism
Be the end user, use your product intensely daily, and never ship anything that isn't useful to you.
- Difficulty
- Easy
- Time to result
- ~weeks to results
- Steps
- 4
- Confidence
- 85%
Anysphere's product-development process was built on dogfooding: because the team were themselves the end users (engineers building a coding tool), they used Cursor intensely every day and refused to ship anything that wasn't useful to them. Truell credits this with instilling a realism about where the technology actually is today — a counterweight to hype that kept a human in the driver's seat rather than betting on full automation.
Origin
Michael Truell describing Anysphere/Cursor's founding product process.
Core principles
- 01Being your own end user gives you a built-in, honest quality bar.
- 02Daily intense use surfaces what's actually useful versus what merely demos well.
- 03Refuse to ship anything that isn't useful to you.
- 04Dogfooding instills realism about current tech limits and guards against over-trusting AI.
How to run it
- 1
Build for a user you actually are
Where possible, choose a problem where you and your team are the end users so your judgment is the customer's judgment.
Pro tip This is a strong argument for building tools in a domain you personally live in.
Watch out If you're not the user, you get a 'blind man and the elephant' problem — Truell's team hit this trying to build for mechanical engineers they weren't.
- 2
Use the product intensely every day
Live on your own tool full-time, not as an occasional check.
Pro tip Anysphere was living full-time on their hand-built editor within about five weeks, having thrown away their previous one.
- 3
Gate shipping on your own usefulness
Only ship features that are genuinely useful to you; if it's not useful to the team, it's not ready for users.
- 4
Let daily reality set your view of the tech
Use the honest signal from daily use to stay an 'intense realist' about what AI can and can't do right now, and design accordingly.
Pro tip This realism is what told them the human must stay in the driver's seat rather than automating everything.
Watch out Beware seeing AI do something magical and concluding it's better than a smart person everywhere — daily use exposes the massive gaps.
In the wild
Truell's team hand-built a code editor from scratch and 'after maybe five weeks we were living on the editor full-time,' having thrown away their previous editor, then shipped publicly within about three months of the first line of code.
→ A realism-grounded product and a fast build-in-public loop that fed rapid iteration and early explosive traction.
Common mistakes
Building for users you're not (the blind-man-elephant problem)
Truell's team first spent four months on tools for mechanical engineers they weren't; being unfamiliar with the field left them guessing, one reason they abandoned it.
Trusting a magical AI demo as general competence
Without the reality check of daily use, it's tempting to anthropomorphize a model that shines in one area and over-automate; dogfooding reveals the massive real-world issues that demand keeping humans in control.
Is it for you?
Best for
Founders building tools in a domain they personally practice, especially in fast-moving AI where hype outruns reality.
Not ideal for
Products whose true users are fundamentally unlike the founding team, where dogfooding gives a misleading signal.
From the transcript
“our our product development process was really about dog fooding and using the tool intensely every day and we we never wanted to ship anything…”
“we try to be intense realist about where the technology is today”
“it was after maybe five weeks that we were living on the editor full-time and you know had thrown away our previous editor”
“there's a little bit of a blind man in the elephant problem from the get-go”
From the episode
The rise of Cursor: The $300M ARR AI tool that engineers can’t stop using
Michael Truell (co-founder and CEO)