Building a Custom CMS vs Using One That Already Exists

When I decided to rebuild heathschweitzer.com on Next.js, I faced a choice... do I build it on what I know or do I challenge myself to learn something new and build my own custom CMS. I decided I was up for a challenge and I built my own. Here's what I learned — and when that decision makes sense versus when it's a colosal waste of time.

The Options I Considered

The modern CMS landscape broadly falls into three categories.

Traditional monolithic CMSs like WordPress couple the content management UI with the frontend presentation. You get everything integrated but you're working within their architecture.

Headless CMSs like Contentful, Sanity, and Strapi separate content management from presentation. You use their API to fetch content and build your own frontend.

Code-first CMSs like Payload CMS are built on Node.js and TypeScript, generate their own admin UI from your schema definition, and integrate naturally with the kind of stack I was building on.

Payload was the most tempting. It uses Prisma-like schema definitions, has a polished admin UI, supports complex content types, and is fully open source. For a team building a production content platform, it may have been the right call.

Why I Built a Custom CMS Instead

I chose to build my own CMS for one reason: this was a learning project, and the CMS is where most of the interesting learning happens.

Post creation, slug generation, category and tag management, draft previews, scheduled publishing, publishedAt preservation on edits — these seem like solved problems until you implement them yourself and discover the edge cases. A scheduled post that's technically PUBLISHED but has a future publishedAt requires filtering publishedAt <= now() on every blog query and using force-dynamic to prevent Next.js from caching the page with stale data. WordPress solved this years ago. I had to figure it out from first principles.

The process of building the CMS taught me more about Next.js, Prisma, and React Server Components than any tutorial would have. I now understand why Payload and WordPress make the choices they do because I made the same choices independently.

What I Actually Built

The admin section of heathschweitzer.com now includes:

• Post creation and editing with a Markdown editor
• AI-assisted content generation using the Anthropic API with streaming responses
• Excerpt generation
• Category and tag management with create, rename, merge, and delete operations
• Bulk post actions including delete
• Scheduled publishing with a future date picker
• Draft preview mode with an authenticated access gate
• Contact form submissions with read/unread status, archiving, and bulk actions
• A token-gated REST API for creating and managing posts programmatically

That last feature — the API — is what I'm using to publish this post. I wrote it in Claude, exported the Markdown, and pushed it via curl to the production endpoint. The CMS received it as a draft, I reviewed it in the admin, and scheduled it.

Building the API from scratch took less than an hour once the CMS data model was in place. Adding it to Contentful or Payload would have meant reading their API docs and working within their abstractions. Building it myself meant I understood every line.

The Real Cost of Building

I'm not going to pretend building a custom CMS is free. It took significant time, and there are still things Payload or even WordPress handle better:

Rich text and media: My CMS only supports Markdown, a basic image upload, and embedded videos, there's no rich text editor with formatting controls, drag and drop blocks, or an extensible plug-in architecture.

Comments: I have a comment model in the schema but no UI or moderation tools. Payload has this built in.

Content types beyond posts: Everything on my site is a blog post. A real CMS handles pages, portfolios, products, and arbitrary content types. Mine doesn't.

Multi-user workflows: My admin is single-user. No editor/publisher roles, no draft review queues, no collaboration features.

For a personal blog, none of these gaps matter much. For anything beyond that, the calculus shifts.

When to Build vs When to Use Existing

Build your own when: you're learning, the project is small enough that missing features don't matter, and you want full control over the data model and admin experience.

Use Payload when: you need a production-grade CMS with a real team, complex content types, and you want the admin UI handled for you.

Use Sanity or Contentful when: you want a hosted solution with excellent editorial UX and you don't want to manage infrastructure.

Use WordPress when: your editors aren't developers, the plugin ecosystem matters, and you're building a content site that needs to work reliably with minimal maintenance.

The right answer depends on who the users are, what the content model looks like, and how much operational ownership you want. For me, building was the right call — but I went in knowing it was a choice to learn, not a choice to ship fast.