Development
How product development works: from brief to launch and support
A transparent product-development journey: brief, discovery, prototype, estimate, iterations, testing, launch, handover, and support.
The short answer: every stage should produce a verifiable outcome
Product development should not be a long silence between payment and a final reveal. Every stage needs a purpose, something the client can inspect, and a decision: continue, refine the boundary, change direction, or stop before a mistaken assumption becomes expensive.
The ZeroBlack journey is: enquiry and initial qualification, problem discovery, a prototype of the critical journey, scope and commercial agreement, a 20% advance, iterative development, quality assurance, launch, final payment, and product handover. Support and continued development are agreed separately so the live product has clear ownership.
1. The enquiry clarifies the problem; it does not create an instant quote
For the first conversation, describe the business objective, primary user, current workflow, desired outcome, constraints, and any known budget context. You do not need to arrive with a complete specification or guess the architecture; defining those responsibly is part of the work.
The team checks whether the problem fits its capabilities, who can make decisions on the client side, which systems and data are involved, and what could block a start. The output is a clear next step and a list of missing evidence—not a precise price promised from one message.
2. Discovery separates the real problem from a preselected solution
Discovery examines users and context, the current journey, business rules, data, integrations, legal and technical constraints, and the evidence that will measure success. GOV.UK guidance recommends understanding the problem before deciding whether to prototype it; production development should not begin at this stage.
The client provides access to the process owner, recent real cases, current rules, external-system interfaces, and an honest account of exceptions. The output is a problem map, critical risks, a boundary for the first outcome, and a go/no-go decision. Stopping after discovery is valid when the evidence shows that building would not justify the problem.
3. The prototype tests the critical journey and riskiest assumptions
A prototype is not decoration for a presentation. It exposes the critical user journey, data structure, and important states before the team invests in production code. GOV.UK describes alpha as the time to test alternative solutions and the riskiest assumptions with prototypes that are only as complex as learning requires.
The team tests the happy path, errors, empty states, roles, permissions, and transitions. The client brings future users into the review and resolves decisions quickly. The output is an agreed journey and a record of what has been validated, changed, or removed from the first release.
4. Scope, estimate, and terms define the boundary of responsibility
After prototyping, the estimate is based on a concrete user journey, data, integrations, and quality requirements rather than an abstract idea. The boundary records what is included and excluded, client-supplied materials, acceptance criteria, demonstration cadence, infrastructure, release work, source-code handover, and support terms.
At ZeroBlack, a 20% advance is paid after scope and commercial terms are agreed. Change is not prohibited, but a new requirement is first assessed for its effect on the journey, budget, and release. This protects both sides from a feature request silently redefining the entire project.
5. Architecture and design cover more than the ideal screen
Before active development, the team defines the data model, roles and permissions, system boundaries, integrations, personal-data handling, analytics, backups, and expectations for performance, security, and accessibility. Interfaces are designed for desktop, tablet, and mobile with realistic content rather than convenient placeholders.
The review covers loading, empty data, failure, unavailable integrations, retries, and recovery—not only an ideal home screen. Accessibility criteria refer to WCAG, while non-functional requirements become part of acceptance rather than a task postponed until after launch.
6. Development proceeds through short, inspectable iterations
An iteration should end with a working increment that can be inspected against the agreed definition of done. The official Scrum Guide links each Increment to a Definition of Done and uses review to inspect the outcome and adapt what happens next. A percentage-complete report is therefore not a substitute for demonstrating the real journey.
Each review records accepted decisions, feedback, blockers, and the next outcome. The client supplies access, content, and decisions within the agreed window; the team exposes constraints and risks before they affect release. This rhythm keeps delivery manageable without pretending the plan will never change.
7. Quality assurance proves readiness, not the absence of obvious bugs
Quality assurance covers more than the happy path: critical journeys, permissions, validation, repeated actions, slow networks, external-service failures, device classes, analytics events, baseline security, backups, and recovery. Web products also need indexability and technical SEO foundations; applications need build, permission, and store-readiness checks.
Every defect has a severity, reproducible scenario, and either a pre-release resolution or an explicitly accepted limitation. Acceptance uses criteria written before the review, so 'it looks similar' cannot replace testing system behaviour and data.
8. Launch includes rollback, observability, and an accountable owner
Before launch, the parties agree on production environments, domains and certificates, migration, backup, rollback, analytics, monitoring, and an incident channel. A mobile release also requires metadata, a processed build, testing, and store review, so its publication date does not depend on the development team alone.
After release, the team checks the critical journey, forms, payments or other key operations, analytics events, and errors. Launch has an accountable owner and an observation window. If control conditions fail, the team restores a safe version or disables the affected capability according to the agreed rollback plan.
9. Handover means real ownership, not merely receiving a link
After acceptance and final payment, the client receives the agreed package: source code, repositories, infrastructure and analytics access, domains and publishing accounts under the chosen ownership model, deployment, backup, and administration instructions, plus a record of known limitations.
Handover follows a checklist and verifies access through client-owned accounts. Secrets should not remain in chat or belong to a single contractor. The team explains how to deploy the product, where to observe its health, and how to respond to a common incident.
10. Support separates defects from evolution and keeps measuring outcomes
A live product starts generating real evidence. Support covers agreed responses to defects and incidents, infrastructure maintenance, and dependency updates. New journeys, integrations, and substantial interface changes are estimated as continued development so operations do not become an endless, undefined task list.
The roadmap is guided by user behaviour, support requests, technical signals, and the business measures defined during discovery. Iterative delivery means continuing to learn from and improve a working service. Launch completes production of the first release, not responsibility for its outcome.
What the client should see before the next stage begins
Every gate should have evidence that supports the next decision: a problem map after discovery, a tested journey after prototyping, scope and acceptance criteria before development, working demonstrations during production, a readiness record before launch, and a handover package after acceptance.
If a team cannot show these artefacts, name the decision owner, or explain what happens during failure, risk is hidden inside the process. Transparent development does not promise that nothing will change; it makes the reasons, consequences, and ownership of change visible before they become expensive.