At some point in almost every app-development project, a business owner gets a message that reads something like: “Feature X is done – it’s been pushed to staging.” And shortly afterwards, they log in, find it doesn’t quite work the way they expected, and a difficult conversation begins.
Neither party is lying. The developer has written the code and it runs without errors. The business owner had a picture in their head of how the feature should behave that was never fully written down. Both are acting in good faith. The problem is that they were measuring done against different rulers.
This is one of the most common sources of friction in software projects – and one of the most avoidable. The fix is not to mistrust your developer or become a technical expert. It is to agree, in advance and in plain English, on exactly what done means for each feature before anyone writes a line of code.
Done must mean that the feature works for the business – not merely that the code has been written.
The Four Stages Between ‘Coded’ and ‘Released’
Releasing a feature is not a single event – it is a ladder with at least four distinct rungs. Most disputes happen because people assume everyone is on the same rung at the same time.
- Coded. The developer has written the logic and it behaves correctly in their local environment. This is the starting point, not the finish line.
- Tested. The code has been verified against agreed criteria – ideally by both developer (automated tests) and business owner (manual, real-world scenarios).
- Approved. The business owner or product lead has formally signed off. Approval is a decision, not an assumption – it should exist as a written record.
- Released. The feature is live for end users. Even after approval, releases can be staggered or gated, so ‘approved’ and ‘released’ are worth treating separately.
When a developer says something is done, they almost always mean coded. When a business owner hears done, they usually picture released. Closing that gap is a shared responsibility.
What Good Acceptance Criteria Look Like
Acceptance criteria are the written conditions a feature must meet before it can be signed off. They do not need to be technical. The best ones are written by the business, because they describe what the user needs to be true – not how the code achieves it.
Even simple statements work well for most SME projects:
- “A new customer can register using their email address and receive a confirmation email within two minutes.”
- “The monthly report shows total sales, broken down by product category, for any calendar month I select.”
- “If a booking is cancelled by the customer, the slot is immediately available for someone else to book.”
Notice what these have in common: they describe an outcome a real person would care about, they are specific enough to test, and they leave no ambiguity about what ‘working’ means. Compare that with “the booking system should work properly” – which can mean almost anything to a developer under time pressure.
Write your acceptance criteria in the language of your business, not the language of code. If you can test it with a browser and a notepad, it’s written correctly.
Why the Business Must Test Real Scenarios
Developers test that their code does what they intended. Business owners need to test that the feature does what the business needs. These are not the same thing, and developer testing cannot substitute for the latter.
This is not a criticism of developers. They test against the specification they were given. If that specification was incomplete – or existed only in someone’s head – testing will be incomplete too.
User acceptance testing doesn’t need to be formal. It means actually using the feature the way a real customer or staff member would, including awkward edge cases:
- What happens if someone submits the form twice?
- What does the error message say if the postcode is in the wrong format?
- Can someone on a mobile phone complete the whole journey without getting stuck?
These are scenarios that slip through developer testing – not through negligence, but because the developer has never answered your customer calls or watched someone struggle with a web form at a trade show. You have. That knowledge is your contribution to quality.
How to Record Issues Without Blaming People
When testing turns up problems – and it usually does – the way you report them matters. Vague feedback like “it doesn’t work” creates defensiveness and wastes time. A simple format removes both problems:
- What I was doing. Exact steps from a clear entry point. “I logged in as a new user, went to My Orders, clicked the June invoice.”
- What I expected. Based on agreed criteria. “I expected to see a PDF download.”
- What actually happened. Specifically, not evaluatively. “I got a blank white page.”
- Evidence. A screenshot or short screen recording (Loom’s free tier works well) removes any remaining ambiguity.
This format contains no judgement. It doesn’t ask whose fault it is. It describes a gap between what was agreed and what exists – which is all a developer needs to reproduce and fix the problem.
Sign-Off as Protection for Both Sides
Formal sign-off sounds bureaucratic, but it is one of the most relationship-preserving steps in a project. Without it, the question of whether a feature was delivered correctly can fester for months – surfacing awkwardly when the next invoice arrives or something breaks in production.
Sign-off doesn’t need to be a formal document. An email saying “I’ve tested the booking flow against our agreed criteria and I’m happy to release it – please go ahead” is perfectly sufficient. What matters is that it exists, is explicit, and both sides have a copy.
For the business owner, sign-off is protection against scope creep – the temptation to say “while we’re at it, can you add X?” without recognising that X was never part of the agreement. For the developer, it is protection against being held responsible for problems arising from changes made after they delivered the agreed work.
Sign-off is not a formality. It is the moment a feature stops being the developer’s responsibility and becomes the business’s asset.
Practical Steps to Get This Right
- Write acceptance criteria before development starts. For every feature, complete the sentence: “This feature is done when…” Keep it specific and share it with the developer before work begins.
- Use a simple tracker for the done ladder. A Google Sheet or Trello board with columns for Coded / In Testing / Approved / Released is enough. Nothing should jump from Coded to Released.
- Block time for testing. UAT is not something you fit between meetings. Schedule a dedicated hour or two per sprint to test real scenarios before sign-off.
- Use screen recording for bug reports. Loom’s free Starter plan lets you record a short clip and share a link. A ninety-second video is worth three paragraphs of description.
- Make sign-off an explicit action. Agree that no feature goes live without a written approval – a message, an email, a ticket comment. Silence is not sign-off.
Start With One Feature
If none of this is in place on your current project, start small. Pick one feature about to go into development and write down what done means for it. Complete the sentence: “This feature is done when…” Share that list with your developer, ask them to confirm it’s achievable, then test against it and make your sign-off explicit.
Do that once and you’ll see how much clearer the conversation becomes. Do it consistently and you’ll spend far less time in post-delivery disputes – and far more time shipping features that genuinely work for your business.
