Approach
How the work actually runs
This page exists because process is the part of an agency you can check before you hire them. Everything below is either something you will see in your own engagement or something you can hold us to in writing.
The engagement
Seven phases, in order
Not every project needs all seven at full weight, but they always happen in this sequence. Skipping the first two is the most expensive shortcut available.
-
Establish the commercial problem
Before scope, before platform, before design. What is supposed to be different afterwards, for whom, and how will anyone know? A brief that says "modernise our website" cannot be scoped or judged; a brief that says "our enquiry volume is fine but the enquiries are unqualified" can be. We will push on this until it is specific, because everything downstream depends on it.
-
Audit what already exists
Analytics for where people leave, Search Console for what they arrived wanting, a technical baseline of Core Web Vitals and accessibility, and a review of the content that already earns traffic. This is also where we find out whether the project you asked for is the project you need — a meaningful share of redesign requests are really content or measurement problems.
-
Scope in writing, with exclusions
A document naming what is included, what is explicitly excluded, what we need from you and when, the assumptions the estimate rests on, and how changes are handled. Exclusions get the same prominence as inclusions. Nothing is billed until both sides have agreed it.
-
Set the budgets before the work
A performance budget and an accessibility target are agreed at the start, not discovered in QA. This matters because both are design decisions as much as engineering ones: a full-bleed hero carousel is a decision that costs a second of Largest Contentful Paint, and a brand colour that fails contrast is a decision that costs a remediation phase.
-
Build in reviewable increments
Work is shown at points where feedback can still change something cheaply — structure before surface, one template before twenty. Review windows are agreed in the schedule, because slow approvals are the single most common cause of a late project and they are much easier to discuss before they happen.
-
Test against reality, not the happy path
Longest headline and shortest headline. Missing image. Eleven navigation items. Keyboard only. Screen reader. A throttled connection on a mid-range Android. The states most projects discover in production are the states we would rather find in staging.
-
Hand over as a deliverable
Repositories, source files, design tokens, documentation and account ownership transfer to you, with a walkthrough for whoever will maintain it. If your team can take the work in-house afterwards, the handover succeeded. Retainers should be something you choose, not something the architecture forces on you.
Boundaries
Five things we will not do
A supplier's refusals tell you more than their capability list. Here are ours, so you can decide now whether they suit you.
-
We will not quote before we can scope
A number produced before the problem is understood is a guess dressed as a commitment, and it is usually the client who absorbs the difference. Where a project genuinely cannot be scoped without discovery, we will say so and propose a paid discovery phase with its own defined output — rather than quoting the whole thing and pricing in the uncertainty.
-
We will not build on a platform we think is wrong for you
Including when you have already chosen it. We will explain why, in writing, and if you want to proceed anyway we will note the disagreement and build it properly — but you will not find out our reservations at the retrospective.
-
We will not hold your accounts
Analytics properties, advertising accounts, domains and hosting are created under your organisation with us granted access, not the other way round. Account ownership used as commercial leverage is one of the most common disputes in this industry and it is entirely avoidable.
-
We will not sell you services you do not need
A significant proportion of enquiries are better served by a smaller engagement than the one requested, and some are better served by no engagement at all. Saying so costs us a project occasionally and costs us nothing in the aggregate, because the alternative is a client who quietly concludes we oversold them.
-
We will not use tactics we would have to hide
No link schemes, no scaled auto-generated content, no doorway pages, no fake reviews, no engagement pods. Not primarily because they are penalised — though they are — but because a tactic you would not want your client to see is a tactic that will eventually cost them.
Standards
What every build meets
These are testable by you, on your own project, with tools you can run yourself. That is deliberate.
-
WCAG 2.2 AA as a build constraint
Contrast is measured when the palette is chosen, focus states are designed when components are designed, and keyboard operation is tested on every interactive element. Retrofitting accessibility after a build costs several times what designing to it costs.
-
A Core Web Vitals budget agreed up front
Targets for Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift are set before design begins and verified in staging against throttled mobile conditions, not on a desktop connection.
-
Security basics, not security theatre
Dependencies pinned and monitored, secrets out of the repository, sensible response headers, input validated server-side, and the OWASP Top Ten treated as a checklist rather than a poster. We will tell you plainly which risks a static or CMS site does and does not carry.
-
Measurement that survives a privacy review
Analytics configured to answer the questions in the brief, consent handled properly, and no tracking added that nobody will ever look at. A dashboard nobody reads is a liability with a maintenance cost.
Questions
How we engage
Do you work on fixed price or time and materials?
Both, chosen by what the work actually is. Fixed price suits work whose shape is knowable in advance — a defined set of templates, a migration with a known inventory. Time and materials suits genuinely exploratory work, where a fixed price simply means we have priced in the uncertainty and you have paid for it either way. What we will not do is quote a fixed price for work nobody can yet describe.
What do you need from us for a project to go well?
A single decision-maker, agreed review windows, and content. Those three predict schedule outcomes better than anything on our side. Committee approval and unwritten content are the two most reliable causes of overrun, and both are much easier to solve at the scoping stage than in week ten.
Can you work with our in-house developers or another agency?
Yes, and it is common. The main thing that determines whether it works is deciding early who owns each interface — the design system, the content model, the deployment pipeline — and writing it down. Ambiguity about ownership between two capable teams causes more damage than a gap in capability.
What happens after launch?
You own everything and can walk away, which is the point. If you would like ongoing support we will propose a defined arrangement with a stated scope and response expectation, rather than an open-ended retainer. If your team would rather take it in-house, the handover documentation is written for exactly that and we will do the walkthrough regardless.
How do you handle disagreements about the work?
The scope document names an escalation contact on both sides from day one, so there is a defined route before anyone needs it. Beyond that, we would rather have the uncomfortable conversation early: most project failures are visible weeks before they are acknowledged, and the cost of raising it is always lower than the cost of not.
Approach
Bring us the constraint, not the wish list.
Send us the problem, the constraint and the deadline. You will get a considered reply from someone who would actually do the work — not a templated proposal.