Imagine having access to all the wisdom about Umbraco best practices from the get-go in just a few clicks. Simply put, that’s our goal with the Implementation Skill for Umbraco. But, even in this era of AI, it’s not that simple. There are quite a few considerations and a lot of continuous “behind the screens” work to be done before we can proudly present these skills. But the work has started, and we’re confident this skill will be a big help for getting more and better Umbraco projects out there, benefiting everyone in the Umbraco ecosystem.
And let us be clear - the goal isn't to create a rigid blueprint that homogenises every Umbraco site. That’s not Umbraco. The goal is almost the opposite: by encoding a well-reasoned starting point, we free developers to focus on the interesting problems specific to their project rather than re-learning lessons every developer before them already learned the hard way.
Why Umbraco Needs Implementation Skills
Umbraco is a toolkit. That's genuinely one of its greatest strengths. You can build almost anything with it. But that openness is also what makes the learning curve more challenging.
When you install Umbraco, you get a blank canvas. Yes, there are several starter kits to choose from, so you don’t have to start from scratch, but they're not a teaching tool, and they don't explain why the structures are the way they are.
This, you can of course learn by going on Umbraco training courses that cover all the fundamentals: document types, data types, and how to navigate the backoffice.
But how do you actually structure a site that will still be pleasant to work with in three years? What are the best practice implementation patterns?
That knowledge exists. It lives inside agencies, inside the heads of developers who've shipped dozens of Umbraco projects. The problem is that it stays there and becomes “quiet standards”. That means every new developer who joins a project or starts their own goes through the same learning curve to figure out a solid implementation setup. And in this process, the same mistakes get made, the same lessons get re-learned, the same "oh, I shouldn't have done it that way" moments happen to everyone.
This has real consequences. The Customer Support Teams at Umbraco regularly encounter implementations that reveal a fundamental misunderstanding of how the CMS is meant to work. Anyone who has inherited an Umbraco site built by a team figuring it out as they went will recognise the pattern: document types that have sprawled in unpredictable directions, content hierarchies that make sense to no one, compositions that could have been but weren't.
The goal of these skills is to surface the “quiet standards”. To make them explicit, legible, and accessible, without calcifying them into rules. The difference matters. A rule says "always do X." A skill says "Here's why experienced developers usually do X, and what to think about when deciding whether your situation is different."
And the business case is simple. Starting a project with community-backed skills gives you a massive head start. Taking over a project built on those same standards makes maintenance and development seamless. But it’s not just about business, it’s about quality. When we raise the floor of implementation standards, the entire Umbraco ecosystem wins.
Setting Boundaries: What These Skills Are (And Are Not)
Before getting into the specifics, it's worth being explicit about scope. This came up early in conversations about what these skills should cover, and it's the right thing to address head-on.
These skills are about Umbraco implementation. Not MVC patterns in general. That's Microsoft's domain. Not front-end frameworks. Not how to build a Next.js application that consumes a headless API. Those are important topics, but they're not Umbraco's job to opine on. The moment we start doing so, we dilute focus and risk giving advice we're not best placed to give.
Even within Umbraco's world, boundaries matter. Razor templating sits at the edge: we'll cover how templates work in Umbraco, how property editors are rendered, and how block grids and block lists are handled in views. But we're not going to turn this into a Razor tutorial. The distinction is whether a question is primarily about Umbraco or about an adjacent technology that Umbraco uses.
There is enough depth in Umbraco alone to keep these skills focused, valuable, and excellent. Staying within that depth is a quality decision as much as a scope decision.
Implementing Umbraco Sites: The Core Skill
The most important skill area is implementation: how you actually build an Umbraco site from the ground up.
C#
This covers a lot of ground. On the C# side: how you write controllers, how routing works, how CRUD operations fit into the Umbraco model, how composition works, and how you handle scope and dependency injection correctly. These aren't exotic edge cases. They're the decisions you make on every project, and getting them wrong early creates compounding problems.
Models Builder
Then there's Models Builder. Understanding what it does, how to configure it, how to manage the generated models, and how changes to document types flow through to your code. Models Builder is one of those tools where the happy path is genuinely good, and the misuse patterns are genuinely painful. That’s exactly the kind of thing a skill can encode well.
Razor
On the Razor side: templates and layout views, how to work with property editors in views, the right way to handle block grids and block lists. Block lists in particular are a common source of confusion because they're flexible enough to be used in several different ways. Not all of which hold up well over time.
Headless Implementation (Delivery API)
Headless Umbraco is no longer a niche approach. Since Umbraco 12, the Content Delivery API has been part of the core. Built in, not bolted on. The number of projects using it is growing steadily. Implementation skills need to reflect that reality.
On the Umbraco side of a headless implementation, there's a meaningful set of things to understand: how the Delivery API is configured, how you control what's exposed and what isn't, how routing works differently in a headless context, and how webhooks can be used to trigger downstream processes when content changes. Caching strategies also behave differently when the consumer isn't a traditional Razor view. Understanding those differences matters for getting performance right.
The critical word there is "Umbraco side." These skills will cover what you need to know to set up and manage a headless Umbraco backend well. They won't prescribe how to build the Next.js or React application consuming that API. That's a deliberate choice, and it ties back to the boundaries we've already discussed. There are excellent resources for building with those frameworks; what's been missing is clear, consolidated guidance on the Umbraco side of the equation.
That said, integration guidance might come later. Once the foundational skills are established and proven, extending them with patterns for specific consumer frameworks is a natural next step. But establishing the core well is the priority.
Testing Strategy for Implementations
Testing deserves its own section because it's too often treated as an afterthought in CMS development. Something you add when there's time, which means something you rarely add.
Good Umbraco implementation is testable by design. That means making architectural decisions that support testing from the start: keeping logic out of controllers where it can live in services, being thoughtful about how document type models are used in code, and understanding how Umbraco's composition model enables dependency injection in a way that makes test setup manageable.
Unit testing and integration testing serve different purposes and have different trade-offs in the Umbraco context. Unit tests are fast and focused; integration tests exercise more of the stack and catch a different class of bug. The skills here won't mandate a testing philosophy, but they will encode patterns that experienced Umbraco developers use. Because a team that inherits a well-tested Umbraco implementation is starting from a fundamentally better place.
Content Modelling: The Foundation
If there's one area where getting it right pays dividends for the entire life of a site, and getting it wrong creates immediate, compounding technical debt, it's content modelling.
Content modelling is also, paradoxically, one of the least formally taught parts of Umbraco development. Training courses tend to explain the mechanics: here's what a document type is, here's how to add properties. But what about the strategy: when should you use composition versus inheritance? When does a tab add clarity versus when does it add noise? How should you structure a blog list, and what are the failure modes of the approaches that seem reasonable at first?
These questions have answers. Not single correct answers in every case, but hard-and-fast rules the community has developed through years of building, inheriting, and fixing Umbraco sites. Rules like: compositions are almost always preferable to deep inheritance chains. Block grids need to be planned carefully before editors start using them, because restructuring them later is painful. URL pickers and link management have specific patterns that avoid subtle bugs.
The vision here goes further than a checklist of rules. Content modelling skills, if built well, could act as a complementary knowledge base that integrates with MCP (Model Context Protocol), providing real-time guidance as document type structures are being built. And further still: there's an opportunity to define a standardised "Content Requirements Document" format. An equivalent of the Product Requirements Document familiar from software development, but purpose-built for defining content architecture. A CRD created during the planning phase could feed directly into an MCP-powered site generation process, turning design decisions into Umbraco structure without manual translation.
That vision requires getting the foundational skills right first. But it's worth noting where this can lead.
We choose the Community-Driven Approach
