Why I built InkCMS — a CMS for the agent era.
I've been building content management systems for thirty years. InkCMS is the seventh one. The first six are still out there running production sites for real businesses — none of them are going away. But InkCMS is the first one I built for a world where Claude is sitting next to the editor. That changed everything.
Thirty years on the Microsoft stack
I built my first CMS in the late 1990s using classic ASP. The shape was set early: a SQL database in the back, a forms-based admin in the middle, a templating layer in the front. That model worked. It scaled. It paid the bills for a generation of agencies and platforms.
Then came ASP.NET Web Forms in the early 2000s, and we ported the engine. Then ASP.NET MVC in the late 2000s, and we ported again — better separation of concerns, cleaner routing, but the same SQL-in-the-back shape. Then .NET Core in the mid-2010s opened the door to Linux deployments and a leaner runtime, and we ported once more. Then .NET 6 in 2021. Then .NET 8. Each migration kept the core data model intact: pages were rows, content was columns, layouts were templates that joined them at render time.
Six platforms. Three decades. Hundreds of production sites — corporate, e-commerce, editorial, internal portals, financial forecasting tools, member directories. The underlying CMS engine got faster, cleaner, better tested with every rewrite — but architecturally, you could have shown the 1998 codebase to the 2024 codebase and they'd recognize each other. The shape of a CMS hadn't changed.
The moment everything tilted
In early 2025 I started experimenting with Claude on real client work — drafting copy, restructuring content models, fixing markup. The exercise was supposed to be efficiency: how much faster can a senior editor work with an AI alongside them?
What I noticed instead was where Claude struggled.
Claude struggled with admin forms. It struggled with the dropdown-of-content-types pattern. It struggled with "click here to add a row, click here to save, then click here to publish." When I asked it to fix a typo in a paragraph, it wanted to edit a file — and our CMS, like every other CMS we'd built, refused to give it a file. There was no file. There was a SQL row.
Meanwhile, Claude was extraordinary at the parts of our stack that were files. Razor templates. CSS. JavaScript. Markdown documentation. Configuration. Anything that lived on disk, Claude could read, understand, modify, and put back. The friction was on the database side — exactly where we'd been investing for thirty years.
The penny dropped sometime in March. The data model was the bottleneck. Not the runtime, not the templating engine, not the deployment story. The decision we'd inherited from 1995 — that content belongs in a SQL database — was actively working against the most powerful authoring tool that had ever existed.
What we threw out — and what we kept
InkCMS is a clean-sheet build on .NET 10. Every piece of state — pages, menus, entities, users, sessions, audit logs, conversation history — lives on disk as Markdown, YAML, or JSON. There is no database connection string. There is no schema migration. There is no admin-form-as-the-only-path-to-edit. Content is files. Files are the interface Claude already understands.
That's the throw-out. What we kept is harder to see, but it's most of what matters:
- The publishing model. Drafts in staging, snapshots on save, audit log on every action, rollback per page. Every CMS we'd built had this; the new one didn't get to skip it.
- The security boundary. Admin sessions in HttpOnly cookies, role-based gating, 2FA with TOTP, no AI access to shell or secrets, IP allowlisting, signed license activation. We didn't reinvent any of it — we ported the patterns that already worked.
- The performance posture. Eager startup indexing, in-memory caches with file-watcher invalidation, response caching, image resizing on demand. The decisions that made the SQL versions fast still make the filesystem version fast.
- The "developers own the stack" principle. InkCMS is source-available. Customization is C#, Razor, and CSS — the same skills every .NET developer already has. No proprietary scripting language. No plugin economy. The site is your ASP.NET app; we just shipped it.
That third principle deserves more weight than a bullet point. "Developers own the stack" isn't just about templates and CSS — it's the architectural decision that lets InkCMS sit at the core of any project, not just play the CMS role inside one. Every install carries a dedicated /Custom directory: your controllers, your services, your views, your data layer, your migrations. Anything you put there is yours, and the installer is contractually obligated to preserve it across every product update. When a new InkCMS release ships, our changes flow into the product files; your /Custom tree is untouched. No merge conflicts. No manual port. The update happens, your application keeps running.
The inkcms.ai site you're reading right now is the working example. The marketing pages are normal CMS content — but the entire customer portal sitting under /accounts is custom code: recurring Stripe billing, license-key issuance, install heartbeat tracking, support ticketing, installer downloads, audit logging. All of it lives in /Custom. None of it required forking the platform. None of it breaks when the platform updates.
The same shape handles everything we've used it for so far — member-management systems, gated content portals, e-commerce extensions, real-time dashboards, custom AI tools that show up in the admin assistant alongside the built-in ones. The substrate is a CMS for the editors and administrators who run the site day-to-day. The extension surface is a full ASP.NET application for the developers who need to build something bigger than a CMS knows how to do. One install, two audiences, no compromise between them.
What's new is the AI surface. Two of them, actually: an admin-side editing assistant that proposes changes and writes them through approval cards a human clicks to apply, and a public-facing AI Advisor that visitors can ask questions in your brand's voice. Both run on a provider you choose — Claude, GPT, or Gemini — using your own API key. They never pass through our servers. That was a deliberate decision. AI capability is a commodity we'd rather have you own.
Where we are right now
InkCMS is in Preview release. That's stronger than beta — the system is running production sites today, this one included, and new installs go live every week. It's also less than "1.0 mature" in the way you'd expect from a platform that's been around for years. Some sharp edges exist. We're closing them in public.
Try it without paying — create an account, download the installer, run it on localhost. Localhost is unlimited, unactivated, always free. Build a real site with it. The same install is what runs production once you point it at a real domain and add a subscription key. The difference is the heartbeat to our licensing server, not the code path or the feature set.
If you've been building CMS-driven sites long enough to have opinions about the shape, the easiest way to evaluate InkCMS is to do exactly that — boot it, point Claude at a real content task, and see whether the friction you've come to accept disappears. That's the result we built it for, and that's the part that's hard to summarize on a marketing page.