The boring bit of every Umbraco build

If you've done more than one Umbraco build, you know the shape of the first week. Document types. Compositions. Block Grid and Block List editors. Views and templates. A content tree that reflects the design. Hosting and deploys. None of it is technically hard. All of it is time-consuming in a way that creative work is not.

Most of this work can be automated. Not in a "we've written a generator and we're pretending that makes us a product company" sense. In a "Claude Code plus a custom MCP server does the boilerplate, a developer drives" sense.

This is how we do it at Simplepage. I'll show the pieces, the workflow, and a concrete example from simplepage.com itself.

Start with: what are Claude Code and MCP

If you're up to speed, skip this section.

Claude Code is Anthropic's CLI tool that runs Claude in a shell and gives it access to your local filesystem, bash, and anything else you hand it. It reads and writes files, runs tests, runs migrations, commits to git. It is Claude with hands.

MCP (Model Context Protocol) is an open spec for giving an LLM a structured connection to a tool. Think of it as a JSON-RPC layer between Claude and whatever system you want it to work with. A Slack MCP server lets Claude send messages. A Postgres MCP server lets Claude run queries. And an Umbraco MCP server lets Claude create document types, templates, blocks, and content inside your CMS.

Together, Claude Code plus an MCP server is what takes AI-assisted development from "autocomplete on steroids" to "scaffold this whole backoffice schema for me, then populate it".

The Umbraco MCP server

There is a community MCP server for Umbraco (see the Umbraco Community repo for the current state of play) and we run it against our dev instances. It exposes a set of tools to Claude:

  • Create document type (with properties, compositions, allowed children)

  • Create data type (including block grid, block list, rich text, and custom property editors)

  • Create template (empty, or from a Razor file)

  • Create content node (at a given location, with property values set)

  • Publish content

  • Query the content tree

Nothing magic. Each tool is a thin wrapper over the Umbraco Management API.

What makes it useful is that Claude can now reason about the backoffice. If I hand Claude a design system and say "build me the document types for this", it can work through the design, identify the reusable patterns (heroes, CTAs, testimonial grids), create compositions for the shared properties, create document types for each page pattern, and then create example content that demonstrates each one. In an afternoon. Without me clicking through the backoffice a hundred times.

Our working pattern

This is the loop we use for every new Simplepage build:

Step 1 - Claude Code reads the design system and the project brief.

The design system lives in a markdown file (you've seen ours, linked in the footer). The brief is a short markdown doc describing the information architecture: which pages exist, what blocks they use, what content they hold. Claude reads both.

Step 2 - Claude proposes a schema.

It generates a draft schema: compositions, document types, block element types, data types. Output is a markdown summary, not code. I read the summary and push back on anything that looks wrong. This is where human judgement earns its keep. It takes thirty minutes. Without AI, proposing and sanity-checking an architecture at this depth is a half-day of whiteboarding.

Step 3 - Claude executes against the MCP server.

The schema is locked. Claude calls the MCP server to create each document type, composition, data type and template. On our dev instance, this takes about ten minutes for a site with ten doc types and twenty blocks. I watch it and spot-check.

Step 4 - Claude creates populated sample content.

Once the schema is in, Claude creates enough content to demonstrate each pattern. A homepage with hero, feature grid, testimonial block, CTA. Three sample blog posts. An About page with the right compositions. Real-looking content, not lorem ipsum, because a designer reviewing a populated site needs to see how copy flows through the blocks.

Step 5 - I build the views.

Razor views, partial views, the front-end CSS and JS. This is the bit I still do myself. AI helps on the block-view boilerplate (each block type has a predictable shape), but the actual layout and the design system implementation is human work. CSS is opinionated. So is my taste.

Step 6 - Iteration happens in both directions.

Content tweaks happen in the backoffice. Schema tweaks go through Claude again, which keeps document types, compositions and the MCP executions in sync. Git history records everything (our MCP server produces a migration file for each change).

A concrete example: the Simplepage homepage

When we built simplepage.com itself, the pattern above did the first-week-of-Umbraco work in a single afternoon.

  • Step 1: read design-system.md and the project plan. 10 minutes.

  • Step 2: Claude proposed compositions (_Core for title and SEO fields, HeroComposition for hero blocks, BlockItemCore for block background colour and hide flag). I pushed back twice - once on a proposed generic body property I didn't want on every page, once on a missing hreflang field on the SEO composition. 25 minutes.

  • Step 3: Claude created 13 document types and 23 block types against the dev Umbraco instance via MCP. 12 minutes elapsed time.

  • Step 4: Claude populated the homepage, about, product hub, and three product pages with realistic content from the project plan. 15 minutes.

  • Step 5: I started writing the Razor views. By the end of the day the homepage rendered.

Total time from empty solution to rendering homepage: one working day. The same work two years ago was a week, and I know because I was doing it.

Where it goes wrong

It's worth being specific about what does not work.

Anything that needs cross-cutting knowledge. Claude Code does not know your existing codebase's conventions unless you tell it. The first time we ran MCP scaffolding on an existing project it created property aliases that violated our aliased-naming convention. We added the convention to our CLAUDE.md and it doesn't happen again. But you have to know to do that.

The design decisions that aren't obvious in a design file. A designer shows you a hero with a photo. Claude will give you an image property of type Media Picker. What's missing is the mobile-crop decision, the alt-text requirement, the fallback behaviour when there's no image. Human design judgement lives in those gaps.

Anything involving customer data or live content. We never point the Umbraco MCP server at a production instance. It runs against dev, changes flow through git, and deploys follow the normal pipeline. If the MCP server had a write-anything-you-like permission on a live client site, one bad prompt would be an incident.

If you run an agency and want this workflow

The pattern above is the core of Simplepage Automations - a service we offer where we set up this exact workflow for other Umbraco teams. The MCP server, the CLAUDE.md conventions, the schema-proposal-first loop, the handover on how to drive it.

It is also the core of how we build our own Rapid Development projects. If you have an Umbraco build on your plate and you want it to be a two-week project not a two-month one, this is how we do it.

Or if you want the AI content layer inside the backoffice too, that is a different product: Eddi.