Custom website development for businesses that need enquiries, not applause

What “custom website development” actually means here

It means a site assembled from components we write, on a platform chosen against what the site has to do, rather than a theme bought and bent into shape. The practical difference shows up two years later: a component-built site can be edited, extended and moved; a builder-built one has to be rebuilt.

Price and timeline, published

A focused marketing site runs 2 to 3 weeks from signed scope to launch. A CMS or e-commerce build runs 4 to 12 weeks, and what moves that date is almost always content readiness and third-party integrations rather than design. Starting prices for all three tiers are on the offers and pricing page, in US dollars, so you can rule us out in a minute rather than after two calls.

Performance and accessibility are acceptance criteria, not adjectives

Google publishes the thresholds a page is measured against: Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint of 200 milliseconds or less, and Cumulative Layout Shift of 0.1 or less, at the 75th percentile of real page loads. Accessibility follows WCAG 2.2 at level AA. Both are checked on a mobile profile before handover, because a site that passes on a desktop and fails on a phone has failed.

What we hand over

The Git repository, the domain, hosting, the CMS admin, Search Console and the analytics property, all in your name. Handover includes written documentation and a recorded walkthrough for whoever joins your team next. Ongoing care, core, theme and plugin updates, backups, uptime and Core Web Vitals monitoring, security patching and a monthly note on what changed, is optional and priced separately.

When a website is the wrong purchase

If the site is fine and nobody can find it, the money belongs in digital marketing. If people find it and do not believe it, the money belongs in branding. If the enquiries arrive and nobody answers them quickly enough, the money belongs in a support desk. We would rather route you correctly than sell you the thing we happen to be discussing.

What actually decides a website project

Design gets the blame for most website projects that go badly, and it is almost never design. The three things that decide the outcome are whether the content exists, whether the integrations were scoped, and whether anybody agreed what the site is supposed to make happen. A beautiful site built on unanswered versions of those three will still underperform the plain one that answered them.

So the build starts with the question the site has to settle for a visitor, and the structure follows from that. Everything after it — layout, components, performance budget — is execution, and execution is the part that is reliably deliverable.

Website development, in practice

• Content readiness treated as a project dependency with a date on it
• Integrations scoped before the design, because that is what moves the estimate
• Core Web Vitals measured against the thresholds before launch, not after

See WordPress or Shopify for what we build on, and the Ankora build for what a structured site looks like in practice. Google’s Core Web Vitals reference defines the thresholds.

How this work usually starts

A website engagement starts with the question the site has to settle and the list of content that does not yet exist. Both are uncomfortable and both are cheap, and together they prevent the two things that actually delay builds.

Two dependencies decide the date: content and integrations. Design almost never does, and a project plan that tracks the first two honestly is a plan that holds.