We go from the first observation to a worked-through concept, and build what it takes when an idea deserves to become real.
- 01
Explore
Before we pick a path, we dig into the problem: what it actually is, and whether it's worth solving.
- 02
Define
We look for patterns, test the assumptions and narrow down to the opportunity that holds.
- 03
Build
We design, prototype and build. Fast, focused and hands-on. And we get to break things.
- 04
Launch
When an experiment matures into a company of its own, we help it leave the lab and make it on its own.
When an experiment graduates from play to something serious (customers, revenue, outside interest), it becomes a company of its own. The lab stays lean and free to break things, while what proves out takes on a life of its own.
Four words on four cards don't say much. Here is what they mean once you are actually in the work.
The steps rarely run neatly in order. You discover during the build that the definition was wrong and have to go back, and that is intended. The point of the sequence is not to follow it slavishly, but to know which step you are in and therefore which question matters right now.
explore
We dig into the problem before choosing a direction. What actually grates, for whom, and how often? Most things stop here, and that is correct. A problem that annoys one person once a quarter is not a problem worth building away.
define
We translate the observation into a claim that could turn out to be wrong. Which assumptions does it rest on, and which of them is the most dangerous? That one gets tested first. This is where the work narrows, from a broad opportunity to a question sharp enough for a build to answer.
build
We build something that runs. Not a sketch, not a deck, but something you can use and therefore be disappointed by. It moves fast and it is allowed to break, because finding a fault in the lab is cheaper than finding it after a launch.
launch
Once something has shown that it holds, we take it out of the lab. It gets its own name, its own site and its own way forward. From that point the goal is for it to manage without us.
The simplest way to show the process is to follow something that actually went the whole way.
The observation came out of the work: technical SEO is stuck in the code. Changing a title, a meta description or the structured data usually needs a developer, a release and a moment of risk. On a site with a handful of pages that is manageable. On a site with thousands it becomes a bottleneck, and plenty of improvements never happen simply because the route out is too long.
The definition became a claim that could be wrong: what search engines read ought to be changeable without rebuilding the site. If that held, the cost was never in the change itself but in everything around it.
The build became a layer that answers at the edge, before the request reaches the server, shaping the title, the description and the structured data directly in the response. The site underneath does not have to do anything extra.
The launch came when it held. Dynamic SEO got its own name, its own site and its own company, and is in private beta today. Same four steps as the cards above, this time with a result to check them against.
A lab that keeps everything eventually becomes a layer of half-finished things nobody wants to maintain. So the spinout is built into the model rather than decided after the fact.
When an experiment moves from play to serious it becomes its own company. That separates what holds from what is still being tested: the risk stays in the lab, and the asset moves out. That is what assets up, risk down means in practice.
It also keeps the lab honest. When whatever succeeds is going to move out anyway, there is no reason to keep something alive just because it has already cost money.
Want to see the process pointed at your problem?