Decap CMS or Webamend, a form or an agent
Decap is the free, open source, Git-based CMS most static-site builders reach for first. Here is where each one is the right choice, and why the answer is often both.
Amit Malul Lev
Software engineer
Decap CMS is where most people building static sites start when a client asks to edit something, and for good reason. It is free, MIT licensed, and it was Netlify CMS before the rename, so it has been around long enough to have every rough edge documented. If you have not tried it, try it before you try Webamend. This post is about what happens after.
What Decap is
Decap is a React app you add to your site as two files, an index.html under /admin and a config.yml next to it. The config tells it where your content lives and what shape it has: a backend (GitHub, GitLab, Bitbucket, Gitea and a few others), a media folder, and collections. A collection is a folder of Markdown files or a fixed set of files, and each one has fields, and each field has a widget. A blog is a folder collection with a string for the title, a markdown widget for the body and an image for the cover. Your client signs in through GitHub or Netlify Identity and sees a form built from those fields.
Turn on the editorial workflow and it gets closer to Webamend than you might expect. A draft commits to a branch named cms/collection/slug and opens a pull request. Edits push to that branch. Publish merges it and deletes the branch. With deploy preview links on, the client can see the built site before they press publish. That is a real review loop, and Decap had it years before anyone put an agent in one.
What the form cannot do
A form changes what it was built to change. That sentence is the whole comparison.
If the client's site is a blog, a catalogue, a docs site, anything where the same shape repeats and the content lives in front matter and Markdown, Decap is the better tool and it is not close. The edit is deterministic. It costs nothing per save. The client cannot break the layout because the layout is not in the form. You should use it.
The requests that do not fit are the ones every builder recognises. Make the hero bigger. Put the testimonials above the pricing. Add a photo where there was none. Change the green. Those live in templates and stylesheets, not in a collection, and Decap has no widget for them. Each one is a change request that comes back to you, which is the thing you were trying to stop. And the hand-written HTML site, the one with prose in the markup and no front matter at all, cannot be driven by Decap without first being rebuilt into the shape Decap understands. That rebuild is a week, and it is a new invoice.
What Webamend does instead
Webamend puts a coding agent where the form was. The client types the request in words. The agent edits a copy of the files, whatever files, in whatever framework or none, and a gate checks the change against a policy file you wrote once: which paths may be touched, and how many files and lines a single change may reach. What passes becomes a pull request. Netlify builds a preview. The client looks and presses publish, and undo reverts the merge.
So the pull request and the preview are the same idea in both tools. The difference is what sits in front of them. Decap gives the client the fields you defined. Webamend gives the client anything the files can express and the policy allows, and asks you to define nothing but the fences.
That comes with costs Decap does not have, and they should be said plainly. An agent is not deterministic. It will sometimes change the wrong line or too much, and the client will see that on the preview and ask again. Each change burns a few tokens on your OpenRouter key, fractions of a cent for a wording tweak and a few cents for a new section. Setup is by hand, a day per site. And the hosted plans cost money, $4 a website a month for the first five, where Decap costs nothing.
Use both
There is no rule that a repository gets one editor. Decap for the blog, where the shape repeats and a form is exactly right. Webamend for the rest of the site, where the next request will be something nobody put in a config. Both produce pull requests against the same repository, both leave the history as the audit trail, and neither knows the other is there.
If you are picking one, the question is not which is better. It is whether the client's next ten requests will fit in a field. If yes, Decap. If you honestly do not know, that is the answer too.
The technology post has what the agent can and cannot reach. Decap's own documentation is good and worth an evening.