Before we write code, we try to answer a less glamorous question: what would make this project genuinely useful six months after launch?
That question changes the conversation. It moves attention away from feature lists and towards the decisions people make every day. It also exposes assumptions early, when they are still inexpensive to correct.
1. Understand the operation
We ask for examples, not general descriptions. A sample invoice, a real reporting routine, the exact moment a customer gets frustrated. We map who does what, where information comes from and what happens when the process breaks.
2. Define the smallest useful version
Not every good idea belongs in version one. We separate the workflow that must work from the features that would be nice later. This protects the budget and gets something real into people’s hands sooner.
3. Agree how decisions will be made
Projects slow down when feedback has no owner. We agree who can approve screens, who can change scope and how quickly responses are needed. Clarity here is worth more than another planning document.
4. Build in visible increments
We prefer regular previews to a dramatic reveal. Seeing a working piece early makes it easier to say “this is wrong” before the wrongness is expensive. It also keeps the project grounded in real use.
5. Handover is part of the build
Training, documentation and access details are not afterthoughts. They are part of the deliverable. A system that only the builder understands is not finished.
Good process does not remove every surprise. It makes surprises smaller, earlier and easier to discuss. That is usually the difference between a project that launches and a product that lasts.