<- Technologies
/
Wagtail Development
A CMS that gets out of the way. Django underneath, editors in control above.
Wagtail is our CMS of choice when content teams need power and developers need flexibility. Not because it's trendy—because it works.
What We Build
Content-driven platforms. Marketing sites with complex editorial workflows. Multi-site architectures under a single admin. Headless CMS backends powering React or Next.js frontends. Publishing systems where non-technical editors need to do sophisticated things without calling a developer.
We've built sites with a handful of page types and platforms with dozens of content models, custom workflows, and integrations with external systems. We've migrated content from WordPress, Drupal, and legacy systems into Wagtail. We've set up editorial teams to manage their own content and built approval workflows for organizations that need them.
What we build less of: simple blogs that WordPress would handle fine, applications where content management is an afterthought, projects where the CMS choice is already locked in elsewhere. Wagtail shines when content architecture matters. If it doesn't, simpler tools exist.
Why Us
How We Work
Sometimes you have a team, a process, and a rhythm—you need specialists who can plug in and elevate what's already working. We do that. Your tools, your ceremonies, your preferences. We adapt, and we'll point out where things could be sharper—but the mode is integration, not takeover.
But often, especially with new content platforms or CMS migrations, you need more than hands. You need someone to own the process end-to-end. Set the standard. Make the calls. Tell you what's working and what isn't.
When we lead, we actually lead. That means a clear rhythm: two-week sprints, weekly syncs, monthly reviews that look forward as much as back. Decisions documented in writing so you always know why something was built a certain way. We bring the tools—Linear for tracking, Slack for daily pulse, Notion or Confluence for documentation built to last—but more importantly, we bring the discipline to use them well.
What makes CMS projects different: editors are users too. We involve content teams early, test workflows with real content, and iterate based on how people actually work—not just how developers imagine they'll work.
What stays constant either way: direct communication, no surprises, and feedback that's honest even when it's uncomfortable. We'd rather have a hard conversation about content architecture in week two than a CMS that editors hate in month six.
What We See Go Wrong
The most common pattern: content models designed by developers without input from editors. Fields that make sense technically but don't match how content is actually created. Page types that are too rigid or too flexible. Editors forced into workarounds from day one.
We also see the opposite: content models designed entirely around current content without thinking about future needs. Everything works until someone asks for a new page type, and suddenly the whole architecture needs rethinking.
Another pattern: underestimating migration complexity. Teams assume moving from WordPress or Drupal is mostly copy-paste. It's not. Content structure, URL handling, media management, redirects—migration is a project in itself, and treating it as an afterthought shows.
We're not here to judge how you got here. Sometimes the original CMS was right for the time. Sometimes the team that built it is gone. We come in as partners—assess what exists, understand what content teams actually need, and figure out the path forward.
Technical Approach
Content Modeling is Where Projects Succeed or Fail
We design page types and content blocks based on how editors think, not just how developers would organize data. StreamField for flexible content. Structured page types when consistency matters. The right balance depends on your editorial workflow, not on technical convenience.
Custom Functionality Through Django
Wagtail is Django, which means when you need something Wagtail doesn't provide out of the box—custom authentication, complex permissions, integration with external systems, specialized workflows—we build it with Django's full power. No awkward workarounds.
Multi-Site Architecture When You Need It
Single Wagtail installation, multiple sites, shared or separate content as required. We've built multi-brand platforms and multi-region sites where content governance had to work across organizational boundaries.
Migrations Done Properly
Content mapping, URL preservation, redirect handling, media migration. We've moved sites from WordPress, Drupal, and custom systems into Wagtail. We know what breaks and how to prevent it.
Who We Work Well With
Clients who care about editorial experience, not just developer convenience. Who understand that a CMS is a product for content teams, not just a checkbox for "has backend."
Also: clients building something where content is genuinely central. Not "we need a blog eventually" but "our business runs on content and the people who create it need serious tools."
What both types have in common: direct communication, involvement of actual editors in the process, and treating our team as partners rather than vendors executing a spec.
Who We're Not For
If you're comparing agencies on hourly rate alone, we'll lose that spreadsheet every time. What we won't lose is a year of editors working around a CMS that doesn't fit how they actually work.
If you need a simple blog or brochure site and don't have complex content requirements—WordPress or a simpler solution might genuinely serve you better. Wagtail's power comes with complexity. If you don't need that power, you're paying for overhead.
If you want the CMS decision made without involving your content team, we'll push back. We've seen too many projects where technical choices were made in isolation, and editors paid the price. The people who use the CMS should have input on the CMS.



