Why we built our own blog
We build content systems for clients, so for our own blog we built one more: markdown, scheduling, cleaned images, and an admin that lives in our own site.
3 min readTanveer Singh
We build content management systems for clients. When it came to our own blog, the obvious question was whether to build another one or rent one.
We looked at three ways to do it.
| Where posts live | Who can write | What it costs us | |
|---|---|---|---|
| A git-based editor | Files in the code repository | Anyone with a GitHub account | Every post is a deploy |
| A hosted CMS | Someone else's servers | Anyone with a login there | Another account, another vendor |
| Our own admin | Our own Firebase project | Anyone we allow in | We build and maintain it |
We chose the last one, for three reasons.
It's the work we sell
Content platforms are one of the studio's services. A blog that runs on our own admin is the same kind of thing we hand over to clients: a login, an editor, a media library, and publishing that doesn't need a developer. If something about it is awkward, we're the first to find out.
It fits what we already run
The site already uses Firebase for its data, so posts sit in the same Firestore database as everything else, images go to Firebase Storage, and sign-in is Google through Firebase Authentication. Only the studio's own accounts are allowed into the admin; anyone else who signs in is turned away by the server.
It's markdown
Posts are written in markdown, in a proper code editor with a live preview beside it. The preview isn't an approximation: it uses the same renderer as the published page, on the same graph paper.
Markdown here also means MDX, so a post can drop in a few of the site's own components — a portfolio project, a Lab exhibit, a video, a note like this one:
The details that made it worth building
- Drafts save themselves. A published post doesn't: edits to a live post wait until someone presses Update, so nothing half-typed reaches the site.
- Scheduling. A post can be set to go live at a chosen time, and it appears on the site the moment that time passes.
- Images are cleaned on the way in. An upload goes straight to Firebase Storage, then the server resizes it to at most 2,400 pixels, converts it to WebP, strips its metadata — phone photos carry the GPS position they were taken at — and deletes the original.
- Tags remember. Type a tag once and it's offered from then on. "Next.js", "nextjs" and "NextJS" are the same tag, so the list doesn't fill with near-duplicates.
- Images in use can't be deleted. The media library shows which posts use each image, and refuses to delete one that any post still uses.
The trade-off
A hosted CMS would have been running in an afternoon. This took longer, and we maintain it ourselves. For a studio that builds these systems, that's the point: we'd rather find the rough edges in our own admin than in a client's.
From the portfolioNobility Care AustraliaCompany Website · See the project →