I set out to build a consulting website. Somewhere along the way, I realized I had built a small publishing system.
Not a content calendar attached to a website. A system: distinct editorial voices, explicit sources of truth, structured content, reusable brand assets, version control, quality gates, and a human decision-maker responsible for what goes live.
The difference matters. A website is an output. A publishing system is the set of decisions, handoffs, controls, and recovery paths that make the output reliable.
The First Infrastructure Was Voice
Almost none of this started with code. It started with a question that sounded subjective:
How should this company sound?
I used an interview process to separate two related voices. Katie Kearns is personal, exploratory, and willing to show the reasoning. Structured Ink is more edited and systems-oriented. It speaks as the company and turns an observation into something a reader can use.
Those interviews became voice guides. That was the first piece of infrastructure.
“Sound like me” is not an operating instruction. A useful voice system identifies what each voice notices, how it builds an argument, which claims require restraint, and where the personal and company voices should diverge. Once those decisions are explicit, they can guide drafting and review instead of being reinvented for every post.
Different States Need Different Sources of Truth
The content needed somewhere to live before it became public.
Notion became the editorial system: ideas, campaigns, drafts, publication dates, website metadata, related posts, dependencies, and status. It holds the planning state—the version still being decided.
Once an article becomes part of the website, GitHub becomes the source of truth for the published artifact. The prose travels with structured metadata and the code that renders it. Editorial planning and production content stay connected, but each has a clear home.
Canva holds another kind of source material: brand assets and reusable visual components. Visual consistency is not decoration added after publishing. If every article, post, and page is supposed to look like it came from the same company, those assets are production dependencies.
The goal is not to force every artifact into one tool. It is to make ownership and handoffs legible.
The Prose Behaves Like Data
The Structured Ink site is a Next.js static site managed in GitHub. The repository is treated like a product: issues, branches, pull requests, acceptance criteria, build checks, documented decisions, and tests tied to the behavior they protect.
Insights are Markdown files with structured metadata. Titles, summaries, dates, tags, campaigns, relationships, and featured states travel with the article. The site can generate pages, make them searchable, filter them by topic, and recommend related reading without hand-wiring every relationship.
The content is prose for the reader, but it also behaves like data for the publishing system.
Underneath that visible layer are the quiet systems readers never see: DNS, GitHub Pages, preview environments, regression tests, accessibility checks, and safeguards intended to let one change go live without breaking something next to it.
Automation Still Needs an Authorization Boundary
This system produced a useful failure almost immediately.
An automation saw that this item was marked Scheduled in the editorial planner and treated that state as permission to publish it to LinkedIn. The post was technically ready. It was not approved for that specific action.
That is not just a scheduling mistake. It is a governance mistake.
A workflow state can describe readiness, priority, or intent. It should not silently become authorization to act in an external system. The repair was not simply to delete the post. The publishing rule had to change: automation may prepare, reconcile, draft, and recommend, but publication requires a new, explicit instruction naming the item and channel.
The failure made the architecture clearer. Human judgment is not the temporary part of the system waiting to be automated away. It is a control boundary the system has to preserve.
The Point Is Less Ambiguity
This may sound like a lot of machinery for a consulting website. The point is not to imitate a giant software organization. The point is to remove avoidable ambiguity:
- Which voice is speaking?
- Where is the current draft?
- Which version is public?
- What must a person review?
- What can be checked automatically?
- What could this change break?
- What constitutes permission to publish?
- How will we know the release worked?
A useful publishing system gives those questions explicit answers—and changes when the answers prove inadequate.
At this point, “I made a website” is not really what happened. I built a concrete example of content architecture, documentation systems, publishing infrastructure, automation, governance, and human judgment stitched together into something maintainable.
And, apparently, the website itself became the case study.
This is the first installment in The Website Is the Case Study, a series about the decisions, mistakes, safeguards, and small pieces of architecture behind Structured Ink’s publishing operation.
Next: One Company, Two Voices.