What 'Done' Really Means: Value, Not Just Code
16 Jul 2026
A recently circulated developer essay is pushing back on one of software's most casually used words: done. Its argument is simple but pointed—"done" isn't the end of effort, it's the moment value is actually created in the world.
The core claim
The essay frames done as a claim about reality, not about effort. That reframing carries a strict checklist. According to the piece, work is only done when:
- It works on all supported devices
- It has been tested through multiple rounds of feedback and iteration
- Its pull request is merged
- Related work from teammates is also complete
- It is live in production and available to intended users
Under this definition, a long list of familiar milestones don't count as done. Code that only runs on a developer's own machine isn't done. An unmerged PR isn't done. Code sitting on a dev or staging environment isn't done. Even code that's deployed to production but not yet available to users isn't done. And if a teammate still has related work outstanding, the task—per this definition—remains incomplete.
Why this matters
The distinction the essay draws is between shipping code and creating value. A feature can be technically finished from an engineering standpoint while still delivering zero value to a user—because it's stuck behind a merge, an environment gap, or someone else's unfinished dependency. The essay's position is that none of that counts until value shows up in the real world, for real users.
Risks and open questions
The report flags several tensions in applying this definition literally:
- Shipping speed: Strict adherence could slow teams down if they wait for full cross-team completion before calling anything done.
- Ambiguity: What exactly counts as "value created" is left undefined, which could lead to inconsistent interpretation across teams.
- Dependency bottlenecks: Tying "done" to a teammate's separate work risks creating blame cycles or blockages when one person's task depends on another's timeline.
There's also missing context worth noting: the essay offers no concrete examples, no publication date or author identity, and no metric for measuring when value has actually been "created in the world." It's also unclear how the framework applies to partial rollouts—feature flags, phased releases, and similar real-world deployment patterns common at startups.
Why founders should care
For early-stage teams, this framing is likely to resonate more as a mental model than a strict rulebook. It's plausible that adopting a stricter definition of "done" could help align engineering and business teams around user outcomes rather than internal milestones like merged code or staging deploys. It may also reduce disputes over whether something is actually finished, since the bar becomes "is it live and usable" rather than "is my part complete."
At the same time, founders should weigh this against velocity. Teams operating in fast iteration cycles may find that requiring full production availability and cross-team completion before calling something done risks slowing delivery cadence—especially in orgs where dependencies across teams are common. It could be worth auditing your own team's definition of done: does it already require production deployment and user access, or does it stop at code review and merge? Tightening that definition, even partially, may improve accountability—but doing so rigidly, without accounting for phased rollouts or feature flags, carries real risk of introducing new bottlenecks rather than removing old ones.
Bottom line: The essay's message is directionally useful—value to users is the real finish line, not a merged PR—but founders should treat it as a prompt for internal discussion rather than a fixed process to import wholesale.