How much content is enough for a studio site?
Publishing on satanilabs.com—blog vs insights, cadence, and why eight solid articles beat a empty writing hub waiting for perfect.
Studio sites die from two content failures: never publishing because the case study is not “ready,” and publishing filler that erodes trust. I rebuilt satanilabs.com with a writing hub—blog for long-form build stories, insights for shorter craft notes—and had to decide how much was enough to launch without pretending to be a media company.
This meta piece is that decision written down.
The hub needs proof, not volume
Visitors do not count posts; they sample one. The writing hub needs a featured article that shows how I think, plus enough neighbors that the index does not look abandoned. Eight pieces—five blogs, three insights—was my launch floor. Fewer and /writing feels like a promise deferred; many more and I would delay shipping the portfolio itself.
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 skeptical technical buyer reads one article and thinks, I know how this person ships. Launching with eight files crossed that line for me. The site will grow; the hub is designed for markdown in git, not a CMS migration later.
The eight-piece launch set spans product work (LenDen), enterprise patterns (finance UI, Angular adoption), field mobile (Capacitor), and meta craft (WebGL questions, motion a11y, publishing itself). That spread answers “can he ship?” better than eight posts on the same toolchain.
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.