How much content is enough for a studio site?

Studio sites die from two content failures: never publishing because the case study is not “ready,” and publishing filler that erodes trust. Deciding how much writing is enough—without pretending to be a media company—is a question every technical studio hits, and the answer is not a post count.

The hub needs proof, not volume

Visitors do not count posts; they sample one. A writing hub needs a featured article that shows how you think, plus enough neighbours that the index does not look abandoned. Below roughly half a dozen substantial pieces, /writing reads as a promise deferred; waiting for twenty means the portfolio never ships.

Quality bar: each post should answer a question a client might already have (“How do you handle dense finance grids?” “Why ledger-first?”). If it only repeats the homepage bullets, it belongs on the homepage, not in markdown.

Featured posts matter: one piece on the writing hub should represent the depth a prospect will get if they hire SataniLabs. I marked the Next.js build article as featured: true in frontmatter so the hub hero rotates intentionally, not by whatever file sorts first alphabetically.

SEO without becoming an SEO blog

Studio content should attract the searches your buyers actually run: “hospitality FP&A dashboard,” “Capacitor barcode inventory,” “ledger app for small business.” Titles and descriptions are written for humans first, with honest keywords second. I keep descriptions under roughly 155 characters so snippets do not truncate mid-thought.

Internal linking is lightweight: blog posts reference insights where a checklist would help, and vice versa. No content farm interlinking—just paths that respect how technical buyers skim.

Blog vs insights is a contract with the reader

Blog posts carry project narratives and implementation depth—things that age slowly and rank well. Insights are shorter, opinionated, and allowed to be timely (WebGL checklists, motion a11y notes). Mixing them on one route trained readers to expect uniform length; splitting routes sets expectations.

Frontmatter kind enforces the contract in code, not just in nav labels.

---
title: "..."
kind: blog # or insight
tags: ["..."]
---

Cadence beats heroics

I would rather ship one essay a month for a year than binge twelve posts and go silent. Search engines reward consistency; humans reward not ghosting. A realistic cadence for a working studio is 2–4 substantial posts per quarter, supplemented by insights when a client conversation surfaces a reusable idea.

Repurposing is allowed: a migration war story becomes a blog; the checklist you send in Slack becomes an insight. The work is editing for strangers, not inventing topics.

I batch drafting in two phases: outline five titles from real projects, then write bodies over two weekends. Trying to publish one perfect essay per month often means zero essays. Outlines stored in the same content/ folder as finished posts keep git history honest about intent.

Markdown in git beats a CMS (for now)

Posts live beside the Next.js app. Pull requests review copy and code together; previews deploy on Vercel like any feature branch. Reading time and sort order come from the filesystem—no webhook sync, no author accounts to forget.

The tradeoff is non-technical collaborators cannot edit without git. For a solo studio that is acceptable until volume demands a CMS. Frontmatter validation will come next; until then, discipline in review is the schema.

Measuring “enough” after launch

Traffic on a studio blog starts small. I watch scroll depth on one or two flagship posts and inbound messages that mention an article—not vanity pageviews. If prospects quote a paragraph in email, the hub earned its keep.

Update cadence matters more than retroactive rewrites. A post from 2025 that still describes the right architecture can carry a footnote; a post that references retired frameworks should be refreshed or archived, not left to embarrass you in search results.

What I will not publish

AI-slop listicles, keyword-stuffed “Top 10 React Tips,” and faux thought leadership without scars. Anonymized client work still needs ethical boundaries—patterns and principles, not logos and confidential metrics.

Enough content is a moving target

“Enough” is when a sceptical technical buyer reads one article and thinks, I know how this person ships. That is a threshold about depth, not about volume — and it is worth aiming at directly rather than counting files.

What matters more than the number is the spread. A launch set covering product work, enterprise patterns, mobile, and craft notes answers “can they ship?” far better than the same number of posts on one toolchain. Breadth demonstrates range; depth in any single piece demonstrates rigour. You need one of each, and then cadence does the rest.

A simple launch checklist

Before linking /writing in the main nav: featured post set, descriptions unique, dates honest, tags useful for future filtering, at least three posts per kind if you split routes, sitemap includes slugs, and one post you would send cold to a lead. Skip press-release tone; write like you explain work to a peer.

If you are staring at an empty /blog folder: pick one piece you would send a prospect anyway, publish it, and write the second while the first is live. Perfect libraries are for Storybook; studio credibility is built in public, one honest post at a time.