Web development

A marketing site, a customer portal and an internal dashboard are three different problems that get sold as one. A site has to load fast on a phone on a bad connection and be editable by someone in marketing. A portal has to be secure, auditable and survive a password reset at 11pm. A dashboard has to make a decision obvious in four seconds. We build all three, and we build them differently. Aurelia Retail Group’s storefront went from a 4.1-second largest contentful paint to 1.2 seconds, and checkout completion moved 9% in the quarter that followed.

• 01

  Performance is a build gate, not a post-launch project: budgets are set in the first week and the pipeline fails when a change breaks them.

• 02

  Accessible to WCAG 2.2 AA, tested with automated checks in CI and a keyboard-only pass before every release. Public-sector and enterprise procurement both ask, and one of them audits.

• 03

  Content that non-developers can change. Editors get a structured editing surface, not a rich-text box that eventually breaks the layout.

• 04

  Portals and dashboards get role-based access, audit trails and session handling designed in — retrofitting authorisation into a shipped application is where breaches come from.

• 05

  One design system across the estate, so a new page or a new internal tool takes days instead of restarting the argument about buttons.

1. 01

   Surface and audience

   We separate the surfaces — public site, authenticated portal, internal tooling — and agree what each is actually for. They have different performance, security and editing requirements, and conflating them is what produces a slow site and an ugly portal.

2. 02

   Structure and design system

   Information architecture, then components. We design the reusable set once — type scale, spacing, forms, tables, states — so page eleven costs a fraction of page one.

3. 03

   Build and instrument

   Implementation against the agreed components, with performance and accessibility checks wired into the pipeline from the first commit rather than added before launch.

4. 04

   Content load and launch

   Real content, real images, real edge cases — the long product name, the empty state, the customer with no orders. Launch is a rehearsed cutover with DNS, redirects and a rollback path agreed in advance.

• The site or application, deployed, with source and pipeline in your repository.
• A component library and design tokens, documented so the next developer does not reinvent them.
• Redirect map and SEO carry-over plan for anything replacing an existing site.
• Accessibility report against WCAG 2.2 AA, with anything outstanding named rather than omitted.
• Performance budget wired into CI, plus the Lighthouse run at launch as a baseline.
• Editor guide for whoever maintains the content, written for a non-developer.

• 01Can our marketing team edit the site without us?

  Yes, and that is a design constraint rather than a plugin. We model content as structured fields — a case study has a client, a sector, a set of metrics — so an editor fills in a form and cannot accidentally break the layout. Where a headless CMS is warranted we wire one in; where the content changes twice a year, typed files in the repository are cheaper and faster.

• 02Do you do e-commerce, or should we use a hosted platform?

  For a standard catalogue and standard checkout, use a hosted platform — it will be cheaper and better than anything worth building. We build commerce when the pricing rules, the fulfilment logic or the B2B account structure are the actual business, which hosted platforms model badly.

• 03How fast is fast enough?

  We target a largest contentful paint under 2.5 seconds on a mid-range Android over 4G, cumulative layout shift under 0.05, and a Lighthouse performance score above 90 on a production build. Those numbers go in the contract, and the pipeline enforces them.

• UXD

  UI/UX and product design

  Interface and product design for software people use all day — websites, applications, dashboards and mobile.

  /services/ui-ux-product-design
• CSD

  Custom software development

  Business systems built for how your operation actually runs, when the off-the-shelf product would need bending until it breaks.

  /services/custom-software-development
• API

  API and system integration

  Making the systems you already own talk to each other — payments, CRM, ERP, messaging and the third-party APIs in between.

  /services/api-system-integration