
Requirements and prototype
Map the important journey and review the proposed design or workflow before building it.
A defined brief and a prototype for the important journeys.
When a standard website does not fit the brief, start with the requirements. We plan a custom design and build around your content, customer journey and operational needs.
Designed for businesses across the UK. Scope, ownership and next steps agreed before the build.



Bespoke and custom describe the approach, rather than another set of fixed features. A distinctive editorial layout, unusual enquiry flow or integration may justify focused development. We first check whether an existing platform or a simpler change can meet the requirement, then define the work that needs building.
Custom where it makes a difference.

Map the important journey and review the proposed design or workflow before building it.
A defined brief and a prototype for the important journeys.

Specify integrations, data flows, user roles and edge cases relevant to the brief.
Custom development where the requirement calls for it.

Check the agreed journeys and explain source access, deployment and support responsibilities.
Review points, documented responsibilities and handover.

Bespoke website design makes sense when the brief needs a particular customer journey, content structure or connected workflow. We identify the important jobs first, then decide which parts need custom development and which can use proven existing tools. A custom project does not need every component reinvented.
The early work defines users, pages, permissions, data and integrations. A prototype can make a complicated journey easier to review before the full build. We use that review to settle the useful first release and identify later phases, rather than presenting a long feature list as one undifferentiated project.

The scope covers more than what appears on screen. We agree source-code access, hosting responsibilities, third-party dependencies, documentation and the way the business will maintain content. If the website handles private account data, the access rules and operational requirements need explicit attention.
A booking system, CRM or customer portal may sit within a bespoke website, but each has different users and decisions. Their dedicated pages explain those distinctions. We quote against the actual requirement and identify infrastructure, licences and optional support separately from the design and development work.
Booking, CRM, customer portals and memberships have separate service pages because their users and requirements differ. A bespoke website can connect these functions, but naming them does not make them automatic inclusions. We agree what is built, what uses an existing service and what remains outside the project.
Explore systems & automationA useful brief makes the quote clearer. Share what you have, what customers need to do and who will manage the website or system after launch.
Bespoke work is quoted against agreed requirements. Third-party licences, infrastructure, messaging and maintenance are identified separately so the running cost is understood.
Practical answers before you decide on the next step.
They describe closely related needs, so we cover them on one page. We use the brief to decide the amount of custom design and development.
No. Well-supported existing tools may be the right choice. We explain what is custom, what is integrated and the ownership or licence implications.
We can scope system modernisation separately, including dependencies and migration. A website redesign alone does not include replacing an internal application.
We can assess documented integrations and APIs, account permissions and the data involved. Connection work depends on the provider's capabilities and terms, rather than being assumed to work with every tool.
Yes. We can divide the requirements into a useful first release and later phases. Each phase needs a defined scope, acceptance criteria and separate quote where applicable.
Our website packages include website and source-code ownership. The written agreement confirms repositories, hosting access, third-party licences, documentation and any ongoing support responsibilities.
Share the requirement and your current setup. We can then agree the useful first version, the scope and the next step.