Wagtail CMS development

Almost none of the work is installing Wagtail. It is deciding what your content actually is, and that decision is the one you cannot cheaply undo:

• Page models. Which things are pages, which are snippets, which are settings. Get this wrong and editors end up copying and pasting the same block into forty places.
• StreamField blocks. The temptation is one block that does everything, configured by a dozen checkboxes. The better answer is a small set of blocks that each do one thing, because every option you add is a decision an editor has to make on every page forever.
• The editor experience. Field ordering, help text, validation and what the preview shows. This is the part nobody specifies and the part that decides whether the CMS gets used or worked around.

I work directly with you rather than through an account manager, and in small increments you can see. In practice that means a working staging site early and often, rather than a long silence followed by a reveal.

I also take over existing Wagtail projects. That is a different job from a new build — the first weeks are spent reading, getting tests around what matters and finding out which parts of the codebase are load-bearing — but it is work I have done repeatedly, and an inherited codebase is not a reason to start again.

• A CMS your team can use without a manual, because the blocks match the way you actually write.
• Page models that will still make sense when the site has three times as much content in it.
• Tests around the parts that would be expensive to break.
• A site you can hand to someone else. No proprietary layer, no licence, no lock-in — Wagtail is Django, and Django developers are not hard to find.

HFBK Hamburg is an art and design university whose site came across from a media agency. The interesting part is a custom-built search backend: the site is structured around one large search bar instead of conventional navigation, which only works if the search is genuinely good.

ISIMIP is a climate-impact research network where I was the lead developer, including the conference site for the Impacts World conference in 2017. That engagement ran long enough for me to live with my own architectural decisions several times over, which is the most useful thing that can happen to a developer.

Distylerie, a branding agency in Zurich, needed its animation-driven content to be editable rather than hard-coded into the templates.

Duesenberg, a guitar maker, needed editorial design freedom on the product pages — the same requirement from the opposite direction, and a site I still look after today.

It is worth saying, because a developer who only ever recommends the thing they sell is not giving you advice.

If the site is five pages that change twice a year, a CMS is overhead you will pay for forever — static hosting and a developer for an afternoon is cheaper and faster. If your team is entirely PHP and has no intention of changing, a well-run WordPress build you can maintain beats an excellent Wagtail build you cannot. And if what you actually need is an application with a bit of content attached rather than content with a bit of application attached, the CMS should not be the centre of the architecture.

Wagtail earns its place when there is real content, more than one person editing it, and a structure worth modelling properly.

Whether it is a new build or a site you have inherited, get in touch and describe what your editors are trying to do and where the current setup fights them. That is usually a more useful starting point than a feature list.