Nearly every engagement starts at one of those two moments. What follows is the same either way — work built to a standard that usually costs an enterprise budget. Bring in one piece of it, or all four.
Discovery & Strategy and Support & Rescue are where nearly every engagement starts. Design & Development is what usually follows. Accessibility runs through all three as a matter of course — and is also the one thing here you can buy entirely on its own, which is why it leads the list.
A score tells you that something is wrong, not what to change. The reports written here name the specific failure, the success criterion it breaches, and the specific change that resolves it — written so the developer who has to make that change can act on it without a specialist sitting beside them.
The practice behind this was built auditing and remediating enterprise systems to WCAG 2.1 AA, and its most useful result was not a report at all: accessibility ended up positioned as a delivery input rather than a pre-launch scramble, with testing moved out of manual review and into an automated pipeline gate.
Projects rarely fail in the build. They fail because nobody asked what the thing was actually for, who had to be able to use it, what it would cost to keep running once the launch is over, or whether something off the shelf would have done the job for a tenth of the money. Those questions take days to answer and years to unpick.
So discovery here is short, and it ends in something you can act on. If the project isn't worth doing, if a cheaper approach would serve you better, or if the thing you asked for isn't the thing you need, you will hear it. That happens often enough that it's worth saying before you book rather than after.
The recommendation names the rejected options and why they were rejected, so you can disagree with the reasoning rather than just the conclusion. The architecture and platform choice is specific enough to hand to a developer. The range carries the assumptions it depends on, because a number without them is a guess wearing a suit.
None of it is locked to this practice. If you take the document to another firm and they build it, discovery still did its job — you made the decision with the facts in front of you.
See the thinking that turned a static PDF into a searchable public service →
Functional, aesthetically balanced web applications — built to WCAG 2.1 AA as standard rather than as a line item. Accessibility, search visibility and maintainability are the same discipline: making sure the thing can actually be used by whoever arrives.
Every page runs through all three before a build ships. Fail one and it doesn't go out.
The middle one was written here, because the first has a blind spot. axe can't calculate contrast when text sits on a gradient or a translucent layer — it reports those as incomplete rather than failed. Nearly every section background on this site is a gradient, so that bucket is where its text mostly lives. Skim past that bucket and a clean report can still be hiding real failures. The custom pass flattens the layers and tests the text against every colour stop in the gradient, so what comes back is a ratio you can act on rather than a shrug.
See a business launched end to end — identity, storefront and POS →
Some of the best work here started as somebody else's worst week. A site compromised and quietly serving spam. A developer who stopped answering email. An agency winding down with a portfolio of client sites still live and still someone's responsibility. A codebase nobody remaining knows how to deploy.
Inherited work is most of what arrives here, and it doesn't have to start with a discovery phase — an emergency doesn't leave room for one, and insisting on it first is how the bleeding keeps going while the paperwork gets done. The first job is finding out what you actually have. The second is telling you what it takes to stabilise it. Stabilising and rebuilding are different bills, and you get to see both before choosing.
Where it's hosted, which versions are unpatched, what attack traffic is already hitting it, what you're paying for services nobody has logged into in two years — and, more often than anyone expects, whether the domain and the accounts are genuinely in your name rather than your last developer's.
Then a stabilise-or-replace recommendation with a number against each. Both routes have been taken plenty of times here, and the honest answer is not reliably the one that bills more.
See a compromised site taken back from 17,000 bot attacks a day →
See an agency's legacy portfolio carried through its business transition →
This is a partnership, not a vendor arrangement. That means hearing when a project isn't worth doing, when a cheaper approach would serve you better, and when the thing you asked for isn't the thing you need.
Twenty minutes is usually enough to work out whether it's a fit.
Book a 20-minute call