Messaging
What the site actually claims
Who it is for, what it does, and why this rather than the alternative. Written before anything is designed, because design cannot rescue an unclear claim.

Marketing and lead-generation sites built around the buying journey, the content the team has to maintain, and the systems the enquiry has to reach.
Which is fine, until the business needs the site to produce something.
A site that describes the company is not the same as a site that routes a buyer. The second one needs to know who is arriving, what they are deciding, and what has to be true before they will send a message.
That means messaging before design, a page for each real search intent rather than one long homepage, proof placed where the doubt is, and an enquiry that reaches a person with enough context to reply usefully.
It also means the team can change the site afterwards. A site that needs a developer for a copy change stops being maintained within a quarter.
In roughly the order they get skipped.
Swipe the parts
Messaging
Who it is for, what it does, and why this rather than the alternative. Written before anything is designed, because design cannot rescue an unclear claim.
Architecture
Service, sector and decision pages that match how buyers actually search, rather than one homepage carrying every argument at once.
Content model
A CMS where content changes regularly, modelled around the content that exists rather than a generic page builder.
Capture
Forms, routing and CRM integration, with enough context attached that the first reply can be useful.
Marketing sites, redesigns, web applications and ongoing support.
The stack follows the requirement. We do not sell a framework as the proposition.
| The requirement | What we would build | Why |
|---|---|---|
| A compact marketing site, updated occasionally | Astro, content in the repository | Static output, nothing to maintain, and the fastest thing to load |
| A growing site the marketing team edits weekly | Astro with a managed CMS | Editing without a release, with the performance of a static build |
| Personalised or server-rendered behaviour | Next.js | Application behaviour and server logic the static model cannot cover |
| Accounts, workflow or relational data | Next.js with a managed backend | Authentication and data requirements beyond a marketing site |
| Selling products directly | Shopify | Checkout, tax and fulfilment are not worth rebuilding |
Where a CMS or backend is needed we select it against the requirement. Licence and hosting costs are yours and are stated in the scope rather than absorbed silently.
GBP and USD, excluding VAT. Applications are scoped after discovery.
From-price or scoped after discovery
Lead generation
From £4,000From $5,200
A complete marketing and lead-generation website: the messaging, the structure and the enquiry routes a qualified buyer needs to make a decision.
Starting price
Up to 20 pages
From £2,000From $2,600
A compact marketing site or one focused lead-generation system, on a defined page and component scope of up to twenty pages.
Starting price
Software, not a site
From £4,000From $5,200
Authentication, application behaviour, relational data, private merchant tooling or a custom Shopify app. Requirements beyond what a marketing site or a theme can hold.
Starting price · scoped after discovery
Separate from project pricing
Per month
From £399From $525
Monitoring, routine technical care and platform updates, plus small edits to text and images already on the site. New pages and substantial feature development are quoted as project work.
Starting price
Per month
From £1,250From $1,650
A live improvement programme on one site. You set the priorities each month, we work the queue in order, and the month closes with what changed and what it did.
Starting price
Per month
From £3,000From $4,000
Continuous delivery across an agreed portfolio, with planning ahead of the work rather than a queue you have to keep feeding.
Starting price
All prices exclude VAT where applicable. Domains, hosting, CMS licences and third-party services are separate unless explicitly included.
A build ends with a handover either way.
Monthly support is a separate service with an agreed capacity and a prioritised queue. It exists for sites with a genuine backlog, not as a condition of having had something built.
Astro where the site is mostly content and speed matters, Next.js where the site needs application behaviour or server-rendered logic. A managed CMS is added when someone other than a developer has to edit the site. The stack follows the job rather than the other way round.
No. It is a reasonable choice where a team already runs it well and the plugin set is under control. What we will not do is inherit a site whose performance and maintenance problems come from twenty plugins nobody chose deliberately.
That is usually the point. Where content changes regularly we add a CMS and model the content properly, so a page edit does not need a release.
No. Enquiry volume depends on traffic, offer, market and sales follow-up as much as the site. We build the routing, the messaging and the capture, and we are explicit about what the site does not control.
Yes. URL inventory, redirect mapping, metadata carry-over and analytics continuity are part of the build, not an afterthought.
Enquiry quality, enquiry volume, or a team that cannot change the page. Each one points at a different build.