Can you work with our existing WordPress site?

Yes, as clearly separate work. We default to building on our own stack because that is what we can stand behind, but a great many businesses have a WordPress site that mostly works and needs rescuing rather than replacing. We will audit it and tell you honestly whether fixing or replacing is the better spend. Sometimes it is fixing.

Do you host the site?

By default, in the same Kubernetes cluster that runs our own platform — which is why we can be specific about uptime rather than vague. You are not locked in. The site is a repository and a container image; it can be deployed anywhere that runs either, and the handover documentation says how.

Will it work with KamoCRM?

If you want it to. Forms into the CRM, tracking that survives the visit, live chat, booking, a customer portal — all of that is built rather than bolted on, because we wrote both ends. If you are not a KamoCRM customer it makes no difference to the site we build you.

How long does a site take?

A focused marketing site is usually six to ten weeks from the first workshop, and the largest variable is content, not code. A site with an application behind it, or one shipping in several languages, runs longer. We give you a date with the quote and tell you what would move it.

Do you do the writing?

We do, when the alternative is a site that never launches because nobody wrote page four. We would rather work from your material and shape it than invent a voice for your business, so the usual arrangement is that you supply the substance and we do the structure and the words.

A Website Is Software. Ours Is Built Like It.

Most sites are assembled from a theme and a plugin list, then degrade quietly. We design and engineer sites the way we build our own — with an accessibility budget, a performance budget, and a build that fails when someone breaks either.

The reason so many business websites are slow, inaccessible and impossible to change is not that designers are careless. It is that the site was assembled rather than built. A theme, a page builder, eleven plugins and a caching layer to hide what the other thirteen are doing. It looks finished on the day it launches and gets worse every week after.

We treat a website as software with an audience. That means version control, a real build, automated checks that fail rather than warn, and performance and accessibility budgets that the build enforces. This site is the example: its build refuses to complete if a page is missing from the sitemap, if a translation key does not resolve, if a price cannot be verified against the live catalogue, or if an entrance animation is slow enough to read as a stalled page.

Design and engineering are not separate purchases here. A beautiful page that takes four seconds to become interactive on a phone is not a beautiful page — it is a picture of one. The work is making something that is genuinely good-looking and genuinely fast at the same time, on the device your customers actually hold.

What usually happens, and what we do instead.
The usual arrangement	How we work
Builds on a theme and a stack of plugins	Builds on a framework, with every dependency chosen deliberately
Checks the site looks right in a desktop browser	Enforces performance and accessibility budgets in the build itself
Treats accessibility as a compliance overlay widget	Builds to WCAG with real keyboard and screen-reader testing
Hands over a login and a maintenance retainer you cannot leave	Hands over a repository anyone competent can pick up
Rebuilds from scratch every three years	Builds something that can be changed instead of replaced

What you actually get

Design done against real content, not filler — the content is part of the work
A component library, so the site can grow without a redesign
Accessibility to WCAG 2.2 AA, tested with a keyboard and a screen reader, not just a scanner
Core Web Vitals measured on real devices and held to a budget the build enforces
Structured data, canonical rules and sitemaps correct on the day it launches
The repository, the deployment pipeline and documentation — yours