JUL 10, 2026
Why Bbluestudios runs on the BMAD-Nova Protocol
Spec before code, always. The four-step methodology behind every build in the studio — and why the rule exists in the first place.
Every build in this studio — client work, internal ventures, a landing page, a full platform — runs through the same four steps: Brainstorm, Map, Act, Double-check. I call it the BMAD-Nova Protocol, and the short version of the rule is this: spec before code, always. No exceptions, including for me. Especially for me.
The protocol exists because I broke the rule enough times to learn what it costs.
Where it came from
I’ve been building things professionally since 2006 — 3D visualization, design systems, websites, automation platforms, and now AI-driven systems. The single most expensive pattern I’ve seen in twenty years, in my own work and in every project I’ve inherited from someone else, is the same one: someone started building before anyone agreed on what was being built.
It doesn’t feel expensive at the start. It feels fast. You open the editor, you make progress, the thing on the screen grows. The bill arrives three weeks later, when the “quick build” has absorbed four rounds of “actually, could it also…” and nobody can say what done looks like, because done was never written down.
AI made this pattern worse before it made it better. Coding agents are extraordinary executors — I run most of my production work through Claude Code and Cursor — but an executor without a spec is just a very fast way to build the wrong thing. The better the agent, the more wrong thing per hour.
The four steps
Brainstorm. Divergence first. Options on the table, including the ones that get killed in the next hour. This step is deliberately messy and deliberately short. Its only job is to make sure the decision that follows is a choice between real alternatives, not the first idea wearing a suit.
Map. The spec. Architecture, scope, locked copy, success criteria — in writing, in the repo, before a line of code exists. On a website build, the Map is a spec document plus a CLAUDE.md agent-context file that every session reads first. If a decision isn’t in the Map, it isn’t a decision yet.
Act. Execution, and this is where the AI-first part of the studio earns its name. Agents build; I direct. Each session has one scope and one role. The agent doesn’t improvise visual decisions, doesn’t rewrite locked copy, doesn’t start the next session’s work early. Velocity without chaos — but only because the Map exists.
Double-check. Nothing ships unverified. Build passes, types pass, copy is checked character-exact against the spec, the form actually lands in the CRM, the Lighthouse score is real. A system is only done when it’s proven, not when it looks done.
What the protocol actually buys
Three things, in order of value.
First, scope discipline. When the spec is written down, “could it also…” becomes a visible change to a document instead of an invisible expansion of a build. That single mechanic has saved me more unbilled hours than any tool I’ve ever purchased.
Second, agent leverage. AI agents perform dramatically better against a written spec than against a conversation. The spec is the difference between delegating and gambling.
Third, a quality floor that compounds. Every build starts from the standard the last one set, because the standard is written down. The site you’re reading this on was built in six sessions against a spec — and it inherited its entire design-system discipline from the Atenax Project build before it.
The protocol isn’t heavy. The Map for a landing page is a day of thinking. But it’s non-negotiable, because the alternative isn’t “faster” — it’s the same work, done twice, with an argument in the middle.
Spec before code. Always.
— Orlando