# Build a product people can use Start with one real job your users need to finish. We build the smallest complete release that helps them do it, then use what happens to decide the next step. - First slice: 6 wk - Test gate: 100% - Monitor: Day 1 ## The problem worth solving A roadmap can describe months of features without proving that anyone can complete the work that matters. The expensive misunderstanding is often outside the interface: the records arrive late, an approval depends on another department or a customer cannot provide the information the design assumes. We start with a person doing a specific job. Together we trace the inputs, decisions and result. That gives the team something concrete to build and the business a way to judge whether the release was useful. ## How we build with your team The first release covers a complete journey, including the awkward steps. If someone needs permission to approve a payment or recover an interrupted task, that behaviour belongs in the scope. Decorative features can wait; reliable records cannot. You see working changes as we make them. We explain choices in ordinary language and keep decisions beside the code. Your team helps review the product before each release, using examples from the work rather than a demonstration designed only to look finished. ## Timing and the first release Access, integrations and the work needed to make a release safe affect the plan. We agree the first release date after understanding those dependencies. Useful progress starts on day one: tracing the workflow, exposing an assumption or getting a working environment into your accounts. The first production release follows when the agreed checks pass. We show what is ready and what remains uncertain instead of hiding both behind a percentage-complete report. ## What you keep Your repositories contain the application and its release configuration. Your accounts hold the infrastructure. Tests protect the agreed behaviour, and operating notes explain how to release, observe and recover it. We work through those notes with the people who will use them. Before a pilot grows, we review the evidence: whether people finish the job, where support is needed and what failed. That review sets the next release. See [why a first slice should be small](https://sunclue.com/insights/why-the-first-slice-should-be-uncomfortably-small/) for the decisions that make this approach useful. ## After the first release A new product still needs care once real users arrive. We agree responsibility for incidents, maintenance and changes before launch. [Ongoing ownership](https://sunclue.com/services/own/) covers that work; it does not depend on starting a second project to fix every production problem. ## Questions ### What should we bring to the first conversation? Bring a real example of the work, the people involved and what happens when it goes wrong. An existing specification helps, but you do not need a finished brief to start. ### Do we need to know the full scope first? No. We agree the first user journey, the evidence it should produce and the limits on time and cost. Later work follows what we learn, with changes recorded openly. ### Who owns the product and infrastructure? Your company keeps the code, intellectual property and accounts. We work in your repositories and cloud, with access agreed from the start. ## Talk through your situation Bring the work that is getting stuck. We will help identify what needs attention first. [Book a diagnosis call](https://calendly.com/petaniweb/petaniweb-introduction) ## Related reading - [Get a stalled project moving again](https://sunclue.com/services/rescue/) - [Keep the software running after launch](https://sunclue.com/services/own/) - [Modernise without stopping the business](https://sunclue.com/services/transform/) [All services](https://sunclue.com/services/) --- [Canonical HTML page](https://sunclue.com/services/build/) ยท [Sunclue reading guide](https://sunclue.com/llms.txt)