Sixteen minutes. A hundred and two files. Sixty-five thousand lines of code, and about $50 in CEO.ai credits. That's the headline number, and it's the part people want to talk about.
It's also the least interesting thing that happened that afternoon.
I've been telling the story of TrabajoEmiratos.com, a platform that connects Latin American workers with UAE employers. Yesterday I walked through the strategic groundwork: the ICP research, the North Star Metric, the mission, the positioning. Fifty artifacts by the time it was done.
Here's the thing I hadn't expected. Those 50 artifacts didn't end up parked in a slide deck nobody opens. They got eaten by the architecture plan. They flowed into how every task got assigned, and into how every task got delivered.
The comment that stopped me
After the build finished I did what I always do. I opened the codebase and started reading. Not the functions first - the comments. And these weren't the usual "this function returns a list" filler.
This was sitting at the top of one file:
/**
* Empleos — End-user (Spanish) jobs page.
* Stage 'Postula' in "El Camino". Lets the user
* search and filter partner-verified job matches,
* view details, and express interest. All salary
* figures render as honest ranges with visible
* disclaimers. No fabricated applicant counts,
* no guarantees, no worker-side upfront fees.
*/And on another file:
/**
* Guías (Learn) page — end-user facing, Spanish-first.
* Belongs to the "Aprende" stage of El Camino.
* Lets the user browse honest migration/work guides,
* filter by category (scams / culture / legal /
* english / costs) and search free text.
*/I sat there for a second. The code knew who it was for. It knew why it existed. It even knew the guardrails - no fake applicant counts, no worker-side fees - because those weren't afterthoughts I'd remember to enforce later. They were part of the positioning, and the positioning was part of the build order.
No developer read a brief and interpreted it into that comment. The strategy was baked into the build instructions at every level, so it showed up in the source.
The insight
Most codebases lose the "why" within a week of shipping. The reasoning lived in someone's head, or a Notion doc, or a meeting nobody recorded. When strategy is written as the build spec, the "why" gets stored where you can't lose it: right next to the code that acts on it.
Why this matters past the party trick
Fine, self-documenting code is neat. So what?
Two things, and they're the two that usually break a young product.
Maintainability. Come back to this codebase in six months. Or hand it to someone who's never seen it. Every component tells you its reason for existing. You're not reverse-engineering intent out of variable names and guesswork. The intent is documented at the source, in plain language, tied to the stage of the user's path it belongs to.
Scalability decisions get cheaper. When you're deciding what to add or cut, you already have a filter wired into the architecture. Does this serve the ICP? Does it move the North Star Metric? You don't have to reconvene a strategy session to answer that. The answer is in the comment.
- New feature request lands. You read the file header, check it against the ICP, and know in ten seconds whether it belongs.
- A contractor picks up the repo cold and ships the right thing, because the guardrails are written where they'll read them.
- The trust rules - no fabricated numbers, no upfront worker fees - can't quietly slip out during a refactor, because they're stated in the code, not the roadmap.
The translation layer is gone
I've built software for years. I've also written strategy decks for years. They were always two separate jobs, done by two separate people, at two separate times, stitched together by meetings and Slack threads and a fair amount of hope.
The person who understands the customer writes a document. The person writing the function reads it, or skims it, or forgets it exists by sprint three. Every handoff loses a little signal. That's the game of telephone every product team plays and pretends not to.
What I watched here was different. Strategy became architecture became code in one continuous flow. Nobody translated anything.
"The salary disclaimer wasn't a ticket I filed later. It was a positioning decision that became a build rule that became a line of code. Same idea, three forms, zero drift." — Greg Marlin, building TrabajoEmiratos.com
The numbers below get quoted a lot. Read them the other way around, though. The build was cheap and fast because the thinking upstream was done and structured well enough for the machine to act on it directly.
Fifty artifacts in. A hundred and two files out. Sixteen minutes of build time. But the days I spent defining strategy first? That's what made those sixteen minutes mean anything at all.
Key takeaways
Fast builds aren't the win. A clear, structured strategy upstream is what makes a fast build worth trusting.
When strategy is written as the build spec, it ends up in the code as documented intent - not lost in a deck.
Self-explaining code cuts maintenance cost. Anyone opening the repo later reads the "why," not just the "what."
Scaling gets easier when the ICP and North Star filter is embedded in the architecture. You test new work against it instantly.
Removing the strategy-to-engineering handoff removes the signal loss. Same idea travels from positioning to code without drift.
Want Your Strategy to Show Up in the Code?
Describe the product and who it's for. CEO.ai turns your positioning, ICP, and metrics into an architecture plan, then builds it - with the reasoning written into the source.
Greg builds real products in the open to test what CEO.ai can actually do. He's spent years on both sides of the wall - shipping software and writing strategy - and is mildly obsessed with what happens when you stop treating them as separate jobs.
