Build it your way. Hand it over with Orbit.
You already know WordPress, and so do your clients. Here's why a Markdown-powered site plus Orbit is the better thing to hand over — and when it isn't.
The handover problem
The reason most client sites end up on WordPress isn't the build — it's the handover. The client needs to change their own words, and WordPress gives them a place to do it. It also gives them a page builder, a plugin directory and an admin account, and six months later the site you built looks like a site you didn't.
Orbit is the handover for sites whose content lives in files. Your editors get a friendly app; you keep the build, the design and the workflow.
It's about how the site is built
Orbit doesn't care which tool turns your content into pages — it cares where the content is. A site is Orbitable when:
- The words live in Markdown or MDX files, with their fields (title, date, price, image) in frontmatter, plus JSON or YAML for data like navigation and team lists;
- those files are in a git repository; and
- the design lives in templates and components, which read that content.
That's a set-up, not a framework. Astro, Hugo, Eleventy, Jekyll, Gatsby and Next.js sites can all be built this way — you could even write a WordPress theme that reads Markdown files. Build it like that, and the content is editable.
An Astro site needs nothing more: Orbit reads its content schema, so the form's fields match exactly what your build expects. Any other generator gets a shortcontent map in orbit.config.yaml — where the content lives, which template renders it, and (if you like) its fields. Orbit works with Astro, Gatsby, Next.js and Nuxt today; is being tested; Hugo, Eleventy and Jekyll should work but haven't been tested yet. One app, and one licence, covers them all.
Editors add content, not layouts
Editors aren't limited to changing what's there. In any section you allow, they add new entries themselves — blog posts, products, case studies, events, team members — each one a new Markdown file, filled in through the same form, that your templates turn into a page.
What they don't do is invent new kinds of page. A new layout is a template, and templates are yours. You decide which sections take new entries and which are fixed pages, like the home page, that can be edited but not duplicated.
What your client gets
- A desktop app with a form for every page. Text, dates, dropdowns, images, lists — built from your schema. No YAML, no Markdown syntax to learn.
- The words and the data, not the design. Editors change and add content. Layout, components and styling stay in code, where only you go.
- Publishing they can understand. Every page shows whether it's live. Saving sends changes to a preview site; editors ask to publish, approvers publish. Who can publish is set by the git host, not by a setting they can untick.
- History and undo. Every save is a real commit. They can restore an old version of a page themselves; you can see exactly what changed.
What you get
- No CMS to host. No database, no admin login, no hosted CMS account. Orbit edits files in the repo you already have, and your normal build and deploy takes it from there.
- No maintenance retainer you didn't want. Nothing to patch or keep alive for the editing side.
- Your workflow, untouched. Branches, pull requests, CI — Orbit commits like a polite colleague. Clean diffs, one change at a time.
- A clear line around your work. The design is yours. If a client wants a new layout, that's a job — not something they quietly broke.
A Markdown site + Orbit, next to WordPress
In general terms — every site is set up differently.
| Markdown site + Orbit | WordPress | |
|---|---|---|
| What runs in production | Static files (or your framework's server) | PHP + a database |
| Plugin and core updates to keep up with | None for editing | Ongoing |
| Can editors add pages? | Yes — in the sections you allow | Yes |
| Can editors break the layout? | No — words and data only | Often, with page builders |
| Where content lives | Markdown files in your git repo | The database |
| History and rollback | Every change is a commit | Revisions, plus backups |
Make your site Orbitable
Most sites are nearly there. An Astro site's content collections are edited as they are; on Gatsby, Next.js or Nuxt, a few lines of content map say where the Markdown lives and which template renders it. Words written straight into components need moving into a content file first — the design stays in code, the words become a form. Orbit's What Orbit edits screen shows what's covered and what isn't.
Or let your AI assistant do the legwork: ask Claude, ChatGPT, Gemini or Cursor to"read orbitmarkdown.com/llms.txt and make my site Orbitable", then review the changes like any pull request.
Content map ·Where to put content (Astro) ·Set up with AI
Working with clients
- A client editing their own site needs nothing. Orbit is free for one site, fully featured.
- You need Pro or Team to look after many sites. Pro is a one-time £29 for one person; Team packs cover a studio.
- Starting points. Pro and Team include Orbit Extras — ready-made sites already set up for Orbit, from a blog to a business site.
When WordPress is still the right call
Be honest with your client and yourself. A product catalogue is just content, but a full online shop — stock, orders, customer accounts — or a membership site or forum needs software behind it, and WordPress (or a platform built for that) may well be the better fit. If editors need to design new layouts themselves, Orbit won't let them — on purpose. Orbit is for sites where you build the design and the client runs the content.
Also worth knowing: Orbit is a macOS app today (Windows and Linux are coming), and it uses git on the editor's computer, so each editor needs access to the site's repository.
Got a client who isn't sure? Send themOrbit for site owners — the same story without the jargon.