Can you work on a site another agency built?

Yes. We start by reading the code and the deployment setup and write down what we found, including what we would not touch yet. Every change after that goes through the same review and rollback path as new work.

Do you design the site as well as build it?

We do structure and interface design: page hierarchy, components, states and layout. If you need a new visual identity, we work from one your brand designer supplies, or we say plainly that this sits outside what we do.

Which content management system or framework will you use?

Whichever your team can maintain after we leave. We recommend a stack once we know who edits content, who maintains code and where it is hosted, and we write down why, so the choice can be questioned later.

What do we receive when a built site or product is handed over?

The running site or product in your hosting, the repository with its full history, the component library and content model with usage notes, and a written deployment guide. Before we sign off, one of your developers makes and ships a small change using only that guide.

Depth 14 · Service line

Web and product engineering

Web and product engineering is the building of the websites and software interfaces a company's customers actually use, along with the connections between them and the systems behind. It covers marketing sites structured for search, product screens built from a shared component library, integrations that move data between tools, and the performance work that keeps pages fast on ordinary phones.

Inside this line

Four sub-services: marketing sites, product interfaces, integrations and performance engineering.

Input: Your current site or product, access to its repository and hosting, any brand and design files, and a person who can make decisions about content and scope.
Method: We agree the page and component structure before any visual design, build in small reviewed changes on a branch your team can see, and test on real devices and slow connections before each release.
Deliverable: Production code in your repository, deployed to your hosting, with the component library, content model and deployment steps documented so another team could take it over.
Measured by: Core Web Vitals from field data, accessibility checks against WCAG 2.2 from the W3C, and integration error rates from logs.

Level 3 · 01

Marketing sites

A marketing site is the public website that explains what a company sells and lets a buyer get in touch. For a company with several services, the hard part is structure: each service needs its own page, its own address and a clear place in a hierarchy, so that both people and search engines can find the right page without reading everything.

Inside it

Service tree modelled as data
Templates per level of the hierarchy
Generated navigation, breadcrumbs and sitemap
Structured data on every template
Editor workflow for copy changes

Measured by Pages indexed in Search Console, valid structured data on every template, and enquiries recorded per page in analytics.

Marketing sites, full page

Deliverable · Level 4→ Multi level service architectureMulti level service architecture: the content model, the page templates for each level and the generated navigation and sitemap.

Level 3 · 02

Product interfaces

Product interfaces are the screens inside a software product: dashboards, forms, settings and every state they can be in, including empty, loading and error. A design system in code is the shared library of components those screens are built from, so a button or a table behaves the same everywhere and a change is made once.

Inside it

Component inventory and consolidation
Design tokens shared by design and code
Empty, loading and error states
Keyboard and screen reader behaviour
Component documentation

Measured by Share of screens built from library components, accessibility checks against WCAG 2.2, and defects reported against interface components.

Product interfaces, full page

Deliverable · Level 4→ Design system in codeDesign system in code: a documented component library in your repository, with design tokens and usage notes.

Level 3 · 03

Integrations

An integration is a connection that moves data between two systems automatically, for example from a website form into a CRM or from a billing tool into accounting. Integrations fail quietly: a changed field or an expired key can stop data flowing for days before anyone notices, so the work includes knowing when they fail.

Inside it

Field mapping between systems
API and webhook connections
Retries and duplicate protection
Transfer logs
Failure alerts and key rotation steps

Measured by Transfers that succeeded, failed or were retried, read from the integration logs, and time from failure to alert.

Integrations, full page

Level 3 · 04

Performance engineering

Performance engineering is the work of making pages load and respond quickly for real visitors on their own devices and networks. Google measures this with Core Web Vitals: how fast the main content appears, how quickly the page reacts to input, and how much the layout jumps while loading. Field data from real users counts for more than a lab test on a fast laptop.

Inside it

Field data review by template
Image, font and script loading
Server response and caching
Input responsiveness
Layout shift fixes

Measured by Core Web Vitals in field data against the "good" thresholds Google publishes on web.dev (industry benchmark: LCP 2.5 seconds or less, INP 200 milliseconds or less, CLS 0.1 or less, at the 75th percentile of page loads).

Performance engineering, full page

Deliverable · Level 4→ Core Web Vitals remediationCore Web Vitals remediation: a list of causes per template, the fixes merged into your code, and a before and after record from field data.

Where this applies

Who this is for: Product and marketing leads with a site or product interface in production that is slow, hard to change or rebuilt by hand for every new page.

Sectors this line is set up for, not a list of clients.

B2B softwareIND 02: Product interfaces and a design system in code that the product team keeps after handover.
Professional servicesIND 03: Multi level service sites generated from one content model, so no page is written twice.
EcommerceIND 05: Storefront performance work measured against Core Web Vitals field data.
LogisticsIND 04: Integrations between carrier, warehouse and order systems with retries and alerts.

Shape of the work

Build pipeline: commit, type check and tests, browser tests with Playwright, preview deployment for review, then production release.

What you get

14.1 · Marketing sitesMulti level service architecture: the content model, the page templates for each level and the generated navigation and sitemap.
14.2 · Product interfacesDesign system in code: a documented component library in your repository, with design tokens and usage notes.
14.3 · IntegrationsRunning integrations with a field mapping document, logs and alerting, plus steps to rotate keys.
14.4 · Performance engineeringCore Web Vitals remediation: a list of causes per template, the fixes merged into your code, and a before and after record from field data.

What we work with

Languages and runtimes: TypeScript · JavaScript · Node · Python · Go · SQL · Bash
Front end: React · TanStack Start · Next.js · Astro · Vite · Tailwind
Back end and APIs: REST · GraphQL · webhooks · background workers · queues
Content systems: Strapi · Sanity · Contentful · WordPress for migrations · Notion as a source
Commerce: Shopify · WooCommerce · headless storefronts
Quality and observability: Playwright · Sentry · uptime monitoring · structured logging · error budgets

These are the tools we work with, not partnerships, certifications or resale agreements.

How this fits the other lines

02Search and AI visibility
A rebuild is the cheapest moment to get crawlability and structured data right.
06Managed services
After handover someone has to release, watch and patch what was built.

When this is not the right line

If you need a brand identity or a campaign concept, hire a design studio: we build interfaces from an agreed design. If a hosted website builder already does what you need, keep it.

Questions about this line

Can you work on a site another agency built?: Yes. We start by reading the code and the deployment setup and write down what we found, including what we would not touch yet. Every change after that goes through the same review and rollback path as new work.
Do you design the site as well as build it?: We do structure and interface design: page hierarchy, components, states and layout. If you need a new visual identity, we work from one your brand designer supplies, or we say plainly that this sits outside what we do.
Which content management system or framework will you use?: Whichever your team can maintain after we leave. We recommend a stack once we know who edits content, who maintains code and where it is hosted, and we write down why, so the choice can be questioned later.
What do we receive when a built site or product is handed over?: The running site or product in your hosting, the repository with its full history, the component library and content model with usage notes, and a written deployment guide. Before we sign off, one of your developers makes and ships a small change using only that guide.

Show us the page your team avoids changing

Send the address of the page or screen your team dreads touching. We reply with what we would measure first.

Send the address

An email exchange first, no call needed.