Your marketing site, live in weeks and drivable by AI
We build it new or retrofit what you have. You end up with a site that converts, a design system your AI tools can drive, and a publishing workflow where a human still approves.
This is what a site nobody owns looks like
Not broken. Just quietly wrong in a dozen places, because every fix needs a developer who has better things to do.
The pricing page shows a plan you killed
And the careers page lists a role you filled in March. Nobody decided to leave them; there was just never a moment to fix them.
The changelog stopped four months ago
The product kept shipping. The site stopped saying so, because the entry is a hand-written chore that loses to everything else.
The docs and the site tell two different stories
Two versions of the same claim, drifting apart with every release. Whichever one the prospect reads first, the other undermines it.
The logo wall has a customer who churned
Small things, until a prospect notices one. A site full of stale details reads as a product nobody is sure about.
Two starting points
New build or retrofit. Same destination.
No site, or a site you are embarrassed by. We build from patterns that already work: homepage, feature pages, comparison pages, pricing, blog, changelog. No blank page, no six-week discovery phase to decide what a pricing page should look like.
A site that works but nobody can touch. The one person who knew the deploy left, and every change is a Slack negotiation before it is a change. We keep your design and your content, and change what sits underneath. Components get named and documented, copy rules get written down, funnel events get wired, and publishing moves into a reviewed workflow. Visitors see the same site. Your team stops filing tickets.
Either way you land in the same place: pages your team ships without a developer, and a funnel that is measured from day one. That is the point where the sprint work can start.
How a build runs, week by week
Fixed scope, fixed days, agreed before anything starts. Weeks, not quarters.
We agree the page list and the days
A short discovery pass: what you sell, who buys, which pages exist, what has to be live first. You get a page list, a sequence and a number of days. Nothing starts before you have seen both.
We set up the repo and the design system
Astro project, markdown content, components with names that mean something. Alongside the code go the convention files: how a page is composed, what a section is called, which copy rules apply. This is the part that makes the rest fast.
Pages ship one by one, in review
Every page arrives as a preview link before it arrives on your domain. You comment, we adjust, it merges. The first pages usually go live while the rest are still being built, so nothing waits for a big-bang launch day.
Measurement goes in before you go live
PostHog, HubSpot and Search Console wired up, events named per funnel stage, forms and CTAs tracked, dashboards built. Launch day is also day one of data, which is what the sprint work runs on later.
A retrofit runs the same four steps. Step two takes longer, because we are naming and documenting what already exists instead of writing it fresh.
Three deliverables
What you own when we are done
Not a design file and a handover call. A repo you can run without us.
A website built to convert, not just to exist
Page patterns that earn their place: a homepage that names what you sell, feature pages that lead with the outcome, comparison pages that answer the search someone already typed, pricing that survives procurement. Fast static pages, clean metadata, accessible markup, mobile handled.
A design system an LLM can actually drive
Components with real names, tokens for type and spacing, and the rules written as files in the repo: how pages are composed, which section goes where, what the voice sounds like, what a CTA may say. Your AI tooling reads those files and builds pages that look like your site instead of like a generic template.
A publishing workflow with a human check
Ask for a page, get a branch, a preview link and a checklist: links resolve, metadata present, events fire, nothing broke. Somebody on your team approves, then it publishes. Every change is versioned, and anything can be reverted with one click.
Wired on day one
The plumbing nobody wants to write twice
Every one of these is in the build, not a later ticket. They generate themselves from the content, so they stay right as the site grows.
Sitemap and robots
Generated from the pages that exist, submitted to Search Console. New page, new entry, no reminder needed.
RSS and JSON feeds
Blog and changelog publish feeds automatically, so newsletters and aggregators pick posts up without a manual step.
Redirects that survive renames
Move or rename a page and the old URL keeps working, instead of 404ing quietly since the last redesign. A link check runs before every publish.
Meta and social cards
Titles, descriptions, canonicals and OG images rendered per page from the content. Shared links look deliberate instead of blank.
llms.txt kept current
A machine-readable map of your site for AI answer engines, regenerated on publish rather than written once and forgotten.
Forms into your CRM
Demo, trial and contact forms post straight into HubSpot with source and campaign attached, and fire the matching funnel event in PostHog.
A page is a file, which is why AI can edit it
LLMs read and write files well. They do not click through an admin UI. Put the content in markdown in a git repo and your AI tooling can open a page, change a headline, and open a pull request you review like any other change.
--- layout: compare competitor: Datadog headline: Tracing without the per-host bill funnelStage: acquisition --- ## Where we are different Flat pricing per app, not per host.
That file is the whole page. The layout decides how it looks, the frontmatter decides how it is measured, and the markdown is the part a marketer edits. Thirty comparison pages are thirty files and one layout, not thirty hand-built pages.
It also means every change has an author, a diff and a revert. That is what makes handing the keys to AI tooling safe: nothing goes live that a person did not approve, and nothing is unrecoverable.
What if we already have a site we like?
Then we retrofit it. That question and the rest of the technical ones, answered.
Do we have to throw away our current site?
No. If the design and the content are working, a retrofit keeps both and changes what sits underneath: named components, written conventions, funnel events, a reviewed publishing workflow. Visitors see the same site. Your team stops waiting on developers to change it.
How long does a build actually take?
Weeks, and the number of days is agreed before we start. It is fast because we are not designing a pricing page from scratch for the first time. Pages ship as they are finished, so the important ones are live before the last one is done. What slows a build down is waiting for your content and your approvals, not the code.
Why Astro and not the framework our app uses?
A marketing site is content, not an application. Astro renders it to static HTML, which is fast, cheap to host and hard to break. When there is an app or a POC attached we use Next.js and Supabase for that part. Your product stack does not have to change either way; the marketing site lives in its own repo.
Why not WordPress?
LLMs read and write files. Markdown in a git repo is the format they handle best; a database behind an admin UI with fourteen plugins and a pending update nobody dares click is not. Static pages render fast, every change is versioned and reviewable, and your AI tooling becomes the CMS. If it has to run on WordPress, we are honestly not your agency.
Who owns the code and the accounts?
You do. The repo is in your organisation, hosting and analytics are on your accounts, and the conventions are files you keep. If you stop working with us tomorrow the site keeps running and any developer can pick it up.
Can our AI tools break the site once we have the keys?
Not in one step. Changes arrive as pull requests with a preview link and automated checks: links resolve, metadata is present, events still fire, the build passes. A person on your team approves before anything publishes, and every change reverts with one click.
Do you write our content?
No, and we do not do logos or brand books either. We write the page structure and the copy rules, and we will push hard on headlines that say nothing. The product knowledge and the voice stay with you. We also do not promise conversion numbers; we measure what changes after each sprint.
What happens after the build?
The site is built to run without us, so nothing forces a next step. Most teams keep going: once the funnel is measured, the data shows which stage leaks, and we work one stage per sprint. That is the ongoing side.
One call, no deck
Send us the site, we will tell you build or retrofit
Thirty minutes with the person who would do the work. You get a straight read on which path fits, what would ship first, and a rough scope in days. If we are not the right fit, we will say so on the call.