The Shopkeeper's Terminal

In 2004, Tobi Lütke wanted to sell snowboards online.

The existing tools -- Yahoo Stores, the early e-commerce platforms -- were either ugly, expensive, or built for people who thought differently than he did. So he built his own store using Ruby on Rails, a framework he was learning at the time. He called the shop Snowdevil. The software he built to run it worked so well that other merchants started asking to use it.

In 2006, he launched that software as a product. He called it Shopify.

Today Shopify processes more than $200 billion in merchant sales per year. Tobi is still CEO. He still codes.

The Pattern#

This is not a rare story.

Michael Bloomberg was laid off from Salomon Brothers in 1981. He took his severance, a handful of partners, and built the software that became the Bloomberg Terminal -- the machine that would eventually make him one of the wealthiest people on earth. He wrote significant portions of it himself. When asked later why he built it rather than hiring engineers to build it, his answer was essentially: because I understood the problem.

Matt Mullenweg needed a better blogging tool in 2003. The best existing option (b2/cafelog) had been abandoned by its developer. So he forked it, extended it, and launched WordPress. It now powers more than 40% of all websites on the internet.

Stewart Butterfield was trying to build a game. His team needed a way to communicate that wasn't email. They built an internal tool for themselves. The game (Glitch) failed. The internal tool became Slack.

The pattern across all of these is not genius. It's not technical talent. It's something more specific: the person who had the problem built the solution. And because they had the problem, they understood it at a depth that made the solution useful to everyone else who had it too.

For the last thirty years, this path was closed to most business leaders.

The Gap#

Building software requires code. Code requires years to learn fluently. And so a gap opened between the people who understood what needed to be built -- founders, operators, CEOs, the problem-owners -- and the people who could build it.

The gap was managed with processes: product managers who translated business requirements into specifications, specifications into tickets, tickets into code, code into something that arrived months later and didn't quite match what was described.

This wasn't sabotage. The developers were doing their best with an incomplete map. But the map was always incomplete because language is lossy. When you say "I need a dashboard," you mean something specific. By the time that description passes through two or three layers of interpretation, what gets built is a dashboard that satisfies the specification without satisfying the need.

The founder who could code didn't have this problem. They built what they meant, not what they said.

What Claude Code Is#

Claude Code is not a chatbot with a coding plugin.

When you open it, you don't answer questions or explain yourself to a conversational interface. You describe what you want to build -- in plain language, no technical expertise required -- and it builds. It writes the code, runs the commands, handles the errors, makes architectural decisions within the constraints you set.

You remain present throughout. You decide what to accept and what to reject. You describe what's wrong when something doesn't match your intent. But the translation layer -- the gap between "here's what I need" and "here is a running program that does it" -- is now handled by the system.

This is not automation. It's collaboration at the level of the build itself.

Tobi Lütke had to learn Ruby to close that gap in 2004. A CEO opening Claude Code in 2026 doesn't. What they need instead is what Tobi had in abundance: clarity about the problem, willingness to stay present through the build, and the instinct to keep asking "is this actually what I meant?"

What Changes#

The specific first projects don't matter much. CEOs who discover they can build tend to start with the most specific annoyance: the Monday morning spreadsheet that takes two hours, the dashboard IT quoted six months to build, the internal tool that would save the team four hours a week if it existed.

These are small projects. They are also the projects that never get prioritized because they're not visible to anyone who doesn't have to do them. Claude Code handles them in an afternoon.

But efficiency is the wrong frame for what actually changes.

When you build your own tool, you understand the problem at a level you couldn't access before.

The moment you define the data model for a dashboard, you learn which metrics you actually care about versus which ones you said you cared about. The moment you design the flow for a report, you see where the real friction is. Building is a form of thinking -- one that's more honest than describing because you can't wave away a contradiction in code the way you can in a meeting.

The CEO who builds thinks differently about the company than the CEO who only delegates. Not better at everything. But differently on the problems they've built around.

The Limits#

Claude Code doesn't teach you to code. This matters, and most people skip past it.

If you use it as a pure black box -- describe problem, accept output, ship -- you will eventually ship something you don't understand. When it breaks, you won't know why. When requirements change, you'll describe again and hope the translation holds.

The right relationship with Claude Code is not passive. When it produces a solution, ask it to explain the decision it made. Not the syntax -- the logic. Why this approach? What would break it? What would change if the requirements shifted?

This is not optional. It's the difference between building and outsourcing to a different intermediary.

Tobi didn't need to become a computer scientist to build Shopify. But he understood what his code did and why. That understanding is what made the product defensible. It's what let him iterate it into something that worked for other merchants, not just for himself.

The same standard applies here.

The Permission#

Tobi Lütke had no credential authorizing him to build an e-commerce platform. There was no designation that said: you, the person with the snowboard shop, are permitted to write infrastructure software.

He had a problem and a tool and a willingness to work through the difficulty of learning something unfamiliar.

Claude Code is the first tool in the history of computing that makes the "build it yourself" option available to anyone who owns the problem -- without requiring years of technical training as the price of admission.

You already have the most important thing: the problem. You know your company's friction points more precisely than any developer ever could. You have the context, the stakes, the judgment about what matters.

The question is whether you'll stay present long enough to build something that actually solves it.

-- Ormus