Every agency has a process diagram. What matters is what happens inside each box — where the decisions get made, who makes them, and how quickly you find out that something is not working. Here is ours, described honestly.
1. Discovery — understanding the problem worth solving
We start with the business, not the brief. Who are the users, what job are they hiring this product to do, what does success look like in numbers, and what constraints are non-negotiable — compliance, existing systems, budget, launch dates?
Discovery typically runs one to three weeks and produces three things: a prioritised scope, a technical assessment of anything we have to integrate with, and a clear statement of what we are deliberately not building in version one. That last document saves more time than any other artefact we produce.
2. Architecture and design — deciding before building
Two workstreams run in parallel. On the design side, user flows become wireframes and wireframes become an interface design tied to a component system, so that screens are consistent and future screens are cheap to add. On the engineering side, we settle the data model, the integration points, the hosting approach and the security model.
This is the phase where changes are cheapest. Moving a button in a design file takes a minute; moving it after three sprints of implementation takes a day.
The cost of a decision rises with every week you delay finding out it was wrong. Our process is arranged to find out early.
3. Development — short cycles, working software
We build in two-week sprints, each ending with something you can actually use in a staging environment. Code is reviewed by a second engineer before it merges, automated tests cover the paths that would hurt if they broke, and every merge deploys to staging automatically.
You get a demo at the end of every sprint and access to the environment throughout. The point is not ceremony — it is that feedback arrives while it is still cheap to act on.
4. Quality assurance — built in, not bolted on
Testing runs alongside development rather than as a phase at the end. That includes functional testing against the acceptance criteria, cross-browser and device testing, load testing where traffic expectations justify it, accessibility checks against WCAG, and a security review covering authentication, authorisation, input handling and dependency vulnerabilities.
Bugs found in the sprint they were written are cheap. Bugs found in a testing phase three months later are not.
5. Launch and beyond
Launch is a rehearsed sequence, not an event: a staged rollout where the product allows it, monitoring and alerting live before the first user arrives, a documented rollback path, and someone on hand during the first days.
After launch we watch how the product is actually used. The gap between how a team expects a product to be used and how it is really used is where the most valuable roadmap items come from.
What we ask from you
The projects that go best share three things: one empowered decision-maker on the client side, availability for a short weekly check-in, and honest feedback at sprint demos rather than saved up for the end. That is genuinely most of it.