"It's just a blog — we could build that in a sprint" is a sentence said in every SaaS engineering channel eventually, and it is even sort of true. A table of posts, a couple of routes, a markdown field: a sprint. What that estimate misses is everything the sprint version lacks, and everything the years after the sprint cost. Having built this stack — Kookee exists because we think most teams shouldn't — here is the honest ledger.
What "just a blog" actually expands into
The sprint version has no editor worth the name, so the expansion begins immediately:
The editor. Marketing will not write in markdown files behind a pull request. A real rich-text editor — images, embeds, code blocks, undo that works — is weeks of work even wrapping an open-source editor framework, and it never stops needing attention.
Media handling. Uploads, storage, image resizing, a CDN path, size limits. Every content system grows one; yours will too.
Workflow. Drafts, scheduled publishing, preview links, revision history someone will beg for the first time an editor overwrites an hour of work.
The fields around the content. Slugs and their uniqueness, tags, categories, SEO metadata, open-graph images, timestamps.
Then the second surface arrives. A changelog wants types and versions; a help center wants categories and search; feedback wants voting, statuses, and comments. Each is "small", each re-implements authoring, storage, and delivery with a twist, and each becomes another internal product with you as its only maintainer.
A conservative shape for blog + changelog + help center with a usable admin UI is measured in months of engineering time, not sprints. At typical loaded engineering costs, that is real money before a single user sees a page — and it is the cheap part.
The line item everyone forgets: forever
The build estimate ends at launch. The system does not:
Security and dependencies. Your content system is now attack surface — auth, uploads, a public API — that you patch on your schedule, forever. Dependency updates, framework migrations, the editor library's breaking major version: yearly taxes.
Infrastructure. Hosting, database, object storage, CDN, monitoring, backups. Individually small, collectively a standing bill and a standing pager duty.
The feature treadmill. Search that actually finds things (today that means semantic search and embeddings), translations when you go international, AI answers when your competitors' help centers get them. Each is a project on a system nobody wants to own.
Maintenance for an in-house content stack plausibly runs to weeks of engineering per year — quietly, spread across "quick fixes" that are never quick. The deeper cost is opportunity: every hour there is an hour not spent on the product customers pay for. Content infrastructure is a commodity; your product is not. Spending scarce engineering on the commodity is the actual mistake, independent of the invoice.
The case for building anyway
Build-vs-buy pieces that never concede the build case are advertising. There are real reasons to build:
Content is your product. If you are a publishing platform, a docs company, or content workflows are your differentiation — build. The generic tool will fight you.
Hard constraints. Regulated environments where content must live in your infrastructure, air-gapped deployments, data-residency rules a vendor cannot meet.
Truly unusual models. If your content genuinely does not look like entries with fields — though check whether custom entry types on a platform cover it before deciding it doesn't.
What does not hold up: "we'll build exactly what we need, nothing more." The needs list above is not a vendor's feature bloat — it is what every content system converges on, because editors, marketers, and readers keep asking for the same things.
What buying should actually get you
If you buy, hold the vendor to the standard that justifies not building:
Your domain and your frontend. Content delivered as JSON over an API and SDK, rendered by your app with your design system, so SEO accrues to you and nothing looks bolted-on. If the vendor insists on hosting your pages, you have bought a website builder, not infrastructure.
No lock-in. Everything retrievable as documented JSON with your API key. The exit door being open is precisely what makes entering safe.
The whole surface, one system. Blog, changelog, help center, feedback, pages — the value compounds when the feedback board links to the changelog entry and the help center feeds the AI answers, with one dashboard and one API instead of four stitched vendors, whose combined subscriptions routinely exceed a single platform anyway.
A free path to start. You should be able to validate the integration before paying anything.
This is the shape Kookee is built to: a content backend with the modules SaaS products actually need, a typed SDK and React hooks for the rendering layer, a hosted portal for day one, and API-first delivery so the only code you own is the thin part that was always yours — the rendering.
A decision procedure
Is content your differentiator, or a hard constraint in play? If yes, build, deliberately and staffed.
Otherwise, prototype the buy path: render your blog list and one help article through a platform's SDK on your domain. Budget a day.
Price the build honestly: initial months plus yearly maintenance, at loaded cost, against the subscription.
Decide once, in writing, and stop relitigating it every time someone says "it's just a blog."
The sprint-sized blog is real — you can have it by Friday. It is the five years after Friday that the buy side is priced against.