Process — 6 phases
How we work
Every engagement runs the same six phases, scaled to the size of the job. Each one says what happens, what you hold at the end of it, and what we need from your side — because that last part is where most projects actually stall.
Brief
EDIT — typically a few days
Before anything is quoted we work out what you are actually trying to achieve, and whether we are the right studio to do it.
What happens
- You send what exists — an idea, a Figma file, a running product, a problem
- We read it before the call rather than during it
- A call to establish the goal, the constraints and the real deadline
- An honest read on fit, including saying no
What you get
- A written proposal: scope, sequence, price and dates
- A clear statement of what is explicitly out of scope
What we need from youWhatever material already exists, and one person who can make decisions.
Discovery
EDIT — typically days to a couple of weeks
Paid, short, and the cheapest place in the whole engagement to be wrong. We turn a goal into a plan someone could actually build from.
What happens
- Users, jobs to be done, and the measure of success
- Technical constraints: existing systems, data, integrations
- Scope cut into slices that can ship independently
- The riskiest assumption identified and put first
What you get
- A scoped, sequenced plan with estimates
- Architecture and data-model decisions written down
- Flows or wireframes for the first slice
What we need from youAccess to the people who know how the current thing works.
Design
EDIT — runs alongside build once the first slice is set
Interface design done in the same tokens and components the code uses, so what gets approved is what ships.
What happens
- Flows and information architecture before visuals
- Screens for every state — loading, empty, error — not just the happy path
- A component system rather than a set of one-off layouts
- Review together as it goes in, not as a handover event
What you get
- High-fidelity screens and a design system
- A prototype where testing before building is worth it
What we need from youFeedback within the review cycle. Late feedback is the main cause of rework.
Build
EDIT — the bulk of the engagement
Weekly increments against a live URL. You review the running product, not a status document.
What happens
- Work shipped to a preview environment continuously
- A weekly review call against the real thing
- Tests on the paths that cost money when they break
- Scope reprioritised at week boundaries as reality arrives
What you get
- Working software you can use, every week
- A codebase with history, tests and CI
What we need from youOne hour a week for review, and answers to questions during the week.
Launch
EDIT — typically a short, dated window
The unglamorous part: accessibility, performance, error handling and the cutover plan, brought to the standard agreed at the start.
What happens
- Performance and accessibility brought to the agreed budget
- Monitoring, alerting and error reporting wired to real thresholds
- Cutover and rollback plan written and rehearsed
- Deployment automation your team can run without us
What you get
- The product live, monitored and rollback-ready
- Runbooks and environment documentation
What we need from youSign-off on the release, and whoever owns DNS and accounts.
After
EDIT — ongoing, or a fixed transition period
Either we keep it running, or we hand it over properly. Both are normal endings and neither costs you an exit fee.
What happens
- Dependency and security patching on a fixed cadence
- Monitoring and incident response
- Or: transition sessions with your in-house or new team
What you get
- A monthly report of what changed and what we recommend, or
- A clean handover: repo, infrastructure, docs, walkthrough
What we need from youA decision about which of the two you want. We will raise it before you have to.
Commitments
How we behave when it gets awkward
Process documents are easy. These are the parts that cost us something to honour, which is why they are written down.
You review running software, not slides
Every week there is a URL. An unfinished thing you can click beats a polished description of a thing you cannot.
Bad news arrives early
If we think we are going to miss an estimate you hear it that week, not at the deadline. Late surprises are a choice, and we would rather not make it.
A fixed date means flexible scope
When a launch, event or raise fixes the date, we hold it and cut scope to meet it. Holding both fixed is how projects quietly fail.
We optimise for the second year
Boring, well-supported tools and a readable codebase. You should be able to hire someone to maintain this after we are gone.
You own everything
Source, designs, infrastructure and accounts, in full. No hostage dependency on our hosting or licences.
Defects are ours
If we built it wrong we fix it at our cost. We are not precious about the line between a defect and a change request.
Next
What we build with