What "performance-engineered" actually means

Core Web Vitals targets

Google's Core Web Vitals are now significant ranking factors and meaningful UX indicators. We design for:

Hitting these targets requires deliberate architectural choices — not bolt-on optimisation after launch.

Lighthouse score discipline

We design for 90+ across all four Lighthouse categories (Performance, Accessibility, Best Practices, SEO) on mobile and desktop. The discipline this requires — optimised images, careful font loading, minimal JavaScript, accessibility from day one — produces sites that age well rather than degrading.

Real-device testing

Lighthouse runs on Chrome. Real users access sites from iPhone Safari, Samsung Internet, older Android Chrome, and varying network conditions. We test on real devices across the range your audience actually uses — not just Lighthouse simulations.

Stack selection criteria

We don't default to one stack. The right answer depends on:

Marketing sites (content-heavy, low interactivity)

Static site generators (Astro, 11ty, Hugo) compiled to plain HTML/CSS/JS, deployed to CDN-edge networks (Netlify, Cloudflare Pages, Vercel). Reasons: maximum performance, near-zero hosting cost, excellent SEO, minimal security surface, easy maintenance. Most marketing sites should be in this category.

Dynamic applications (authenticated, personalised)

Next.js, SvelteKit, or Remix with appropriate backend (Supabase for managed Postgres, custom serverless functions, or traditional Node.js/Python backends). React-based stacks dominate but Svelte is competitive for performance-critical applications. Selection depends on team capabilities, integration requirements, and complexity.

E-commerce

Shopify for 80% of cases — the time-to-market and operational simplicity beat custom solutions for most businesses. Headless commerce (Shopify backend, custom frontend) when brand experience demands more than standard themes allow. Fully custom e-commerce only when there are specific requirements (unusual transaction flows, complex catalog logic, B2B-specific needs) that off-the-shelf platforms genuinely can't meet.

Specific platforms with reasons

WordPress when the existing ecosystem and team capability justify it. Webflow for visual-first marketing sites where ongoing content edits by non-developers matter more than performance peak. Framer for design-led sites with substantial animation needs. Each has appropriate use cases; we don't have a religious preference.

The development process

Phase 1: Discovery and architecture (week 1)

Understanding business requirements, content scope, integration needs, performance targets, accessibility requirements. Output: technical brief with stack selection and architecture rationale.

Phase 2: Design and user flows (weeks 2–3)

Wireframes, then high-fidelity designs in Figma. Critical user flows mapped explicitly. Design reviews before development begins — changes during design are 10× cheaper than during development.

Phase 3: Development (weeks 4–8)

Component library built first, page assemblies second. Daily commits with continuous deployment to staging. Performance budgets monitored from day one — not 'optimised at the end'.

Phase 4: Quality assurance (weeks 9–10)

Real-device testing, accessibility audit, performance audit, SEO audit, cross-browser testing. Issues triaged and resolved before launch.

Phase 5: Launch and handover (week 11)

Production deployment, DNS migration, monitoring setup, training for content editors (if applicable), handover documentation. Site live; post-launch monitoring for first 30 days to catch any issues.

SEO baked in, not bolted on

Most web development engagements treat SEO as an afterthought. We build it in:

Common questions about modern stacks

"Why not just use a website builder?"

Website builders (Wix, Squarespace) work fine for very small businesses needing online presence with minimal customisation. They become limiting fast for businesses that need: serious performance, custom integrations, brand-specific design execution, multi-language support, or any meaningful interactive functionality. The cost of moving off them later usually exceeds the cost of starting on a proper stack.

"Why not just use WordPress?"

WordPress works for clients with existing teams trained on it, complex content-publishing workflows, or specific plugin dependencies. For most new builds, modern static-first stacks deliver better performance, better security, and lower maintenance cost. We don't refuse WordPress — we just don't default to it.

"What about Webflow?"

Webflow is genuinely good for design-led marketing sites where ongoing visual editing by non-developers matters. It's our default recommendation when the client values that capability and accepts the platform constraints. We've built substantial Webflow sites and they perform well when the project fits the tool.

Hosting, DNS, and post-launch

Setup decisions that affect operating cost and reliability:

Frequently asked questions

What stack do you build with?

Depends on requirements. For static marketing sites: HTML/CSS/JS with build tooling (Astro, 11ty, Vite) deployed to Netlify or Cloudflare. For dynamic applications: Next.js or SvelteKit on Vercel/Netlify with appropriate backend (Supabase, custom Node, serverless functions). For e-commerce: Shopify for most cases, headless commerce when justified. We don't have a religious preference — the stack serves the requirement.

Do you do WordPress?

Rarely, and only when there's a specific reason (existing WordPress ecosystem the client is invested in, specific plugin needs that don't exist elsewhere). Default modern stacks deliver better Core Web Vitals, better security posture, and lower long-term maintenance cost. Most clients who think they need WordPress benefit from being shown the alternatives first.

What about Core Web Vitals and Lighthouse scores?

We design for 90+ Lighthouse scores by default. Mobile and desktop. Performance, accessibility, best practices, SEO. Achieving this is mostly about discipline in architectural choices: image optimisation, font loading strategy, JavaScript bundle management, server response times. Not magic — methodology.

How long does a website project take?

Marketing site (5–15 pages): 4–8 weeks. Marketing site with substantial custom design (custom illustrations, animations, complex interactions): 8–14 weeks. Web application (authenticated, dynamic, multiple user flows): 12–24 weeks depending on complexity. We always provide written timeline with deliverable milestones at engagement start; we'd rather give realistic timelines than win projects by promising what won't ship.

Do you handle hosting and maintenance?

Setup yes, ongoing maintenance through partners. For static sites on Netlify or Cloudflare, ongoing maintenance is minimal (security patches handled by the platform). For dynamic applications, we work with managed-services partners or hand off to the client's existing infrastructure team after deployment.

What about accessibility (WCAG compliance)?

WCAG 2.1 AA is our default standard. Compliance involves: semantic HTML, proper colour contrast, keyboard navigation, screen reader support, alt text discipline, focus management. Accessibility isn't a separate checklist at the end — it's baked into every design and development decision. For clients with formal compliance requirements (government, healthcare, financial services), we coordinate with accessibility audit specialists for formal certification.