--- title: "Full-cycle product development" description: "Discovery, design, engineering and launch handled as one continuous cycle, with the handover documentation that keeps the product operable." canonical: "https://juhenza.com/solutions/product-development" last-updated: 2026-10-15 --- # Full-cycle product development > Discovery, design, engineering and launch handled as one continuous cycle, with the handover documentation that keeps the product operable. ## From first sketch to a maintained release. Products fail in the gaps between stages — between idea and scope, build and launch, launch and maintenance. We run the full cycle as one continuous responsibility, so decisions stay connected from discovery to handover. ## Fit For founders taking a product from idea to first release, and businesses replacing a critical system without an internal engineering team. ## Scope - **Discovery & definition:** User research, workflow mapping and scope definition that produce a buildable specification — including what is deliberately out of scope. - **Design & prototyping:** Interface design and prototypes that test the concept with real users before full engineering investment. - **Engineering & release:** Iterative development with working increments you can review, automated checks on the rules that matter and a rehearsed release. - **Handover & maintenance:** Documentation, deployment access, monitoring and an agreed support arrangement — the difference between a product and an orphan. ## Process 1. **Define success before the build:** Agree users, journeys, constraints and the evidence that says the release worked. 2. **Build in reviewed increments:** Working software at regular intervals, with decisions recorded where they were made. 3. **Launch with ownership:** Release, monitor and hand over — with the documentation that keeps the product operable without us. ## Examples ### An idea to first release - Challenge: A founder has domain knowledge and customers, but no technical team. - Approach: Run discovery to define the smallest useful product, prototype the core journey, then build and launch in reviewed increments. - Deliverable: A launched first release with documentation and a prioritised next-phase plan. ### A legacy system replacement - Challenge: A critical aging system must be replaced without disrupting daily operations. - Approach: Map the real workflows — including the exceptions — build the replacement to run alongside, and migrate in verified stages with a rollback path. - Deliverable: A staged migration with parity checks, training material and decommissioning plan. ### A product rescue - Challenge: A partially built product has stalled: unclear scope, fragile code, no one accountable. - Approach: Audit what exists, stabilise the critical paths and re-plan the release around what is verifiably working. - Deliverable: A stable codebase, an honest status report and a credible path to release. ## FAQ ### Do we need a full specification before starting? No — but you need agreed users, a first-release boundary and acceptance checks. Discovery produces exactly that much definition, and no more. ### Can you work alongside our existing team? Yes. Whether JUHENZA leads the cycle or fills specific gaps, ownership, code review and release responsibilities are agreed explicitly at the start. ### What happens after launch? Support, maintenance and further development are scoped separately, with coverage and response expectations agreed in writing. You are never locked in: the handover makes the product operable by others. ## Reference architecture A reference full-cycle structure. Each stage ends with a decision the next stage can build on, so scope drift is visible early. ### Definition Users & journeys → Release boundary Record who the product serves, what the first release includes and what is deliberately deferred. Review: Check the scope survives contact with real users, and that deferred items are written down, not implied. ### Build Reviewed increments → Automated checks Turn the definition into working software in steps that can be inspected, tested and redirected. Review: Verify each increment runs, the important rules are covered by checks and decisions are recorded where made. ### Operation Release & monitoring → Handover pack Launch with instrumentation and hand over documentation, access and support arrangements. Review: Confirm someone can deploy, restore and support the product using only the handover pack. Illustrative planning model; scope and deliverables are agreed per project. ## Technology choices One accountable cycle from scope to handover ### Definition Journey maps · Release boundary · Acceptance checks Produce the exact definition the build needs: users, scope, boundaries and what proves success. ### Build Incremental releases · Automated checks · Decision records Keep working software in review at regular intervals, with decisions traceable to their context. ### Operation Deployment runbook · Monitoring · Handover pack Ship with instrumentation and document operations so the product remains operable by its owners. ## Quality checks before handover ### Scope held honest Compare each increment against the release boundary; changes to it are recorded decisions, not drift. ### Verified increments Check the important rules with automated tests and review working software at every stage. ### Complete handover Verify access, documentation, monitoring and support arrangements with the people who inherit the product. ## Preparing for a project Bring the problem, who has it, what exists today — documents, code, data — and any deadline that shapes the first release. Start a project: https://juhenza.com/contact