Sheet 02 / 06
Service line 01
Design, build, launch
Static first

Corporate websites

A corporate site is the first thing a serious buyer checks. We build yours the way a product company builds its own: designed from a blank page for your brand, compiled to static HTML, served from a global edge, tested at every viewport, and written to be found.

Start a project

or write to us at [email protected]

Rendering

Static HTML, no runtime server

Delivery

Cloudflare's global edge network

Accessibility

WCAG 2.2 AA, verified per page

Languages

As many as you sell in

Tracking

No third-party scripts by default

Hosting

We host and run it, monthly

Deliverables

What a Whitewater site includes

Every engagement ships the same substance. The design and the words change per client; the engineering floor does not move.

A design system built for your brand

If you already have a brand, that is where the design starts. A logo, a palette, brand guidelines, a licensed typeface: we work from what exists and extend it into everything a website needs that a brand book never covers, such as a real type scale, a spacing rhythm, a layout grid, a state for every interactive element and a dark scheme that matches the brand rather than fighting it. If there is no brand system yet, we design one from a blank page.

Either way the result is authored for you and committed as code: no theme, no page builder, no component kit carried over from the last project. That is why two sites we build do not look like each other.

The dark color scheme is designed alongside the light one rather than inverted at the end, so a visitor who keeps their phone in dark mode sees a considered page instead of a washed-out one.

Pages written for the search a buyer actually performs

One page per intent, in the words your market uses. Headings answer questions instead of decorating the layout, and the internal links make the hierarchy obvious to a reader and to a crawler. Thin pages do not rank and do not convert, so every page carries the substance its job demands and then stops.

A contact path that actually delivers

The form is plain HTML that posts to a serverless endpoint on the same domain. It is protected by a Cloudflare Turnstile challenge, a hidden honeypot field and a fill-time check, and it sends from a verified sending domain so the lead reaches an inbox rather than a spam folder.

A visitor whose submission is rejected sees an honest error and an email address, never a thank-you page for a message that was quietly dropped.

Every page in every language you sell in

Each language gets real routes and real copy, with the hreflang cluster, the self-referencing canonical and the right text direction handled per page. This site ships in eight languages as its own proof.

Imagery and typography resolved at build time

Photographs are resized, converted to a modern format and content-hashed during the build, then served from your own domain. Brand fonts are subset to the scripts your locales need and self-hosted, so there is no third-party font request and no layout shift while a face loads.

Hosting, deploys and a test suite that gates them

We host and run the finished site for a monthly fee: the edge platform, the certificates, the sending domain, the deploys and the watching. The site is standard code in a repository with automated checks and a one-command deploy, and the tests are not decoration: accessibility, locale parity, security headers, metadata hygiene and link integrity all run on every change, and a red run blocks the deploy.

Relaunch

Replacing a site you already have

Most corporate sites are not first sites. Yours already ranks for something, already collects links from places you have forgotten about, and already has pages a customer has bookmarked. A relaunch that ignores that can undo years of accumulated traffic in an afternoon, so the migration is designed as part of the build rather than improvised on launch day.

An inventory before anything is designed

We list every URL the current site publishes, taken from its sitemap, its internal links, its server or CDN logs, and its Search Console history where you have it. Every URL then gets a decision: kept at the same address, moved, merged into a stronger page, rewritten, or deliberately retired.

The pages that already earn attention are protected first. If a thin, unloved page is quietly the reason half your enquiries arrive, that shows up in the inventory rather than after it has been deleted.

Content moved with its meaning intact

Copy, images, documents and downloads come across page by page. Where the volume justifies it we script the import, and then still read the result: an automated migration that mangles a table, loses a heading level or drops alternative text costs more to repair than it saved. Where the words still work we keep them, because a relaunch is not a licence to rewrite everything for its own sake.

The work is platform independent. Whether the current site runs on WordPress, a hosted site builder, a bespoke content system nobody maintains any more, or hand-written HTML from a decade ago, the content is treated as content and rebuilt into the new structure on its own terms.

A redirect map, written down and testable

Every address that changes gets a permanent redirect to its closest equivalent page. Never a blanket redirect to the home page, which search engines read as a soft deletion of everything you had. Merged pages point at the page that absorbed them, and a retired page points at the nearest parent that is genuinely useful to the person who followed the old link.

The map is a reviewable file in the repository, so you can read it before the switch instead of trusting that it exists. After cutover we request every old URL and confirm both its status code and its destination, and the redirects stay in place permanently rather than for a season.

What carries over, and what we drop on purpose

Carried over: the domain, the content that still works, imagery you own, your brand system, the address your form mail goes to, the analytics or advertising accounts you actually use, and every URL we can keep without bending the new structure around it.

Dropped on purpose: duplicate pages competing with each other for the same search, pages nobody has opened in a year, embeds and tracking scripts whose reports you no longer read, and plugins whose only job was patching the old platform. Every removal is a line on the inventory with a reason beside it, so nothing disappears by accident and you can veto any of it.

The cutover, and the weeks after it

The new site is live on a preview address long before the switch, so nothing is seen for the first time on launch day. At cutover we move the DNS, leave the old host reachable until the change has propagated everywhere, verify the redirect map, confirm form mail is arriving, submit the new sitemap, and ping the instant-indexing endpoints so engines re-crawl within days instead of whenever they next visit.

Then we watch. Search results move for a few weeks after any relaunch while engines re-crawl and re-evaluate the site: some queries settle higher, some dip before they recover. We track the fundamentals with you, meaning indexed pages, redirect health, Core Web Vitals and the queries that actually matter to the business, and we tell you what we see, including when the honest answer is that nothing needs doing.

What we will not do is promise a number. A careful migration protects what you have already earned and gives better content a fair chance to compete. Anyone who guarantees the outcome of a relaunch is guessing with your traffic.

Engineering

How it is built

The stack is deliberately small. Fewer moving parts means fewer things that break at two in the morning, and a site a different developer can still understand in three years.

Static first

Pages are compiled to HTML before any visitor arrives. There is no application server in the request path and no database query blocking the first paint. Content, navigation and metadata live in the HTML itself, so a crawler and a person on a weak mobile connection get the same page.

Enhancement, not dependency

JavaScript is added where it earns its place, scoped to the one component that needs it. Turn it off and the page still reads, the navigation still works and the form still posts.

Assets handled once

Images, fonts and styles are processed at build time and served with immutable cache headers under a content hash. Repeat visits fetch almost nothing, and a new deploy never serves a stale asset.

Deploys you can reverse

Every change is a commit. Continuous integration builds the site, runs the full test suite and only then publishes to the edge. If something is wrong, the previous version is one revert away.

Fig. 1 The page as a drawing: viewport, heading, primary action, contrast target.

Built to be found

For most companies organic search is the main way a new customer arrives. That makes search a build requirement, not an afterthought bolted on by a separate agency.

Structure first. One page per search intent, with headings that answer the question a searcher typed and internal links that make the hierarchy legible.
Head hygiene on every page. A unique title and meta description, exactly one canonical URL, and social cards that render correctly when someone pastes the link into a chat.
Structured data from the visible content. Organization, service and breadcrumb markup is generated from the same source the page renders, so the data a search engine reads can never drift from what a person sees.
Machine-readable index. A sitemap index covering every locale, a robots file that points at it, and an llms.txt for the crawlers that now summarise sites for people.
Instant indexing. Every production deploy pings the IndexNow endpoint with the changed URLs, so engines that support it learn about a change in minutes rather than on their next crawl.
Core Web Vitals by construction. Static delivery, hashed immutable assets and no third-party scripts are the shortest route to good field data, which is itself a ranking input.
What we will not claim. Nobody can sell you a ranking. We build the technical and editorial foundation that lets strong content compete, we measure it after launch, and we tell you plainly which parts are outside our control.

Accessibility

Usable by everyone, not just most people

Accessibility is a legal exposure, a search signal and a quality signal at the same time. We treat WCAG 2.2 level AA as the floor and verify it mechanically rather than asserting it in a brochure.

Audited per page, per viewport, per scheme. An automated audit runs on every built page at phone, tablet and desktop widths in both light and dark, and any violation fails the build.
Real keyboard support. A skip link as the first stop, a visible focus ring everywhere, and a tab order that follows the page.
Contrast in both schemes. Text and interface colors are checked against their real backgrounds, in dark as strictly as in light.
Motion that asks permission. Anything that moves is disabled for a visitor whose system requests reduced motion, and a static frame is shown instead.
Semantic markup. Landmarks, one heading per level in order, labelled form fields, and descriptive alternative text on every image.
Comfortable targets. Every interactive element clears the 24 pixel minimum, checked by measurement rather than by eye.
Hands on the keyboard too. Automated checks catch a great deal but not everything, so we also work the site by keyboard and read it at small sizes before it ships.

Languages

One site, every language you sell in

A translation widget layered over an English page is invisible to search engines and unpleasant to read. Real multilingual support is a routing and authoring decision, taken at the start.

A route per language. Every page exists at its own URL in every language, so each one can be indexed, linked and shared.
Correct signals. An hreflang cluster with an x-default on every page, plus a canonical that points at the page itself rather than at the English original.
Right to left handled in the layout. The stylesheet uses logical properties throughout, so Arabic mirrors the whole composition instead of patching it.
Written, not machine translated. Copy is authored per language in the brand's voice. Automated output reads like automated output, and buyers notice.
Fonts sized honestly. Faces are subset per script and non-Latin text falls back to a system face rather than shipping megabytes to a phone.
A language switch that needs no JavaScript. Plain links between the same page in each language, with no cookie and no redirect guessing.

Security and mail

Locked down, and the mail arrives

A marketing site is a small attack surface that is worth keeping small, and a contact form is worthless if its mail lands in a spam folder.

A real content security policy. No inline script allowance: each inline script is pinned by hash and everything else is refused, which stops an injected script from executing at all.
Transport and browser headers from day one. Strict transport security, no content sniffing, a referrer policy and framing protection ship with the first deploy.
Layered form defences. A Turnstile challenge for humanity, a honeypot for naive bots, a fill-time check for fast ones, and server-side validation and length caps on every field.
Deliverability checked at deploy. The sending domain is verified as part of publishing, so a form that stopped delivering is caught by us and not by a customer who never heard back.
No trackers by default. Nothing third party loads unless you ask for it, and the only analytics we will fit is cookieless, which also means no consent banner.
Secrets stay out of the repository. Keys live in a secret store and reach the running site as environment bindings, never as a file in git.

Hosting and changes

Who runs it, who writes it, and how it changes

From launch we host and operate the site for a monthly fee: the edge platform, the certificates, the sending domain your form mail travels on, the deploys, and the watching that tells us when something needs attention. The people who designed and built it are the people who keep it running, so a question about a page and a question about its hosting go to the same place and get the same answer.

What that is not: no proprietary page builder, no per-seat licence, and no editor you rent seats in. The site is standard code with its own tests, your domain stays your domain, and your content and your brand are yours. Where your contract includes it, you can take the software and host it yourself, and the way it is built makes that a straightforward move rather than a rescue. It is an option we put in writing when you want it, not the default arrangement.

For most companies the default is the better deal: one team that knows the codebase, one monthly line on the invoice, and no third party in the middle of a problem. If you would rather run it yourself, tell us while the scope is being written rather than after launch.

Who writes the words

We do, unless you would rather. Copywriting is part of the build: we draft the page structure, the headings and the body text from the material you already have and from the way you describe the work yourself, in proposals, in sales email and in conversation.

What you supply is the substance and the sign-off: services, the claims you are willing to stand behind, names, addresses, anything that has to be exact. We will not invent a statistic, a testimonial or a case study to fill a space. If you have a copywriter, or you would rather write it yourself, send the words and we design around them.

Changing content after launch

A content change is an edit to a text file in the repository, followed by the same loop every change goes through: a branch, a preview address to check it on, the full test suite, and a deploy that reverts in one step. Nothing is typed straight into the live site, so a bad edit cannot take a page down.

In practice you send us the change and it goes through that loop, which is the quickest path for the small ones. Where your contract puts your own developers in the codebase, they work exactly the same way, which is what the documented setup and the tests are for. And if your team genuinely needs to publish several times a week without a developer, say so early: that is a different build with an editing layer in it, and we would rather scope that than pretend a static site is a newsroom.

The after-launch loop, step by step Software beyond the website

Start a website project [email protected]

Tell us what the site has to do and who it has to convince. Reach us via the contact form or at [email protected], and you will hear back from someone who builds.