Web design & build.

What we build#

Static-first marketing sites that ship server-rendered HTML on first byte, score above 95 on Lighthouse mobile across the board, render correctly when a screen reader or an AI crawler parses them, and stay maintainable by a team of one. We build in Astro. We’ve considered the alternatives. This is the one we ship.

Why static-first#

AI crawlers — GPTBot, ClaudeBot, PerplexityBot, OAI-SearchBot, Google-Extended — parse the DOM and the accessibility tree the way a screen reader does. Client-side React applications without server-rendering produce an empty <div id="root"> to a crawler that doesn’t execute JavaScript, or a partial render to one that does it slowly. Static HTML on first byte produces a parseable page every time. The playbook (Part 7) treats this as non-optional for the AI surface; we treat it as non-optional for everything else too.

The same architecture compounds: Core Web Vitals get easier (less JS to download, parse, and execute), accessibility gets easier (semantic HTML, no JS-only event handlers), and the schema graph gets easier (server-rendered JSON-LD in the head, on every page, by default).

What every site we ship has on day one#

• Server-rendered HTML on every route — no client-side gating of critical content.
• JSON-LD schema for Organization, WebSite, BreadcrumbList, and the relevant per-page types (Article, Service, FAQPage, Person) — emitted from typed templates so they cannot be forgotten.
• robots.txt with the explicit AI-crawler allowlist (GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-SearchBot, Anthropic-SearchBot, PerplexityBot, Perplexity-User, Google-Extended, Applebot-Extended, Bingbot).
• sitemap.xml auto-generated at build time, rss.xml for the research/blog feed, llms.txt listing canonical pages.
• WCAG 2.2 AA compliance audited with axe DevTools — alt text, heading hierarchy, semantic HTML, keyboard navigability, focus indicators, accessible forms.
• Lighthouse mobile baseline: Performance ≥ 95, SEO = 100, Accessibility ≥ 95, Best Practices ≥ 95.
• A markdown content pipeline — articles, services, and team bios as .md files with zod-validated frontmatter so no page ships missing its meta description, author, or dateModified.

What we don’t ship#

We don’t ship: hero shaders, parallax-on-scroll, cursor-tracked spotlights, 3D flip cards, JavaScript-only forms, image carousels, popup newsletter modals, cookie banners that can’t be dismissed in one click, or autoplay video on landing pages. Each of these has been linked to a measurable regression in one or more of: Core Web Vitals, accessibility compliance, AI-crawler parseability, conversion rate, or — in the case of cookie modals — the regulatory profile of the business itself.

How we work with what’s already there#

Most engagements start with a site that already exists. We don’t reflexively recommend a rebuild. We audit the existing platform against the criteria above, identify the specific pieces blocking the work (typically: client-side-only rendering, missing schema, no AI-crawler allowlist, accessibility regressions, dead pages still indexed), and ship a remediation plan that costs less than a rebuild. We rebuild only when the existing platform is structurally blocking the work the business needs to do.

Frequently asked questions#

Why Astro instead of Next.js or WordPress?

Astro ships zero JavaScript by default — the page is HTML on first byte, and interactive islands are opt-in. Next.js ships a runtime by default; for a marketing site that doesn’t need one, that’s a tax on every page load and a complication of every CWV optimization. WordPress is a content management system more than it is a website framework, and for sites where the editorial team is two people who can write markdown, it’s heavier than the use case warrants. There are real cases for both — Astro is the right default for the sites we build.

Will I be able to edit the site myself?

If “editing” means writing or updating an article in markdown and pushing a commit, yes — trivially. If “editing” means a WYSIWYG editor with previews and a publish button, the answer is: not without adding a CMS layer (Decap, Sanity, or Notion sync), which we’ll do if the editorial workflow needs it. We don’t add it by default because most clients turn out to have one or two editors comfortable in markdown.

Do you do design?

Yes. We design the site at the same time as we build it. We do not subcontract design to a separate agency, do not produce 60-page Figma decks before code, and do not ship a “phase one” wireframe-only build. The output is the site.

Can you host it?

The site is static. It hosts on Vercel, Netlify, Cloudflare Pages, or any object storage with a CDN in front of it. We default to Vercel for the dev/preview workflow and the serverless functions for any form handlers; we’ll deploy wherever the business prefers.