A website that does something, not just says something.
Sites, portals and web products where a visitor can actually finish the thing they came to do.
Useful when your site describes the business but every real task still happens by phone or email.
Illustrative system example · fictional product and data · not client work
Customer productMERIDIAN · illustrative system, fictional data
You may need this when
Some of this probably sounds familiar.
- Customers ring up to ask things the website should already answer.
- Changing a page means asking a developer, so pages go stale.
- The site looks acceptable on a laptop and awkward on a phone.
- There is no way for a customer to see their own order, booking or documents.
- You are paying for a site that generates no enquiries you can trace.
What we could build
Somewhere your customers can get something done.
From a site your team can actually edit, through to a product people log into.
- Marketing site with a real CMSPages, posts and sections your team changes without a developer.
- Customer portalA signed-in area for orders, documents, history or progress.
- Booking or ordering flowA path that completes without a phone call.
- Web applicationA product that does the job, rather than a brochure about it.
- Accessible, fast front endBuilt to work on a mid-range phone and with a keyboard.
- Measurement that means somethingKnow which pages produce enquiries, not just visits.
See an example
The same product, three different visitors.
Choose who has arrived. A useful site sends each of them somewhere different — the same underlying system, a different purposeful path.
Every option is shown below. The selector needs JavaScript, so it is not offered here.
OutcomeA stranger can judge whether you are right for them without contacting anyone.
OutcomeA customer finishes the task themselves, instead of joining a phone queue.
OutcomeThe same tasks, ordered for a small screen rather than squeezed onto one.
Illustrative interfaces and fictional data. Not client work.
Deciding these journeys before design starts is what stops a site becoming one page that tries to serve everybody.
What you receive
A site you can run, and evidence it works.
- A live site or product, on your own domain and hosting
- A content system your team is trained to use
- Accessibility and performance checked on real devices
- Analytics configured to answer the questions you actually ask
- Agreed source code, data and infrastructure handed over according to the project scope and terms
- Handover documentation and any agreed support arrangements
Technical depth
Front end
Semantic HTML with progressive enhancement, so core content and navigation work before JavaScript does.
Performance
Responsive image ladders in modern formats, deferred non-critical work, and budgets checked against Core Web Vitals.
Accessibility
Keyboard paths, visible focus, colour contrast and screen-reader labelling tested rather than assumed.
Content
A schema shaped around your real content types, so editors fill in fields rather than fight a page builder.
Search
Titles, descriptions, canonical URLs, structured data and a sitemap that reflects the real site.
Hosting
Static or edge-rendered delivery where it suits, with deploy previews and a rollback path.
Often combined with
What usually sits next to this.
- Software & systems →When the portal needs a real system behind it.
- Automation & integrations →When orders or enquiries must reach the tools you already run.
- Data & analytics →When you need to know which parts of the site actually earn their place.
Tell us what your customers are trying to do.
Describe the task they cannot finish today. That is usually the whole brief.