How we work

Delivery phases

1. 01

   Initial Context Review

   Before any commitment on either side, we review what you've shared — the problem, any existing systems, and rough constraints — to judge whether this is a genuine fit and what a productive next conversation looks like.

   Client input

   A description of the problem and any existing systems or context.

   Our responsibility

   An honest read on fit, and what information we'd need next.

   Output

   A recommendation on whether to proceed to Discovery.

2. 02

   Discovery and Requirements

   We work with your team to understand the business objective, the people who'll use the system, and any constraints — regulatory, technical, or organisational — that shape what's actually possible.

   Client input

   Access to relevant stakeholders, existing documentation, and systems.

   Our responsibility

   Structured discovery sessions and a written summary of findings.

   Output

   A documented set of requirements and open questions.

   Requirements that are still evolving at this stage typically mean a phased approach fits better than a single fixed-scope commitment.

3. 03

   Product and Technical Definition

   Requirements are translated into a concrete product and technical definition — what's being built, in what order, and what's explicitly out of scope for a first release.

   Client input

   Prioritisation decisions and sign-off on what's in and out of scope.

   Our responsibility

   A structured definition connecting business requirements to a buildable plan.

   Output

   A scoped definition used as the basis for estimation.

4. 04

   UX/UI and Prototyping

   Where the project has a meaningful interface, we design and prototype the core flows before full implementation begins, so usability issues surface while they're still cheap to change.

   Client input

   Feedback on flows and prototypes at defined review points.

   Our responsibility

   Interface design and interactive prototypes for key flows.

   Output

   Reviewed designs ready to guide implementation.

5. 05

   Architecture and Planning

   We define a technical architecture and delivery plan sized to the project's actual scale and requirements — not a default template applied regardless of fit.

   Our responsibility

   Architecture decisions, a delivery plan, and an estimate based on the scoped definition.

   Output

   An architecture record and a delivery plan with milestones.

   Estimates at this stage reflect the scope reviewed so far — a scope that changes materially afterward can affect both cost and timeline.

6. 06

   Iterative Development

   We build in short, reviewable iterations, with working software visible throughout rather than a single delivery at the end — so direction can be corrected early if something isn't right.

   Client input

   Regular review of in-progress work and timely feedback.

   Our responsibility

   Iterative implementation with visible, working progress each cycle.

   Output

   A working system, incrementally extended each iteration.

   Change requests introduced mid-development can affect cost and timing — we'll always say so explicitly rather than silently absorbing or ignoring scope changes.

7. 07

   Quality Assurance

   Testing and review are carried out as a distinct discipline from implementation — functional testing, edge cases, and acceptance criteria checked before anything reaches production users.

   Our responsibility

   Structured testing against agreed acceptance criteria.

   Output

   A tested system with known issues documented, not hidden.

8. 08

   Release and Deployment

   We deploy with a rollout plan appropriate to the system's risk profile and user base — including staged rollouts where that reduces risk.

   Our responsibility

   Deployment execution and release-readiness checks.

   Output

   A released system, monitored through the rollout.

   For mobile apps, app-store review timelines and outcomes are outside our direct control — we plan around them, but can't guarantee a specific approval date. Third-party integrations or approvals can similarly affect a release date.

9. 09

   Support and Product Evolution

   After initial release, we remain available for support, iteration, and further development — a distinct commercial scope from the initial build, agreed separately rather than assumed to continue automatically.

   Our responsibility

   Ongoing support and/or further development, as separately scoped.

   Output

   A maintained, evolving system.

• Discovery and technical definitionA scoped engagement to turn an early-stage idea or problem into a concrete technical definition and estimate — useful when requirements aren't yet defined enough to scope a full project.
• Defined-scope projectA project with a clear, reviewed scope, delivered against an agreed plan and estimate — the most common shape once Discovery has produced a concrete definition.
• Phased MVP and product evolutionAn initial release scoped to a core use case, followed by ongoing iteration based on real usage — appropriate when validating a product direction matters as much as the first release itself.
• Dedicated or extended engineering capacityA team or individual specialists working alongside your existing team on a defined workstream, coordinated under the same delivery process described above.
• Modernisation or rescue assessmentAn assessment of an existing codebase or system to determine what can be extended, what needs rebuilding, and what a realistic path forward looks like — before committing to a rebuild.
• Ongoing support and maintenanceContinued support for a system already in production — a separate commercial scope from the project that built it, agreed on its own terms.