Why we built our own Umbraco platform
Every Umbraco project started with the same weeks of foundation work: SEO plumbing, security headers, accessibility groundwork, block architecture. After enough repetitions the conclusion was obvious: solve it once, properly, and stop billing clients for solved problems.
The pattern behind every project
Every Umbraco project I have taken on over the years started the same way: two to three weeks of foundation work before anything client-specific happened. Canonicals, hreflang, sitemaps, structured data, security headers and a content security policy. Not to forget to mention performance defaults and accessibility groundwork. A block architecture editors can actually work with. None of it is glamorous, all of it is necessary, most agencies in the market rebuilds it from scratch, or has a half-baked version to start with, on every project.
After enough repetitions the conclusion stopped being interesting and started being embarrassing: these are solved problems. Rebuilding them per project is not craftsmanship, it is waste.
Solve it once, and dare to be opinionated
So I built the foundation once, properly. The KindbergCo Umbraco Platform is a production-ready Umbraco 17 foundation: clean architecture, reusable Block Grid content structures, SEO plumbing in place, multilingual support, a strict content security policy with per-request nonces, performance defaults, and accessibility groundwork built against WCAG 2.2 AA principles. It represents over 500 hours of development work – but the honest value claim is not the hours I spent, it is the setup phase you skip.
Here is the opinion that shaped it: generic starter kits fail because they refuse to make decisions. They stay neutral on everything to suit everyone, which means every real decision still lands on your project budget. The value of a platform is precisely the decisions already taken – and the willingness to be wrong about the ones that do not matter.
A concrete example of what opinionated means here: every frontend script on the platform carries a per-request CSP nonce, because the production content security policy uses strict-dynamic instead of an allowlist. That decision is invisible in a demo, tedious to retrofit, and exactly the kind of thing a foundation should have settled before day one of your project.
Proof: you are looking at it
kindbergco.com runs on the platform with minimal deviation. The blocks on this page, the language switcher, the structured data in the source, the green Core Web Vitals scores – that is the product, in production, in front of you. A platform vendor whose own site runs on something else is telling you what they really think.
What it is not
It is not a theme, not a one-click website, and not a replacement for implementation work. It is designed to be extended, not merely configured. And on the question every developer asks in 2026: AI can help generate code. It does not replace a tested architecture, production patterns, CMS editor experience, SEO structure, accessibility decisions, and senior developer review.
Why it exists commercially
Two reasons, stated plainly. It is a licensed product for companies, agencies and developers who want a serious starting point. And it is the foundation I build client projects on, which keeps it honest: every real project pushes improvements back into the platform. You can buy it, or you can hire me to build on it – both start in the same place.
The full picture – what is included, who it is for, and how licensing works – is on the platform overview. The features and blocks pages show the details.