Your editors publish, your agent builds, and the whole thing stays yours.
Somewhere in your organisation there is a blog that used to publish weekly. Then the only person who knew how to post left, or every article became a ticket to the agency, or nobody dared log into the admin in case something needed updating first. The content is still there. The publishing pipeline is not.
This package exists for teams that publish: several editors, articles and news on a schedule, pages that change because the organisation does. We build it as a headless CMS website on PayloadCMS — open-source software, no licence fee — and hand it over the DevPowers way: code, pipeline, agent skills and live training. Your editors get a clean admin panel built for non-technical people. You get a site you own outright — code, repository and pipeline. And when a change goes beyond content, you describe it in plain language and let the safety gates check it.
A CMS earns its keep when content is a habit, not an event. The test is simple: if several people publish — articles, news, announcements — and they need to do it without a developer in the loop, a CMS is the right tool. If your content changes a few times a year, it is the wrong one. A static site has fewer moving parts, less to maintain and a lower running cost, and we will tell you so during discovery rather than sell you machinery you will not use.
What structured publishing means here: your blog posts, news items, team members and similar repeating content are defined once as collections with clean fields, then filled in by your editors in a visual admin panel. Adding an editor means creating an account — not buying a seat.
Publishing a few times a year, or mostly fixed pages? The static website packages are the better fit, and they cost less to run.
Three honest positions, not a battle. Every one of these tools can produce a website; they differ in what each one obliges you to do afterwards.
WordPress can run almost anything, and after two decades of plugins that is both the strength and the bill. A WordPress site is a standing maintenance commitment: the core updates, the plugins update, the combinations need checking, and somebody has to own that chore forever. Too often the somebody becomes an agency invoice — the exact dependency this studio exists to remove.
Good tools, one structural condition: the site lives on their platform, on a subscription. You rent the result, and leaving later means rebuilding somewhere else rather than moving. That is the opposite of what we sell.
PayloadCMS is open-source software with no licence fee, built on a modern TypeScript stack, self-hostable, and edited through a clean visual admin panel. Because it is headless, it does half the job — the content half — while your site stays clean, owned code that renders it. The running cost is hosting, and that number is stated in your scope before you commit.
If your current WordPress site works and nobody dreads opening it, keep it — we will say so. If it has become a job, a clean rebuild on an open-source stack you own is what we will quote.
Every editor gets their own account and works in structured fields — title, body, image, tags — inside layout blocks that were designed once, up front, with you. No editor ever meets a stylesheet, a script or a database: those do not live in the CMS, so the admin panel cannot reach them. Writing happens in drafts, preview shows the piece on the real site, and publishing is one click for the people you give it to.
The ordinary Monday: three editors arrive with three pieces ready. Nobody opens a ticket, nobody waits for a developer, nobody asks permission. They log in, write, preview, publish — and go back to their real jobs. The site stays full, and it stays your team's.
Every CMS draws a line at content. Headlines, articles, images, team entries — editor territory, free and unlimited after handover. But a new article layout, a redesigned blog index, a landing page for the autumn campaign? On an ordinary CMS that is where the ticket and the invoice start. On a DevPowers build, it is where you type.
Describe the change to your AI agent in plain language — "give every article page a table of contents" — and the agent builds it on a branch. Nothing reaches your visitors until it has passed the automated end-to-end tests, the quality and accessibility checks and the AI review. A change that fails stays out; rollback to the previous deployment is always available. The CMS protects the content. The pipeline protects everything else.
The automated CI/CD safety gates are documented in full on the how we work page.
Publishing is also a trigger. New article out means newsletter, social post, subscriber notification — the parts after Publish can run themselves: connect n8n automations to your new content and stop being a courier between your own apps.
You can do it yourself - or hand it to us. Both stay open, permanently.
When a change is bigger than a prompt, or the hour is better spent on your own work, hand it to us by email or chat, the same way you reached us during the build. The work is bought as change credits: you receive an estimate in credits before anything starts, and you accept or decline it. Failures caused by DevPowers are repaired free of charge and consume no credits.
Every change is estimated in credits, and you accept or decline the estimate before work starts. Credit pack prices are being set with the first clients and published once they are measured, not guessed.
Everything in the standard DevPowers handover — mobile-first accessible design, technical SEO and structured data, cookieless analytics, the repository, the pipeline, agent skills, playbook and live training — ships with this package too. The full shared list is on the static website packages page. What this package adds:
The CMS software itself carries no licence fee — PayloadCMS is open-source. What costs money is hosting a site with a database: CMS projects are hosted on our standard infrastructure and carry a small monthly fee, stated in the scope. Terms are renegotiated after 12 months. Your own AI subscription, if you use one, is paid to its provider directly. You will always know the number before you commit.
And the exit, stated plainly: you own the source code, and you can take it elsewhere at any time — to another provider, or to your own server. No proprietary platform, no licence fee, no lock-in.
If several people publish regularly and need to do it without a developer, a CMS is the right tool. If your content changes a few times a year, a static site is the more honest answer: fewer moving parts, less to maintain, lower running cost. The decision is made with you during discovery and written into the scope. The static route is covered by the static website packages.
PayloadCMS is open-source software with no licence fee, self-hostable, on a modern TypeScript stack, with a clean visual editor for non-technical staff. WordPress makes you the owner of a standing maintenance workload — core, plugins, combinations. Hosted builders keep your site on their platform on a subscription, and leaving means rebuilding. With PayloadCMS the code is yours, and taking it elsewhere is a move, not a rebuild.
Not from the admin panel. Editors fill structured fields inside layout blocks designed once, up front. Stylesheets, scripts and the application itself do not live in the CMS, so the admin panel cannot reach them. A wrong heading is a wrong heading — someone fixes it and publishes again. Code changes take a different, gated path; see the next answer.
Yes — that is the point of a DevPowers build. You describe the change in plain language, your agent builds it on a branch, and nothing reaches your visitors until the automated end-to-end tests, quality and accessibility checks and AI review have passed. Major framework upgrades, database schema changes and anything touching hosting, DNS or secrets trigger a stop-and-warn first. The full behaviour is on the how we work page.
CMS projects carry a small monthly fee on our standard infrastructure, stated in the scope; terms are renegotiated after 12 months. The CMS software itself carries no licence fee. Your AI subscription, if you use one, is paid directly to its provider. You will always know the number before you commit.
Infrastructure, CI/CD configuration, DNS and secrets are managed by DevPowers and are not client-modifiable; routine publishing never touches them. A major framework or dependency upgrade is a core-risk change: your agent stops and warns in plain language before proceeding, DevPowers cannot guarantee the site afterwards, and repair may be chargeable. Larger work is bought as change credits or quoted as a project.
Yes. Each editor has their own account and their own drafts; publishing is a click for the people you give it to. You decide who holds which account — adding an editor means creating an account, not buying a seat.
The first working draft is on a preview URL within 5 working days after the deposit and your content or written content plan are received. If the first draft does not fit the agreed brief, the deposit is refunded in full and the engagement ends. This applies only to the first draft and is our only guarantee. Payment has three stages: deposit before work, payment on first-draft acceptance, and final payment on handover.
Then you leave, with everything. You own the source code, the CMS it is built on is open-source, and your domain registration stays yours. The site can move to another provider or to your own server. No proprietary platform, no licence fee.
No. Doing it yourself is the default after handover - it is not a duty. Any change you would rather not make yourself, from a small edit to a new feature, you can hand to DevPowers by email or chat: the option stays open, it is simply not the default. The work is bought as change credits, and you receive an estimate in credits before any work starts; you accept or decline it. Failures caused by DevPowers are repaired free of charge and consume no credits.
A change credit is a unit of paid work you buy in advance and spend whenever DevPowers does work on your site. You buy a credit pack; packs cost less as a short subscription than bought one-off. Each change consumes credits by its complexity, not by the time it takes. Credits carry an expiry date and unused credits expire after two months. Credits cover new work and repairs of damage you caused yourself. Failures caused by DevPowers are repaired free of charge and consume no credits. Credit pack prices are being set with the first clients and published once they are measured.
A change that fails the automated gates cannot reach your live site, and rollback to the previous deployment is always available - most accidents stop before they happen. If you override a stop-and-warn and the site is damaged, DevPowers repairs it and the repair is paid in credits: you receive an estimate first and accept or decline it. Failures caused by DevPowers are repaired free of charge and consume no credits.
Then we do it. Doing it yourself is the default because it is cheaper and faster for you, not because we stop working with you at handover. Send the change by email or chat, you receive an estimate in credits, and you accept or decline before anything starts. Nothing about the handover closes that door.
Tell us what your team needs to publish — pages, articles, news, how many editors, how often. We acknowledge your email instantly and a human replies within one business hour — no call, form or booking calendar. The fixed quote follows as soon as discovery is complete.
Get your quote in writing