01
A static Astro site on Vercel
Every page is generated at build time. Publishing in the CMS triggers a rebuild, so a visitor never waits on a database — and the site keeps serving even when the CMS is down for maintenance.
Supapress — a website studio
Websites built as code. Edited as content.
We build and run marketing sites for agencies and for the businesses they serve. The pages are static Astro. The content lives in a CMS your team owns. Every design decision is a reviewed line of code — not a setting somebody can knock over on a Tuesday.
- Static by defaultEvery route is built ahead of time and served as a file. A CMS outage cannot take the site down.
- Edited by your teamCopy, images, SEO, forms and menus live in the CMS, with drafts and preview links.
- Shipped through gatesDesign parity, responsive and accessibility checks run before a change is allowed to merge.
What you get
Four things, and they are the whole product.
Not a theme, not a plugin stack. A site, a CMS, and the working habits that keep the two from fighting each other.
02
A page builder with a section catalog
Sections are typed components in code. Editors pick from a catalog of them, order the rows, choose each row’s background and fill the fields. The catalog is generated from the components themselves, so it can never offer a section that does not exist.
03
Translations that stay honest
Every field carries its own translation status, a glossary holds the terms that must be left alone, and a page is served in a language only once the whole page is in it. A half-translated page falls back instead of mixing.
04
Editing with Claude, under your own account
Each CMS ships a connector, so an editor can ask Claude to draft a page, audit SEO or queue a translation — with their permissions and their name in the history. It writes drafts. Publishing stays a person’s click.
Compared with WordPress
The same jobs, arranged differently.
Most teams asking about this are running WordPress today, and it is a reasonable thing to be running. These are the differences that actually show up in the work.
| Concern | A WordPress site | A Supapress site |
|---|---|---|
| Page delivery | PHP and a database render each request. Staying fast means caching layers and hosting tuning. | Pages are built ahead of time and served as files from a CDN. |
| Editing | A theme plus a page-builder plugin. Layout and content are edited in one place and stored together. | Content in the CMS, layout in reviewed code. A content edit cannot change a layout. |
| Updates | Core, theme and plugin updates, and the conflicts between them. | One codebase with tests. Dependency updates land through pull requests. |
| Security surface | The admin and every plugin sit on the public server. | The CMS is a separate application. The public site runs no server-side code for a reader. |
| Outages | A database or plugin failure takes the site down. | A CMS outage cannot take the site down. The last build keeps serving. |
| Design fidelity | Drifts over time as editors adjust builder settings. | Measured against the design frames before each merge. |
| Translations | Plugin-managed, page by page. | Per-field status with a glossary. A language ships only when the page is whole. |
| History and rollback | Revisions per post. Rolling the whole site back depends on hosting backups. | Every change is a commit. Any deploy can be rolled back. |
The trade is real and it runs both ways: a Supapress editor cannot reorder a page or invent a layout on their own. That goes through us, and comes back as a reviewed change.
How a site is built
The design lives in code. The content lives in the CMS.
That line is the whole architecture. A page's layout is never stored in the database, so a content edit cannot break a layout, and a layout fix is never a data migration. What an editor changes is text, images, links and order — inside sections that were designed, reviewed and measured before they shipped.
Every change is checked before it merges: layout parity against the design frames, a responsive pass at desktop and phone widths, focus rings and heading structure, and before-and-after screenshots in the pull request.
- Design — Frames become sections: one component per band, typed props, its own scoped CSS.
- Catalog — Those same components generate the picker your editors see, with a preview shot for each.
- Compose — An editor builds the page from the catalog, as a draft, with a preview link to share.
- Publish — Publishing rebuilds the site. A failed rebuild never loses the save that caused it.
Who it is for
Two kinds of team, one arrangement.
Agencies running client sites
- One codebase, one CMS per client — no shared database to break
- A shared section library, themed per client
- Role-scoped access so each client’s team edits only their own content
- Fewer micro-tickets: copy, images and SEO stop coming back to you
Clinics and small businesses
- Location pages, enquiry forms, a blog and events
- Staff update hours, photos and copy themselves
- Search rankings kept: existing URLs are carried over, not reinvented
- The site stays fast and the design stays intact
Request a walkthrough
Half an hour on a real site.
Tell us what you are running now. We will show you the same things on a site that is live: the CMS, the section picker, a draft, a preview link, and a publish that rebuilds the site while you watch.
No slides, and no obligation to move anything.