What “Done” Means in Engineering — and Why It Keeps Moving

The most common source of founder-engineering friction isn't disagreement about priorities or estimates — it's mismatched expectations about what “done” means at any given moment. An engineer who says “it's done” most likely means the code is written, the tests pass, and it's ready for review. A founder who hears “it's done” often interprets that as “it's available for customers.” In between those two states there are typically four to six additional steps that no one has named.

The states between “code complete” and “live for customers” vary by team, but a typical path looks like this: development complete, code reviewed and merged, deployed to a staging or QA environment, tested by QA, deployed to production, validated with real traffic — and sometimes, feature-flagged for a limited test group before full rollout. Each of these steps takes time. The jump from “code complete” to “in production” frequently takes as long as writing the code did, especially for features with external dependencies or significant user surface area.

When these steps are invisible, every status update becomes a trust problem. Founders ask “when will this be live?” and get answers that turn out to mean “live on staging.” Features that were “done two weeks ago” still aren't in customers' hands. The failure isn't dishonesty — it's that everyone is using the same word to mean different things, and no one has established a shared vocabulary for the states in between.

A feature goes through distinct states before it reaches customers, and each state has a specific meaning. Development complete means code is written and the developer believes it works. Code reviewed and merged means at least one other engineer has read the code and approved it. Deployed to staging means the code is running in a non-production environment that mimics production. Integration tested means the feature has been validated in the staging environment, often by QA or a product reviewer. Deployed to production means the code is running where customers can access it. Validated means someone has confirmed it's working correctly with real traffic.

A definition of done is an upfront agreement about which of these states a feature needs to reach before it counts as done — and who needs to verify each step. Without a definition of done, every engineer on your team is implicitly applying their own definition, which may not match yours or each other's. This is fine when every engineer has the same background and expectations. It's a problem as soon as you have more than one or two people, or whenever you're under deadline pressure and someone decides to abbreviate the process without telling anyone.

Before any feature goes into development, agree in writing on what done means for that specific feature. It doesn't need to be elaborate. A one-paragraph definition that answers: what environments does it need to pass, what tests are required, who reviews and approves it before it goes to production, and what does the production deployment process look like. That's enough to prevent the most common mismatches. The act of writing it down forces a conversation that surfaces assumptions before they become surprises.

Make the states visible during development, not just at the end. A simple board or status field that shows whether a feature is in development, in code review, on staging, in QA, or in production gives you a real-time view of where things are without requiring constant check-ins. Founders who can see “in QA” don't ask “is it done?” — they can see it isn't live yet and understand why. The transparency replaces the friction.

For features with significant deployment risk — anything that touches billing, authentication, or core user data — add a validation step explicitly: who will confirm it's working correctly after it goes to production, and what are they checking? This step is almost always skipped under time pressure, and it's almost always the step that catches the problem that made it to production anyway. Naming it in advance makes it part of the process rather than an afterthought.

The gap between code complete and in production is where most timeline surprises live. For teams with a thorough review and deployment process, this gap is predictable and accounts for it in estimates. For teams with an inconsistent process, this gap varies wildly — sometimes a day, sometimes two weeks. The variability is the problem. When founders can't predict how long post-development steps take, they can't plan around them. A definition of done with named steps and rough expected durations makes this gap predictable, even if it doesn't make it smaller.

A practical definition of done for most startup features covers six elements: the environments the feature must pass (at minimum, staging and production), the automated tests that must succeed, the manual review steps and who performs them, the deployment approach (direct to production, behind a feature flag, or gradual rollout), the validation criteria after deployment, and the rollback plan if something goes wrong. This isn't bureaucracy — it's the minimum set of agreements that prevents a feature from being “done” three separate times before it actually reaches customers.