The demo is the deliverable
Gathering requirements, reviewing designs before they are built, and showing non-technical people how to use what you made - the parts of the job that decide whether the code was worth writing.
I have shipped features that were technically correct, on time, matching the ticket exactly, and useless.
Not broken. Useless - because the thing described in the ticket was not the thing anybody needed, and everyone found out in the demo. That is the cheap version. The expensive version is finding out three months later when nobody is using it.
The work that prevents this is not engineering work, and I spent too long treating it as an interruption to the real job.
Ask what happens after
The single most useful question when someone describes a feature is: what happens next?
“We need a way to feature a product on the homepage.” Fine. What happens after it is featured - who changes it, how often, what do they do when the campaign ends, who notices if it is still there in March?
The answers turn one feature into a different feature. If it changes weekly and three people touch it, the thing to build is a setting the merchandising team controls. If it changes twice a year and one person owns it, hard-code it and spend the time elsewhere.
Same request, opposite implementations, and nothing in the original description tells you which.
The smaller the client, the more this matters. Working directly with a shop owner, nobody hands you a specification - you get a description of a problem and a lot of assumed context. The requirements are real, they are just still in their head.
Review the design before it is built
Sitting in the design review is not the designer’s favour to you. It is where the cheapest changes happen.
The questions worth asking there are boring and save weeks:
- What does this look like with no items? With one? With forty?
- This heading is four words in the design and will be nineteen in German. Then what?
- Is this state reachable, and what puts a user in it?
- Which of these elements do you expect someone to change later?
That last one changes the build more than anything else on the list. It is the difference between a section and a configurable section, and it is much cheaper to know before you start than after.
None of this is criticising a design. It is asking what the design means once real content is in it - which is a question a design cannot answer on its own.
Demo it to the people who will use it
The demo is not a status update. It is the last and best chance to find out you built the wrong thing, and it works properly only when the audience is the people who will actually use it - the merchandiser, the marketer, the shop owner. Not their manager.
Two rules, both learned the hard way.
Show it in their tool, with their content. Not a slide, not a staging URL with lorem ipsum. In the theme editor, on their store, with a real product. The moment it looks like their environment, they start noticing real things.
Let them drive. Hand it over. Watch where they hesitate. Every hesitation is a naming problem, a missing default, or a setting that means nothing to anybody but me. I have renamed more settings after ten minutes of watching someone use them than after any amount of thinking about it alone.
And when the tool is one they will use daily - a menu in a point of sale, a content block on their own site - the demo is also the handover. If they cannot change it without me, I have not finished; I have just made myself necessary, which is a worse outcome for both of us.
The demo only does its job when the person who will use the thing is the one in the room.
Why this is the deliverable
Nobody outside the team experiences the code. They experience the thing they can do afterwards, and whether they can do it without asking.
Requirements, design review, demo - that is where you find out whether the code was worth writing. It is not overhead around engineering. On the projects I am proudest of, it was the engineering, and the typing was the easy part.