How we take a project from brief to release

A project starts with a boundary, not a mockup. We write down which problem the first version solves and what is deliberately left out. That is shorter than a full specification, and it is enough to keep the third week from drifting. The rhythm stays the same after that. Once a week we show a working slice: not slides, but a product you can open. If the direction is wrong, it shows while changing it is still cheap. At release you keep the repository, the data schema, the access, and a short note on how to run the project. Support is a separate agreement, not a hidden condition the code needs in order to start.