Process
How we run a project, from first conversation to launch.
For websites, platforms and web applications we work through six stages: strategy, design direction, technical foundations, implementation, quality assurance, and launch and handover. The timing and the work inside each stage vary by project, while the checkpoints stay the same.
- Stages
- 06
- Refined since
- 2017
- Checkpoints
- 06
- Post-launch support
- 30days
01 · The approach
A clear process, adapted to the project.
The stages below are the framework we have used for web projects since 2017. Projects vary in size and do not all call for the same activities, but the order in which the main decisions are made stays broadly the same. Brand identity projects follow an adapted route, set out in the proposal.
Before work starts, we agree what the project includes, what we will deliver, what we need from your team and how the work is sequenced. The deliverables, schedule and responsibilities then go into the proposal and the contract, so at every stage you know what we are doing, what comes next, and what needs approval before we carry on.
02 · The stages
From objectives to a launched, handed-over product.
Six stages and six checkpoints. The framework stays the same, while the activities and deliverables are adapted to the project and agreed in the proposal before work begins.
01
Strategy and scope
We start by establishing what needs to be built and why. We review what already exists, speak to the people who will use or manage the product, and clarify the objectives, audiences, content and the technical and operational constraints. On larger projects the stage can also take in competitor research, a content audit, user interviews or the definition of the key journeys.
What you receive
- A written project brief
- User flows and information architecture
- Project scope and priority order
- A technical recommendation
- A plan for the remaining stages
Checkpoint
We go through the brief together and agree the objectives, priorities and direction before design work begins.
02
Design direction
Before designing every page and screen, we take a single representative area a long way in detail. On a website that is usually the home page; on an application it may be a key journey. This is where the visual language is settled: typography, colour, spacing, components, interface behaviour and tone. The approved direction becomes the basis for the rest of the project.
What you receive
- The full design of the representative page or journey, for mobile and desktop
- The first version of the design system
- A written rationale for the main design decisions
Checkpoint
We present the direction and refine it within the revision allowance set out in the proposal. After approval, substantial changes of direction can affect the schedule and the fee; we discuss any such change before making it.
03
Technical foundations
We select and configure the technologies suited to the project, following the technical recommendation from the first stage. We build the shared foundations: navigation, typography, the rules of the visual system, the main page structures and the common components. We write custom code with strict typing and Server Components. AI tools may speed up parts of the process, but every deliverable is reviewed and owned by our team.
What you receive
- A first working version in the test environment
- A private preview address for the work in progress
Checkpoint
We complete our own technical review and show you the progress before building the remaining pages and functionality.
04
Pages, content and functionality
This is where we build the pages, components, content structures and features the project calls for. Depending on the project, that can include forms, integrations, administration areas, user accounts, payments, migrations and application-specific logic. Content is entered or migrated according to the responsibilities and deadlines agreed in the proposal.
What you receive
- The complete review version in the test environment
- The page structures and components included in the project
- The agreed functionality, implemented
- The content included in the project and supplied by the agreed deadline, entered or migrated
Checkpoint
We run a structured review against the approved requirements and design, and fix implementation issues. Requests that change the agreed requirements, content or direction are assessed separately before they are added.
05
Accessibility, performance and quality assurance
Before launch we set aside a separate stage for checking. We test keyboard navigation, screen reader use, contrast, alternative text and semantic structure. We measure performance on representative pages under defined test conditions, and verify the build in the browsers and on the devices that matter for the project. We fix what falls within our own implementation and document the limitations that come from external services, integrations or content.
What you receive
- An accessibility evaluation report against WCAG 2.2 AA for the agreed scope
- Lighthouse results for the representative pages — we commit to a minimum of 90 under the agreed test conditions
- Verification in the browsers and on the devices agreed for the project
- A final quality assurance report, with any limitations documented
Checkpoint
We present the results of the checks and agree the version approved for launch.
06
Launch and handover
We deploy the approved version to the live domain. We configure redirects, the SSL certificate, analytics and monitoring, and the elements needed for search indexing, where these are included in the project. We then show your team how to manage the content and the operations available in the administration interface.
What you receive
- The project live and working on the agreed domain
- A launch plan and an administration guide written for your project
- The accounts and access credentials specified in the contract
- The source code and documentation specified in the contract
- 30 days of post-launch support
Checkpoint
The project is live, access has been handed over, and your team knows how to manage the administrative functions agreed. The included support period starts here.
03 · After launch
30 days of included support.
Every project includes 30 days of support after launch at no additional cost. During that time we fix defects that surface in real use and make the small adjustments needed to bring the delivery in line with the approved requirements and design. Included support does not cover new functionality, additional pages or content, design changes, or changes to the approved requirements; for those we agree the deliverables, schedule and fee separately before the work starts.
At handover you receive the source code, the access credentials and the documentation specified in the contract. The project does not depend on carrying on with us: you can run it internally, within the interfaces we build, or hand it to another team. Where a feature has a justified dependency on a third-party service, licence or module, we explain that dependency before implementation and you approve it. After 30 days only the included support period ends — we can carry on with maintenance, availability monitoring, content or further development under a separate agreement.
04 · How we price
A clear price for a defined project.
Before a proposal, we have a clarifying conversation and carry out a preliminary assessment of the project. If we are the right fit for what you need, you receive a written proposal covering the deliverables, schedule, responsibilities and fee. We do not work with fixed packages, because the projects we take on differ in structure, functionality, integrations and volume of content.
- The proposal is priced against the agreed deliverables and requirements, not against an open-ended number of hours.
- We state plainly what is in the price, what is not, and which third-party services may carry separate costs.
- The agreed price holds as long as the requirements and conditions of the project do not change, and any new cost is discussed and approved before it arises.
- Payment is usually staged: a deposit on signing, an instalment when the design direction is approved, and the balance on delivery. The split can be adapted to the project.
- If you already have a budget, tell us. We will explain what can be done within it and what would need to be prioritised or adjusted.
05 · Start
Have a project in mind?
Send us a few lines about what you want to build. We reply within 24 hours and tell you directly whether we are the right team for the project — including when the answer is no.