Website Design & Development
A site that loads, converts, and does not need us to change a phone number.
Most of the sites we are asked to look at are not bad designs. They are unmaintained: a theme that stopped getting updates, a plugin stack nobody dares touch, a contact form quietly delivering to a mailbox that closed in 2022, and a login only the agency that built it has. The business is paying for the domain, using it for mail every day, and losing the search to a competitor whose site simply answers faster. We build the replacement on a stack where the fast, accessible, secure version is the default rather than an upgrade, and then we either hand you the keys or keep running it, whichever you actually want.
- Largest Contentful Paint budget the templates we ship are held to
- <2.0s
- WCAG 2.2 conformance target on every build
- AA
- Repository, domain and analytics, in your accounts from day one
- Yours
Sounds like
You might recognize one of these.
The company that built it stopped replying, and we can’t get into anything.
We pay a monthly fee and nothing has changed on the site in two years.
It looks fine on my laptop and it’s unusable on a phone.
We need to change the hours and we have to email somebody to do it.
The contact form works, but we have no idea where the messages go.
The site went down over a weekend and we found out from a customer.
What this includes
The work, specifically.
Not every engagement needs all of it. This is the range we cover and what each part is actually for.
Design and build, fast by default
Prerendered pages served from a CDN, images sized and encoded at build time, and a performance budget enforced in CI rather than measured once at launch. Nothing here is a plugin you have to keep buying: the speed is a property of how the site is assembled.
Content you can actually edit
Hours, staff, prices, photos and posts change in a content editor by someone who is not a developer, with a preview before it publishes. We scope this deliberately: an editor that exposes every layout decision is one nobody touches, and an editor that exposes nothing is a support ticket for a phone number.
Rescue and replatform
Taking over a site somebody else built: getting you back into the registrar, the DNS, the host and the analytics; auditing what the previous build actually does; and either fixing it in place or moving it with the URLs and their redirects mapped first. Traffic loss at a relaunch is nearly always the redirects, and it is preventable.
The paths that turn a visit into work
A quote request, a booking, a call, a directions tap. We instrument them, we make delivery provable, a form that submits and silently fails to send is the single most common defect we find, and we say plainly which page is losing people rather than redesigning the one that is fine.
Accessibility as a requirement
Built to WCAG 2.2 AA: keyboard paths, focus management, contrast, screen-reader semantics, target sizes. It is a procurement requirement in public-sector and enterprise work, it is the ground ADA complaints are argued on, and it is better for everyone else too.
Ownership, in your accounts
The repository, the domain, the DNS, the host, the analytics and the mailbox are in accounts with your name on them, on day one and not at the end. Every rescue we do is somebody discovering the alternative.
Hosting, monitoring and care
Uptime and certificate monitoring that pages a human, dependency and platform updates applied and verified, backups that have been restored at least once, and a small monthly allowance of changes. This is the part that decides whether the site is still good in three years.
Findability foundations
Titles, structured data, sitemaps, a Google Business Profile that matches the site, and the map-pack signals a business with an address or a service area actually gets found through. Deeper diagnosis is its own engagement rather than a line item padded into this one; see Search & AI Visibility.
What you get
Deliverables, not documents.
- Production site, responsive from 320px up, prerendered and served from a CDN
- Repository, domain, DNS, hosting and analytics in accounts you own
- Content editor with the fields your team actually changes, and a preview
- WCAG 2.2 AA conformance report against the templates we ship
- Core Web Vitals budget enforced in CI, not a launch-day screenshot
- Redirect map and a launch checklist for anything replacing an existing site
- Form and call delivery tested end to end, to a mailbox you can name
- Uptime, certificate and backup monitoring, with a restore proven once
- Written handover: how it is edited, deployed, and who to call
Shapes
How this usually runs.
Site rescue
1–2 weeksFor a site that is inherited, broken or locked away. We recover access to the registrar, DNS, host and analytics, audit what the build does, verify whether the forms deliver, and come back with what is worth fixing in place and what is worth replacing, costed both ways. You keep the audit whether or not we do the work.
Design and build
3–6 weeksA new site, from content and structure through design to launch, with a staging URL you can read from the first week. Fixed fee, quoted against the number of page types rather than the number of pages, because the second one is a content question and the first one is the engineering.
Care plan
Ongoing, monthlyHosting, monitoring, backups, platform and dependency updates, security patching, and a set allowance of content and design changes each month. Cancellable, and the exit is real: the site is already in your accounts, so leaving is a handover rather than a rebuild. Priced on the first call.
Tooling
What we build it with.
No tool here was picked because it was new. Where we do reach for something novel, it is in one place, for a stated reason, and it is written down.
- Build
- Content
- Hosting & delivery
- Quality & care
Questions
Websites, honestly.
You do, and not conditionally. The code lives in a repository under your account, the domain stays at your registrar, and the hosting and analytics are in your name. A care plan is a service you buy each month, not a lease on your own website, which is the arrangement that makes the plan worth having, because we have to keep earning it.
Yes, for the things that change: text, images, hours, staff, prices, posts. We agree that list during the build, because the useful version of this is narrow. An editor that exposes every layout decision produces a site nobody dares touch, and one that exposes nothing produces a support ticket every time a phone number changes.
Hosting, uptime and certificate monitoring, platform and dependency updates applied and verified, backups with a restore actually tested, and an agreed allowance of content and design changes each month. What it is not is a retainer against a report; if a month goes by with nothing to change, we would rather tell you that than invoice you for a PDF.
Often, and it is the most common way this starts. The first job is access rather than design: registrar, DNS, host, CMS and analytics, in your accounts. Sometimes the honest answer after that is that the existing site is fine and needs a week of repair rather than a rebuild, and the rescue engagement is priced so we can say so.
We will maintain one, and we will use it headless where the client's team already knows it and the editing habit is worth keeping. We do not recommend starting a new site on a plugin stack: most of what makes those sites slow, insecure and expensive to keep is the plugin surface, and the maintenance bill arrives whether or not anybody is looking.
By who has to live in it. This page is about a public site: mostly read, mostly by people who arrive once, where speed, clarity and the path to contacting you decide everything. That page is about software your staff or customers work inside all day (portals, consoles, field apps) where the questions are workflow, permissions and data. Plenty of engagements need both, and they are scoped together when they do.
You are reading one. This site and the three sibling division sites are built on the stack described above, statically prerendered, measured against WCAG 2.2 AA, and published with their sources and their limits stated. It is the reference build for what is on this page.
Sources
- 1.Web Content Accessibility Guidelines (WCAG) 2.2 (opens in a new tab), W3C,
- 2.Web Vitals (opens in a new tab), Google (web.dev),
Next step
Tell us what’s breaking.
Forty-five minutes, no charge, no deck. We’ll tell you what we’d do, what it would likely cost, and whether what you already have can be made to work.