"Done" for a first release means the core flow works, it's been tested, and it meets a quality bar agreed on before the build — not "every idea is in." A clear definition of done is the short list of things that must be true to ship: the key user action works end to end, it's reliable, and the launch basics are covered. Without it, "done" drifts forever. With it, you actually ship.
Why do you need a definition of done?
Because without one, scope creeps and nothing ever feels finished. A definition of done is agreed up front: the specific things that must work for v1 to ship. It turns "is it ready?" from an opinion into a checklist. I set it before the build starts, so the finish line is agreed instead of negotiated at the end — which is exactly when "just one more thing" quietly delays a launch by a month. Decide the line, then build to it. It also protects you commercially: when "done" is written down, there's no ambiguity about what you paid for and what counts as a new request. The definition of done and the scope are two sides of the same agreement — one says what gets built, the other says when it's finished.
What belongs in the criteria?
The essentials, not the wishlist: the core user flow works end to end, key edge cases are handled, it's tested on real devices, the launch basics are in place (auth, error handling, analytics), and it meets the agreed quality bar. Anything beyond that is a fast follow, not a launch blocker. The skill is separating "must work to ship" from "would be nice" — the second list is where first releases quietly go to die. A useful test for each item: would you hold the launch for it? If yes, it's a criterion; if no, it's a fast follow. That single question keeps the list honest and stops the quality bar from sliding either way — neither shipping something broken nor polishing something nobody asked for.
How is 'done' different from 'perfect'?
Done is shippable; perfect is a moving target. A first release should be good enough to put in front of real users and learn from, not polished into oblivion first. Chasing perfect before launch burns the calendar on things users may never notice, while the actual product question goes untested. I build to done — solid, real, and live — then improve from real usage. Perfect comes from iteration, not from delaying the start. Shipping at done isn't lowering the bar — the core flow still has to be reliable, tested, and trustworthy. It's narrowing what the bar applies to: a small product, fully working, beats a large one that's perpetually almost ready. Done means high quality on a small surface, not low quality on a big one.
What does a definition-of-done checklist look like?
For a first release, it's short and concrete — something like:
- the core user flow works end to end on real devices
- key error and empty states are handled, not only the happy path
- auth and access control work correctly
- basic analytics are firing so you can learn from launch
- the agreed quality bar is met (speed, no known blocking bugs)
- a deploy-and-rollback path is in place
If every box is checked, it ships; if one isn't, it's not done yet. Everything not on the list is explicitly a fast follow, which is what keeps the list from quietly growing into a second project.
Who decides when a release is done?
You and I agree the definition together, up front — then "done" is decided by the checklist, not by either of us in the moment. That's the whole value of writing it down: the finish line stops being a matter of opinion or mood near deadline, and becomes a list anyone can check against. I'll tell you honestly when every criterion is met; you'll know exactly what "met" means because you agreed to it before sprint one. If something new feels essential late in the build, it's a deliberate scope decision you and I make together — add it and move the date, or ship and fast-follow — never a silent slip.
How do I set 'done' on a build?
I write the definition of done into the scope before sprint one: the core flow, the quality bar, the launch checks. It's the same discipline behind how I scope an MVP and my SaaS delivery — agree the finish line, build to it, ship, then iterate. A clear "done" is what lets a first release actually launch instead of drifting. Decide what shippable means, then go hit it.
Related strategy guides
See how to scope an MVP, MVP mistakes that kill launches, and how long it takes to build an MVP.
Not sure what your v1 needs to include? Tell me what you're building — I'll define "done" with you before a line of code.
