Ashish Pitrodafield notes
All plates

Field guide Plate 01

Wagtail CMS

Wagtail is the framework I know best and the one I am usually hired for. New builds, yes — but more often a site somebody else started, a version that has drifted years behind, or an admin the editors have quietly stopped using.

— the one I am usually hired for

I also teach it: Wagtail Unboxed, a free video series that builds a real Wagtail site from an empty folder and explains every file on the way. And for an upgrade, here is one done end to end and written up: Wagtail 2.7 to 7.4, everything that broke.

I

Where it’s found

who this is for

You have a Wagtail site

and it is behind. The version is old enough that security patches no longer apply cleanly, and every new request gets quoted high because nobody trusts the ground.

You are choosing a CMS

and want the editing experience to be genuinely good rather than a form with thirty fields. Wagtail earns that if the page models are designed rather than accumulated.

Your editors avoid the admin

and paste content in from somewhere else. That is a design problem in the page models, not a training problem, and it is fixable without rebuilding the site.

II

Field marks

what the work actually is

  1. Page models and StreamField

    Designing the content types around what the editors actually publish, rather than around the current page designs — which change. StreamField blocks that compose, so a new layout does not need a developer.

  2. Version upgrades

    Wagtail’s own path is release by release, and skipping to save time is how a two-week job becomes a two-month one. Each step gets its own branch and its own staging round on real data.

  3. The admin itself

    Custom panels, snippets, ModelAdmin, permissions and workflows. If the people using it every day find it awkward, the site is failing at the only job a CMS has.

  4. Search, and the API

    Wagtail’s search backends configured properly, and the headless API when the front end lives elsewhere in Vue or Next.js.

  5. Migrations from something else

    WordPress and hand-rolled Django sites into Wagtail, with URLs preserved and redirects in place so the search ranking survives the move.

  6. Deployment and after

    AWS, Nginx, Postgres, media on S3 and a deploy anyone on the team can run. Then maintenance, if you want it — patched the same week an advisory lands.

III

Behaviour

how it runs

  1. 01Read first

    I go through what exists before proposing anything. On an upgrade this is most of the value.

  2. 02Scope

    A written plan with an order, so you can see what is being done and why that order.

  3. 03Build in the open

    Small branches, staging on real data, and something to look at every few days.

  4. 04Hand over

    Documented in the repository, not in my head. You should not need me afterwards.

IV

What it costs

what decides the price

Three things decide it: how much of what exists can be kept, how far behind the version is, and whether there is a fixed date. An upgrade on a site with a working test suite is a different job from the same upgrade on one without.

Small, well-defined pieces of work are quoted fixed. Anything open-ended starts with a short paid look at the code, which produces a written plan and a fixed number for the rest — and that plan is yours whether or not you carry on with me.

V

Questions

the ones I get asked

How far behind is too far?
There is no version I would refuse. Wagtail 1.x to current is real work and I would say so, but the upgrade path exists and it is walkable. What makes it expensive is not the version gap — it is forked templates and a test suite nobody has run in years.
Can the site stay up while you do it?
Yes, and editorial work does not have to stop either. Upgrades happen on branches, deployed to a staging copy rebuilt from a fresh database, so nobody is asked to freeze content for weeks.
We already have a developer. Is that a problem?
No — a good deal of my work is alongside an in-house team on the piece they do not have time for. I document as I go for exactly that reason.
Wagtail or WordPress?
If your content is genuinely structured and your team is comfortable with Python, Wagtail. If you need a plugin ecosystem and a hundred themes, honestly WordPress, and I will tell you that rather than sell you the thing I prefer.

Send a note

Tell me what you have, what is wrong, and what it should do instead. I will tell you honestly whether I am the right fit.

Write to me or read the other plates