A content platform your team runs without us
A CMS is the software your team logs into to publish. We build them so your editors can do their own work, and so the day you want the whole thing in-house, you can take it. Tell us what you are running and what is not working. On request, a technical person joins within one business day and answers your architecture and stack questions directly.
Ask a technical question
Two lines about what you have and what is breaking.
Who is in this decision
Whoever signs for it
You want the end of asking permission to publish, without opening a ticket.
Whoever owns it afterwards
You have watched the growth team lose development time to the product team every quarter.
Price changes, landing pages and careers posts, without opening a ticket. And insurance against picking wrong twice, because the last platform became, in one owner's words, a maintenance nightmare for people without a guy to call. The question underneath both is whether this will still be maintainable when the agency that built it is gone.
Before anything else, the running cost. Nobody in this category will tell you what it is. We opened nine vendor pricing pages and counted how many publish a price covering 10 to 20 editor seats and two environments: the live site plus a staging environment, the private copy where changes are checked before anyone sees them.
Nine vendor pricing pages, opened 29 August 2026
Nine vendor pricing pages, opened 29 August 2026
Nine vendor pricing pages, opened 29 August 2026
What shapes an engagement, and what widens it
Full specification first
Full specification approved before execution
What is inside it
- A written specification, because this shape only works when the scope is settled up front
What widens it The specification is still moving, in which case we will say this shape is wrong.
Dedicated team or sprints
Once confidence and budget are locked
What is inside it
- A named team working in sprints against a backlog you prioritise
- A change note before any new work: time, effort and cost before approval
- Nothing in the build moves on a re-scope you have not accepted
What widens it You add content types, languages or integrations mid-flight, which is entirely normal.
After launch
Ongoing after launch
What is inside it
- Lean mode, a smaller team available without a full sprint commitment
- Security and dependency updates on the platform we built for you
- Neither is a condition of getting your code
What widens it You want us running the releases rather than being on call for them.
Five things move our number. How many content types and page templates you need. Whether existing content and web addresses are being moved, and how many. How many editors log in, and how many environments. Whether you need single sign-on, meaning people log in with the company account they already have, or roles that limit who can publish what. And what happens after launch. Send the shape of it and a technical person will walk those five with you within one business day.
What your editors can and cannot do alone
Headless means the content is kept in one place and the design that displays it is a separate piece of software. Decoupled is the same idea under another name. The content model is the list of shapes your content comes in, an article, a case study, a job post, with the fields each one has. Editing in place means typing on something that looks like the finished page rather than into a form.
| Platform | Content separate from design | Editors reorder existing sections | Developer for new sections | Editing in place |
|---|---|---|---|---|
| WordPressTraditional. Content and design live in one system. | Content separate from designNo | Editors reorder existing sectionsYes | Developer for new sectionsPartial | Editing in placeYes |
| DrupalTraditional, and can also be run headless. | Content separate from designNo | Editors reorder existing sectionsYes | Developer for new sectionsYes | Editing in placeYes |
| SanityHeadless. Content kept separate from the design. | Content separate from designYes | Editors reorder existing sectionsYes | Developer for new sectionsYes | Editing in placePartial |
| StoryblokHeadless. Editors compose from blocks that exist. | Content separate from designYes | Editors reorder existing sectionsYes | Developer for new sectionsYes | Editing in placePartial |
| ContentfulNot confirmable from the vendor documentation on 29 August 2026. | Content separate from designYes | Editors reorder existing sectionsYes | Developer for new sectionsYes | Editing in placeNot published |
| StrapiHeadless, self-hosted or hosted. | Content separate from designYes | Editors reorder existing sectionsYes | Developer for new sectionsYes | Editing in placePartial |
| DirectusHeadless, sits on your own database. | Content separate from designYes | Editors reorder existing sectionsYes | Developer for new sectionsYes | Editing in placePartial |
Whether to buy this at all
Answer these six about yourself. Four or more yes, and this is worth your time.
Does the same content need to appear in more than one place: a website, an app, a partner portal, a screen in a shop?
Do your editors wait on a developer to publish routine changes?
Do you have someone in-house, or budget to hire, who can run a release?
Will this content outlive the current design? A rebrand in three years makes that matter.
Do you need more than one language or region served from the same content?
Can you name the person who will own the content model after launch?
Five situations where a traditional CMS is right and we are not
Just one brochure site, no second language, a single team, and nothing on the roadmap that changes that, where WordPress or Drupal will cost less to run.
Nobody in-house can run a release and you do not want an ongoing contract with anyone, so headless hands you a dependency you did not want.
Your editors need to drag things around the live page themselves and nothing outranks that, which traditional systems do rather better.
The budget covers the build and nothing after it, and every option here carries a running cost of its own.
You are choosing between a CMS and a custom application, which is a different question altogether and needs a different starting point.
What you keep when we stop
The platform vendor decides how long you have.
The terms are the vendor's, not ours. Open the clauses yourself; they are published on their own sites.
What we commit to
We name which applies to the platform we recommend, with the section number, in the proposal. For Contentful we could not confirm an equivalent clause on that date, so we record it as unknown, not as a no.
The code turns out to belong to the agency.
This is in our standard terms, not an upgrade. It is the clause worth checking with every agency you talk to, ours included.
What we commit to
Every line of code is your intellectual property from Day 1. Not on final payment, not on handover. You own it whether or not you carry on working with us after the build.
The hosting, the repository and the accounts sit in the agency's name.
Not everyone arrives with infrastructure. The ones who do already know where they want it to live.
What we commit to
If you have your own Git hosting, cloud accounts and storage, we work inside them. If you do not, we provision them, set them up, and hand the keys over. Either way the accounts end up in your name.
The knowledge leaves with the team.
CI/CD is the automated pipeline that tests and publishes a change. Documentation is what decides whether your own team can pick this up.
What we commit to
Documentation from Day 1, kept current through delivery: architecture, deployment, CI/CD pipelines, business and software requirements, and every change note. It is written as the build happens, not assembled at the end.
Leaving turns into a negotiation.
The longest active partnership here runs more than a decade. Nothing about keeping what we build depends on staying with us.
What we commit to
A written handover runbook, and a handoff planned at intake, whether that is to your own in-house team or us staying on. The handoff is a process, not a hostage situation. So far, no client has needed to use it.
Sanity's terms of service, section 4.4, as published on 29 August 2026, give you thirty days after termination to retrieve your data. Storyblok's terms, as published on 29 August 2026, run differently: sections 12.4 and 3.10 say rights to use the service cease immediately on termination and make backups the customer's responsibility, while section 12.5 says Storyblok will use commercially reasonable efforts to store customer content for up to 90 days to allow for a potential renewal, and disclaims liability for data loss after termination. A window held open so you can restart a subscription is not a commitment to hand you an export.
Ask for these in writing before you sign anything, with us or anyone else. On request, a technical person joins within one business day and will go through your draft with you.
Open the clauses yourself: Sanity's terms of service, Storyblok's terms of service, Contentful's export tool and its documented defaults, WordPress's own export documentation.
Show data table
| Item | share passing all three Core Web Vitals |
|---|---|
| Squarespace | 60% |
| Wix | 57% |
| Drupal | 56% |
| Joomla | 45% |
| WordPress | 40% |
Across all origins the figure is 51 percent, so this whole spread sits within about ten points either side of the web average. The platform is not what makes a site fast; what is on the page and how it is built are. We are not going to tell you headless is faster, and you should push back on anyone who does. One number we left out: W3Techs reports WordPress running about 43 percent of the web. It is a market-share count that says nothing about whether a build will work, and the methodology page behind it returns a 404.
Sources: HTTP Archive Web Almanac 2024, the CMS chapter, W3Techs' own WordPress usage page.
Show data table
| Segment | Value (advisories) | Share | Source |
|---|---|---|---|
| Add-on modules written by third parties | 1827 | 91.6% | drupal.org |
| The core system itself | 167 | 8.4% | drupal.org |
Roughly nine in ten sit in code added to the system rather than the system itself. Exposure is a build-time decision: every plugin installed to save a week is code you now depend on and do not control. Two things we will not claim from this. The equivalent WordPress split is not verifiable at source, so we are not printing one. And nothing we found supports headless being safer. It has fewer add-ons available, which is not the same thing.
Sources: Drupal core security advisories, Drupal contributed-project security advisories.
Moving without losing the traffic
Replatforming means moving a site from one system to another. What happens to your search traffic is decided by what happens to your web addresses, and the sequence is documented by Google.
- The redirect map
A redirect map pairs every old web address with the new one. It is the largest piece of work in a move, and a precondition Google documents.
- Preconditions
Google lists them before a move with changing addresses, along with five ways it is documented to fail, and the list is public.
- The move
Google's own wording is to expect temporary fluctuation in site ranking during the move. That is the documentation, not a caveat we added.
- Index swap
For a medium-sized site Google says it can take a few weeks or more. That is not a recovery time and we will not present it as one.
- Recovery time
Agencies quote three to six months to recover, with no neutral published figure behind it. If you are quoted a recovery time, ask what it is measured from.
- Check it now
atyantik.com runs on WordPress today and we are migrating off it, so load the domain and see the cost we are describing ourselves.
The questions you already have
how much will this cost me every month after you finish
can my team update the site without calling a developer
what happens if you disappear or go out of business
why not just use wordpress
will my google rankings survive the move
do i own it or do i have to keep paying you
One business day
Send two or three lines: what you are publishing on now, how many people log in, and what is not working. On request, a technical person joins within one business day and answers your architecture and stack questions directly. Not a salesperson.
Two outcomes are good here. Either there is a build worth scoping, and you get the five levers priced against your project. Or we tell you a traditional CMS is the right answer instead.
- A technical person on the call, on request, within one business day
- Your code is your intellectual property from Day 1
- What we build is yours to keep, with or without us