Process
How we run a project
- 011–2 weeks
Discovery
We work out what is actually being solved before anyone opens a design tool. Stakeholder interviews, a look at how the work happens today, a review of any existing system, and a written problem statement everyone signs off on.
You receive
- Problem statement and success metrics
- User flows and feature inventory
- Technical constraints and risks
- Fixed scope, timeline and estimate
- 022–4 weeks
Design
Structure first, decoration later. We wireframe the flows, get them wrong quickly and cheaply, then move to high-fidelity screens once the shape is right. Every state gets drawn — loading, empty, error, success — because those are the ones that derail a build.
You receive
- Clickable prototype for user testing
- High-fidelity screens at every breakpoint
- Tokenised design system
- WCAG 2.2 AA contrast and focus review
- 036–20 weeks
Build
Two-week increments, each ending in something you can click. Code is reviewed on every pull request, tests and accessibility checks run in CI, and a preview environment is deployed automatically so feedback happens on real software instead of screenshots.
You receive
- Weekly demo of working software
- Preview environment on every branch
- Automated tests and CI checks
- Fortnightly written progress summary
- 041–2 weeks
Launch
Production infrastructure, monitoring, analytics and error tracking configured before go-live rather than after the first incident. For mobile, we handle store listings, review submission and phased rollout.
You receive
- Production deployment and rollback plan
- Monitoring, logging and alerting
- App Store and Play Store submission
- Documented handover and training session
- 05Ongoing, optional
Support
Software decays if nobody tends it. A retainer covers dependency and security updates, uptime monitoring, bug fixes within an agreed response time, and a monthly block of hours for the changes that inevitably come up.
You receive
- Security and dependency patching
- Uptime and performance monitoring
- Agreed bug response times
- Monthly development hours
Principles
How we make decisions
Working software over status reports
A demo you can click tells you more in five minutes than a progress deck tells you in an hour.
Say the hard thing early
If a deadline is unrealistic or a feature is a bad idea, you hear it in week one, not week ten.
Small batches
Long release cycles hide problems. Shipping every two weeks means mistakes are caught while they are still cheap.
Leave it better documented than we found it
Handover is a deliverable. READMEs, architecture notes and runbooks, not a knowledge transfer call and good luck.
FAQ
Process questions
How involved do I need to be?
Roughly two to three hours a week: one demo call, one feedback round, and availability on the shared channel for questions. Discovery is more intensive — expect a couple of longer workshops in the first fortnight.
What if the scope changes mid-project?
Scope changes are normal. Anything outside the agreed scope gets written up with an estimate and waits for your approval before work begins. Nothing gets built, and nothing gets invoiced, without you agreeing first.
Do you sign NDAs?
Yes, routinely, and we can sign one before discovery starts. We are also happy to work within your security requirements including restricted repository access and VPN-only environments.
What if we are not happy with the work?
Every project runs in two-week increments with a demo at the end of each, so problems surface early. Contracts are structured so you can stop at the end of any increment, and you keep everything produced up to that point.
Have a project in mind?
Tell us what you are trying to build. You will get a straight answer on scope, timeline and cost — usually within one working day.