“The website is beautiful. The images are great, the words all sound professional, but there’s something about it that just... it’s not Kustomcabs.”
Joe runs Kustomcabs, a custom cabinetry shop, and I had just built him a marketing site. By every visible measure it was good work: clean, well photographed, professionally written. Nothing on it was wrong. That was the problem. Marketing language had taken the place of his voice, and he could feel the substitution without being able to point at it.
I kept turning that over for months, because two ordinary things were happening at once. A founder who keeps the brand in their own head becomes the bottleneck every message has to pass through, which stops working the moment the company grows past them. And the moment they hand messaging to a marketing team, an agency, or a model, each one reinterprets it, and each reinterpretation moves the brand a little.
Brand guidelines were supposed to solve this. Guidelines describe a brand; they don’t enforce it. The standard ends up in a PDF nobody opens, or in the founder’s head, which is worse. FounderLock is the attempt at the other thing: a system that holds the founder’s standard as an artifact and judges content against it.
Compiling the rules instead of prompting them
The obvious build was an AI writing assistant with the brand rules stuffed into the system prompt. I rejected that early, and everything else in the product follows from it.
The requirement driving the whole thing is that the rules stay exact: written down once, compiled, versioned, and applied as written, so a verdict can be traced to the rule that produced it. Rules living inside a prompt cannot give you that. The logic is hidden, the behavior shifts with every model update, and there is no way to audit why a piece passed or failed. For a product whose entire value is consistency, that is disqualifying.
So founder intent gets compiled into a structured artifact, the FounderLockfile. What the founder edits and what the evaluator reads are two different things. Founder Encoding stays editable and human; compiling it produces a versioned, hash-stable file, and the evaluator reads only that file. Nothing scores content against the raw input, so a verdict points back at compiled rules instead of at loose prose in a prompt.
It also settled what the product is. The things a company genuinely cannot afford to get wrong end up behind something that sits in the path and refuses to be skipped: CI blocks a bad merge, access control blocks a bad request. Brand identity gets protected by hoping the right person reviews the right thing at the right time. I wanted it in the first category.
Asking founders what they believe didn’t work
The first onboarding asked founders to describe their brand. What do you stand for, how should you sound, what should you never say. It failed, and understanding why was the deepest design work in the project. I was solo on this, the designer and the engineer and the founder, so my own taste was the only design authority in the room and there was nobody to tell me the model was wrong.
Declarative capture assumes a founder can introspect and verbalize brand judgment on demand. They can’t. They have the judgment but not the terminology, so they cannot name what they already know. They omit the rules that are so obvious to them the rules never surface as rules. And what anyone says about their brand in the abstract is vaguer than how they decide when a specific sentence is sitting in front of them.
The fix was to stop asking what a founder believes and start watching how their brand behaves. Instead of “describe your voice,” FounderLock puts real content in front of them and asks them to mark it on-brand or off-brand. A founder who flags “your cabinets will transform your kitchen, book now before prices go up” as wrong has drawn a governance-relevant boundary, and drew it without needing the phrase “urgency framing.”
The cognitive task collapses from four steps to one. No introspecting, finding vocabulary, generalizing, then articulating. Just the question they are expert at: does this fit?
I should have started here. The premise of the entire product is that brand judgment is tacit, and the first onboarding I designed asked people to make it explicit on command. Where the user knows more than they can say, I now reach for observation first.
The compiler was wrecking what it collected
The hardest problem was not a feature. It was a class of bug that got subtler each time I fixed it.
The onboarding-to-compile pipeline was damaging data on the way through. An early run lost seven fields outright, which at least announced itself. The next run was worse for being quieter: roughly eight fields carried damage all the way into the compiled lockfile, every field present, the corruption visible only on close reading. A naive text splitter was shredding prose into fragments. “Montana, Wyoming, Idaho, and Texas” came out as three items with Idaho gone. A phrase like “rejection constraint: heritage” compiled into a confident, weighted, load-bearing rule that meant nothing.
That is the one failure the product cannot survive. It claims to hold a founder’s standard exactly. What it was doing instead was inventing plausible standards on their behalf and then enforcing them.
The fixes were unglamorous: tighten the splitters to break only on real paragraph boundaries, and upgrade the onboarding model to address the silent drop at its root. The durable lesson was about failure modes. A pipeline that drops data loudly costs you an afternoon. One that drops data quietly and keeps going will go on handing users corrupted rules with full confidence until somebody happens to read closely enough to catch it.
A related audit turned up rejection and credibility constraints that were being stored but never compiled into the rules the evaluator runs, so an entire governance gate was silently not firing. That was the largest launch-day risk I found, and it was fixed before v1.
What a block has to say for itself
Content cannot go around evaluation. The order is fixed: input, generation, evaluation, alignment score, approval. Drifting content is flagged and content under threshold is blocked. The authority of the product rests entirely on that path being unskippable, so I made skipping it structurally impossible rather than a setting someone could turn off.
The design risk in that is obvious. A system that blocks your work can feel punishing, and a “Blocked” verdict that gives no account of itself is just being failed by a machine.
A block the founder cannot understand is a defect.
I held the product to that literally. When a scoring bug let content fall from a perfect dimension profile to a 0.64 verdict, I filed it as a bug on the grounds that a founder reading that page could not reconstruct how the number got there.
So every verdict, and especially a block, returns the signals it detected, the specific violations, the openings to fix them, a six-dimension breakdown of the score, and a suggested rewrite. The number exists so the system can enforce a threshold. The reasoning is what the founder reads.
One mechanism makes the philosophy concrete. A lockfile can express orthographic prohibitions, banned words or em dashes, and those act as deterministic floors: a single banned construct hard-caps the score however good the rest of the copy is. The floor only fires when the lockfile itself expresses the rule, so it stays portable across brands instead of being hardcoded into the engine.
The honest boundary runs right there. The floors, the dimension weights, and the verdict thresholds are code, and they return the same answer every run. The dimension scores themselves come from a model running at low but nonzero randomness, so which violations get flagged can vary from one run to the next. The judge drifts; the floor does not. What compiling buys is that the rules being applied are exact, versioned, and inspectable. A governance product that claimed more than that would fail its own check.
What the personas broke
Before launch I built detailed user personas in a simulated-persona tool and ran the product’s core assumptions at them. These were constructed personas, not customer interviews, and I treated what they produced as hypotheses to attack rather than as validation.
Built hostile, they found a strategy problem I had missed. There is a difference between phrase-level alignment and worldview-level alignment, and only one of the two is delegable. Catching a banned phrase is a typo check and nobody minds handing it off. Catching a worldview violation is the thing a founder is personally paid for, and giving that to a system is a different act. The product had been treating both as one feature.
That exposed a tension I have not resolved. For a worldview-level catch, the rule and the post that violates it can arrive as the same act, which cuts against the premise that governance amendments get proposed separately from content. I wrote it up as an open question with a path forward rather than papering over it.
There is a second one I deferred on purpose and deferred too long. Encoding a founder’s specific rejections into the lockfile makes governance sharper, but done naively it means two brands with identical standards can compile to different lockfiles, which breaks the property that the same standard always compiles to the same artifact. Postponing the problem also postponed clarity on what FounderLock fundamentally is.
What governing my own site found
v1 shipped with founder encoding through reactive scenarios, a compiled lockfile, six-dimension scoring with code-enforced floors and thresholds, explainable verdicts, and a console that audited content and tracked brand integrity across channels. The design ran to five phases, ending in a multi-brand operating system. Two of the five got built.
The most useful testing was dogfooding. FounderLock governed its own marketing site and social content, which surfaced things I could not have predicted. The one I keep coming back to: a sentence flipped from reading human to reading machine-generated on the difference between “is not” and “isn’t.” One character, no change in meaning.
That is not a rule I would have thought to write down, and it is not one Joe could have handed me about his own site. Rules at that grain surface when someone reacts to an actual sentence, which is why the encoding was built out of reactions in both directions: what a founder keeps as much as what they throw out.