I spent several weeks writing a brand operating system before writing a single line of site code.
That might sound like overthinking. It wasn’t. Here’s what it produced and why the order mattered.
The problem I was trying to avoid
If I had started with the site first, I would have defaulted to generic copy. Something like:
“We help teams scale with modern cloud infrastructure.” “Delivering enterprise-grade DevOps solutions.” “Accelerate your engineering velocity.”
That writes itself when you haven’t done the thinking. It says nothing specific about who built it or why.
I wanted Newerkey to feel like a specific person built it — because one did. That required doing the thinking before writing a line of code.
What a brand operating system is
A brand OS is a set of source-of-truth files that answer the questions you’ll keep having to answer:
- What does this company believe?
- What’s the origin of the name?
- Who is this for, and what does their actual week look like?
- What words do we always use? What do we never say?
- What should every design element do?
- What makes a post worth publishing?
These aren’t marketing documents. They’re decision rules. The goal is to encode enough context that every future decision — copy, design, content, offer — can refer back to a source of truth instead of starting from scratch.
I built mine as a set of markdown files:
brand/
├── soul.md # origin, beliefs, what we are not
├── voice.md # tone, word rules, sentence rules, platform-specific guidance
├── design.md # color palette, typography, components, diagram language
├── audience.md # ICP, pain points, fears, dream outcomes, buying triggers
├── services.md # offer definitions, pricing structure, qualification questions
├── content.md # pillars, post types, publishing rhythm, content quality test
└── logo.md # name origin, direction, usage rules
Each file is meant to be loaded into an AI session or reviewed before making a decision in that domain. They’re not static documentation — they’re working context.
What I learned by writing them in order
The order matters.
I wrote soul.md first. This forced me to answer the question I had been avoiding: what is Newerkey actually for, and where does the name come from?
Newerkey is the pronunciation of Nuerkie — my middle name. That single fact changed the design direction. Once I accepted that the name was personal before it was strategic, I stopped trying to make it sound like a DevOps consultancy and started treating it as a founder-led brand. That changed the logo direction, the voice, and the way I write content.
If I had started with the website, I would have defaulted to the generic template. Instead, I started with the question that couldn’t be copied.
The practical output
After about two weeks of writing and revising, I had:
- A clear ICP: small software teams without a dedicated platform engineer
- A specific voice: clear, systematic, grounded, calmly confident, practical
- A design system with specific color tokens, type roles, and component patterns
- Five content pillars with angles and example post titles
- Five service definitions with outcome language and qualification criteria
- Logo direction: lowercase wordmark, no key or lock metaphor
None of this is locked. The files get updated as I learn more. But now when I make a decision about copy, design, or content, I have a reference point.
The tradeoff
The obvious cost is time. Spending weeks on brand files before building the actual site means the site launches later.
The return is that when the site does launch, it’s not generic. Every piece of copy is written against a standard. Every design decision has a reference. Every service offer came from a real audience definition.
More practically: because I built the OS before the site, I can hand the files to an AI or a collaborator and get output that actually sounds like Newerkey. That’s worth a lot.
What’s next
The next step is the actual site build — Astro, Tailwind, the brand design system in code.
After that: migrating the existing posts from Hashnode with proper redirects, setting up the content workflow, and publishing consistently.
The principle behind all of it:
Build the system once. The output gets easier every time.
That’s what a brand OS is. A system you build once so you stop making the same decisions over and over.
Part of the Newerkey Build Log — documenting how I turn technical experience, systems thinking, and learning in public into a focused engineering studio.