Five stages, and you always know which one you are in
Nothing here is unusual. What matters is that it is written down, so you can hold us to it — and so you know exactly what we need from you and when.
Discovery
We work out what the real problem is before proposing a solution to it.
Most briefs describe a solution someone has already settled on. We go back a step and look at the process itself — who touches it, where it breaks, what it costs when it does. Occasionally this concludes that the project you asked for is not the one you need, which is a much cheaper thing to discover now.
You get
- A written scope with explicit assumptions
- User flows for the core journeys
- A fixed price and realistic timeline
- A technical approach you can get a second opinion on
We need
- Access to the people who do the work today
- Examples of the current process, however messy
- Your commercial constraints, stated honestly
Design
Structure first, surface second — validated while changes are still cheap.
We wireframe every key screen before touching colour, because it is far cheaper to discover a flow is wrong in a grey box than in production code. Once the structure is agreed we move to high-fidelity design, including the empty, loading and error states that get forgotten and then improvised badly.
You get
- Wireframes for every core screen
- A clickable prototype to walk through
- High-fidelity designs, mobile and desktop
- A component library for future screens
We need
- Consolidated feedback from your side
- Brand assets, or a decision to create them
- One person empowered to sign off
Build
Working software on a staging link every week, not a status report.
We build in short cycles and deploy each one to a staging environment you can open yourself. That means you are reacting to the actual thing rather than to a description of it, and course corrections happen while they are still small. Code is reviewed and tested as we go rather than in a panic at the end.
You get
- A staging link updated weekly
- A short written progress note each cycle
- Code in your own repository from day one
- Early sight of anything that shifts the estimate
We need
- Content and real data as early as possible
- Timely feedback on each staging build
- Access to any third-party accounts we integrate with
Launch
The unglamorous checklist that stops launch day being dramatic.
Launch is a process, not a button. We test across real devices, verify analytics and forms, map redirects so existing search rankings survive, and schedule DNS changes for quiet hours. Then we train your team on the admin area so the handover is genuine rather than a link and an apology.
You get
- Cross-device and cross-browser testing
- Analytics, search console and SEO baseline
- Redirect mapping to protect rankings
- A recorded walkthrough of the admin area
We need
- Domain and DNS access
- Sign-off on the final staging build
- The team members who need training
Support
Someone who already knows your system when something goes wrong.
The first 30 days of fixes are included: if something does not work as agreed, we fix it. After that, most clients move to a retainer covering updates, monitoring, backups and a steady stream of improvements — because software that is never touched slowly stops working.
You get
- 30 days of post-launch fixes included
- Optional retainer with agreed response times
- Monitoring, backups and security patching
- A named contact who knows the codebase
We need
- A clear route for reporting issues
- A decision on whether you want a retainer
About working together
More at the start, less later. Discovery and design need real attention from someone who knows the business — a few hours a week. Through the build it drops to reviewing a staging link and answering questions. Projects slow down for one reason more than any other: feedback waiting on someone who is too busy.
It usually does, and that is fine. We quote the change separately and you decide whether it goes in now, later or not at all. What we do not do is absorb changes silently and then present a surprise invoice, or wave them through and quietly miss the deadline.
We usually recommend it. Building the smallest version that solves the sharpest part of the problem gets you real feedback from real users, and that feedback almost always changes what phase two should be.
Yes. We can design for your team to build, hand off a documented codebase for them to maintain, or work alongside them on a shared repository with agreed conventions and review.
Every project begins with a conversation
Tell us what is not working. Discovery will tell us both whether there is a project here worth doing.
Free consultation · No obligation · Replies within one business day