How we work

One process, whether you need a website, a product or a move off an old platform

We build marketing sites, customer portals, booking and membership platforms and internal tools, and we move existing sites onto newer foundations. Every project runs through the same five phases. What changes is the depth of each phase, not the order.

Phase 1

Discover

We learn how your organisation works, who uses it and what has to be right

We start with the people who use what we build and the people who run it day to day. We map the flows that matter, the content and data behind them, and the systems they depend on. Where something already exists, we measure how it performs before changing it.

01
Interview the people who own the content, the data and the commercial targets
02
Map the flows that earn or save money: enquiry, sign up, booking, checkout, renewal
03
Audit existing pages, data models and integrations for gaps and duplication
04
Record constraints: hosting, third-party systems, security and access rules
05
Agree what success looks like and how it will be measured

You leave with a written scope, a list of risks and an agreed definition of done.

Phase 2

Plan

Structure, design direction and a build order you can hold us to

We turn the findings into a plan you can read without a technical background. Structure, data models, integration points and editing rules are decided here. Design direction is set on the screens that carry the most traffic or the most work. Sequencing puts the highest-risk items first.

01
Set the site or app structure, URL patterns and navigation
02
Design the screens that carry the most value, then extend the pattern library
03
Specify data models, content types and editing rules for your team
04
Confirm integrations, authentication and permissions before build starts
05
Break the build into milestones with dates and dependencies

You leave with an agreed structure, a design direction and a milestone schedule with prices attached.

Phase 3

Build

Working software in a shared environment, updated every cycle

Build runs in short cycles against an environment you can open at any time. Content and data structures go in early, so your team can load real material while we work. Performance, accessibility and editing experience are handled as pages and screens are built. You review working software rather than pictures of it.

01
Ship to a shared environment after every cycle so progress stays visible
02
Set up content editing and permissions early so your team can work in parallel
03
Build against real data and real integrations rather than placeholders
04
Keep pages fast and accessible as they are built, and check on real devices
05
Raise any scope change with its time and cost impact before we act on it

You leave with a working environment, a weekly written update and an open record of decisions.

Phase 4

Validate

Testing the flows that matter, on real devices and real data

We test the paths that carry revenue, enquiries or internal work, then the edges around them. Forms, payments, sign ups, search and reporting are checked end to end, including how they fail. Performance and accessibility are measured against the targets set earlier. Your team reviews content in place before anything goes live.

01
Test critical flows end to end, including failure states and error messages
02
Measure performance and accessibility on mobile and desktop against agreed targets
03
Verify tracking and reporting so the numbers you see after launch hold up
04
Check redirects, canonicals and structured data where existing visibility is at stake
05
Collect sign-off from the person who owns each area

You leave with a tested build, sign-off from your team and a record of what was checked.

Phase 5

Launch and aftercare

A planned release, monitoring in place and someone to call afterwards

Release happens in a window we agree, with a checklist and a way back if something behaves unexpectedly. We watch errors, traffic and the critical flows through the first days. Editors and internal users get documentation and a walkthrough of the parts they own. After that we stay available for fixes, changes and the next phase of work.

01
Agree a release window, a launch checklist and a rollback route
02
Monitor errors, uptime and the flows that matter in the days after release
03
Hand over documentation, training and access for the people who run it
04
Compare performance and search visibility against the pre-launch baseline
05
Agree how support and further changes work from here

You leave with a live site or product, documentation for your team and a support arrangement in writing.

Questions we get before we start

Short answers on timing, involvement and cost.

What this protects

Projects fail on unclear scope, late testing and no plan for the weeks after launch

The process removes those three. Each phase ends with something you can read, open or sign off.

Scope in writing

Everything agreed in the first two phases is written down and priced.

Progress you can see

You get access to a shared environment from the first build cycle and a short written update each week, so nothing arrives as a surprise.

Critical flows tested first

Enquiry, sign up, booking, payment and reporting paths are tested end to end, including what users see when something goes wrong.

Search value kept intact

Where a site already earns traffic, we map URLs, redirects and metadata before release and verify them again once it is live.

Measurement you can trust

Tracking and reporting are configured and checked before launch, so what you read afterwards reflects real behaviour.

Cover at launch

Releases run to a checklist with a rollback route, and we stay on hand for fixes and changes through the weeks that follow.

Tell us what you are building and we will show you how we would run it

Let's Talk

See engagements

No lock-in. No obligation.