From a product idea
to a working release.
A clear scope, connected design and development, regular reviews and a launch with ownership in place.
Understand the product.
We begin with the users, their task and the existing workflow. Research, operational examples and current tools help distinguish a useful product requirement from an assumption that still needs testing.
The first output is a product brief with the core journey, roles, constraints and open questions. We identify the product owner, the people who can review the workflow and the dependencies that could affect delivery.
Design the first release.
The brief becomes a prioritised release scope, user flows and interface designs. Prototypes help review the journey before development, while technical checks address uncertain integrations or platform requirements.
Acceptance criteria describe the behaviour the first version must support. The team can see which features are included, which are deferred and which decisions still require evidence.
Build and review working software.
Interfaces, APIs and integrations are developed in reviewable increments. Shared environments let the product owner try the real workflow and resolve questions before the release is treated as complete.
Testing follows the agreed journeys, roles and supported devices. Loading states, invalid input, permissions and interrupted requests are reviewed alongside the successful path.
Release, hand over and evolve.
Release preparation covers the build, production configuration, account ownership and the people responsible after launch. Mobile projects include the agreed store-submission work and its external review dependencies.
Handover includes the agreed source, design files, operating notes and known issues. Support and future releases follow an explicit arrangement, with priorities informed by real use.
Review the working journey.
Each review has a clear purpose: resolve a product decision, test the interface or accept working behaviour. The scope and the current build provide the shared reference.
- Which user task is this version ready to demonstrate?
- Which acceptance criteria are already agreed?
- Is the feedback a defect, a changed requirement or a preference?
- Who resolves conflicting priorities?
- What is accepted, what changes and what blocks the release?
When the brief changes
New information is welcome. If it changes the task, we review the consequences for scope, timing and cost before proceeding. Keeping the change visible is part of keeping the relationship clear.
Clarity includes
who owns what.
Ownership of source code, design files, hosting, store accounts and external services is agreed in the scope. The product owner should know where the application lives and who can operate it.
The delivery record includes the agreed source, configuration guidance, release notes and known issues. Support hours, response arrangements and future development are specified separately.
Read the application release checklist →The right arrangement follows the work.
Choose a discovery sprint, a defined first release or continuing product development.
Explore ways to work