Blog Details

Etienne de Bruin has been collecting stories for his upcoming book, Zero to Two, about the phase after the prototype is "done" and the real work begins. Daniel Noel shared what that transition looks like from inside the arena: TavernScribe was feature-complete, the team had proven someone would pay, and suddenly the bottleneck was no longer code.

This interview has been edited for clarity and length.

"We realized it is working, but how do we find more people like this?"

For Daniel, the gap between "it works" and "people use it" became obvious the moment TavernScribe won its first customer.

That first sale was validation, but it also exposed the next problem. The product worked. Someone saw value in it. The hard question was what came next: how do you identify the persona signature of that customer, build the right marketing systems, and pull more people like them into the product?

He describes that stage as the real valley of despair. Going from zero to one was difficult, but going from one customer to critical mass forced the team to confront a different kind of uncertainty. The challenge was no longer whether they could build. It was whether they could create repeatable demand.

"Going from 1 customer to critical mass is the valley of despair for sure."

Feature creep can feel like progress because software is cheap

Daniel is blunt about how easy it is to confuse shipping with traction, especially now that AI makes building faster and cheaper.

His team loves user feedback, and that can be both a strength and a trap. New requests arrive, the product team responds, and more ideas appear because the marginal cost of building feels low. Humans become the visible bottleneck, not software.

One major decision they made was to invest heavily in features for the game master, the hardest side of TavernScribe's network to win. That led to work on a virtual tabletop system and other free features designed to reduce friction and attract the key user in the network. Daniel still believes that logic may have been directionally right, but he also sees how easily that kind of buildout can become avoidance if the real problem is distribution, not capability.

The team has since made a deliberate shift away from adding features and toward solving marketing problems.

The legal structure mistake was really a systems mistake

Daniel calls one early decision "so dumb": creating a separate corporation for the project as a subsidiary.

At the time, the reasoning made sense. He wanted contributors to feel true ownership of the project they were helping build. He wanted people to care like founders, not just employees. But the structure created a new constraint. If profits emerge inside that entity, moving them into new ideas or adjacent business models becomes harder. Instead of flexibility, the structure encourages more R&D spending inside the same entity or a growing stack of subsidiaries.

His current view is simpler: keep one main entity and use contracts to define project-level profit sharing. In his words, it should work more like actors on a movie, where people are rewarded for contribution without fragmenting the company every time a promising idea becomes real.

Focus is now a management problem, not a tooling problem

Daniel describes day-to-day team leadership as "playing whack-a-mole" with developers who have more ideas than they can possibly finish.

That is not because the team lacks discipline. It is because AI has changed the emotional experience of building. Starting something new is fast, stimulating, and often more rewarding than grinding through the less glamorous work required to take one product all the way to market.

He has responded by separating projects across people so work can continue at independent rates, then assigning ownership and trying to move himself upstream into more of a chairman role. He prototypes, proves out the idea, sets up workflow and process, then hands execution off where possible.

The real bottleneck, as he sees it, is no longer raw creation capacity. It is how many projects a founder can care about deeply enough to push across the line.

How he decides which project gets the best hours

Daniel is simultaneously involved in TavernScribe, Automa, an AI insurance sales agent project, and an AI-first game engine that he has since handed to his brothers.

His prioritization model is pragmatic:

• Which project has the most upside?
• Which project is closest to cash flow?
• Which project currently has the strongest operational need?

Projects tied directly to revenue tend to get the best hours. TavernScribe remains strategically important because it is the live test of turning a feature-rich product into a network business. Automa matters because it helps his team manage the exploding context created by multi-project execution with AI.

That ranking is not static. It shifts as capital, momentum, and constraints change.

AI makes solutions feel finished long before humans agree

One of Daniel's clearest points is that AI lowers the cost of producing something that looks complete, but it does not eliminate the human bottleneck.

He puts it plainly:

"A solution is only a solution when a HUMAN has a problem and they feel like it is solved."

That is the distinction he keeps returning to. AI can reduce friction in prototyping, planning, and implementation. It can help teams simulate possibilities, build proofs of concept, and accelerate delivery. But none of that matters until a human uses the system, validates it, and assigns meaning to it through demand.

In other words, AI can make the path to a possible solution dramatically faster. It cannot make distribution, trust, attention, or adoption disappear.

If he could go back, he would spend less on features and more on people

Asked what advice he would give himself at the moment TavernScribe became feature-complete, Daniel's answer is immediate: underinvest in features and overinvest in a very small number of target users.

He would focus on the most critical people in the network and turn them from skeptics into fans. That means less broad platform work, more concentrated user development, and more deliberate effort to win the humans who can unlock the rest of the system.

"It would have saved me 200k LOL."

Behind the joke is a serious lesson. Past a certain point, product maturity is not the limiting factor. Human adoption is.

Building is becoming leisure

Daniel ends in a place many technical leaders will recognize immediately: AI has changed his relationship with building itself.

What used to feel like costly commitment now feels like preparation. He can simulate ideas, explore systems, and test assumptions faster than ever before. That speed changes the psychology of work. Building is no longer only execution. It is also entertainment, exploration, and reward.

Games used to be how he unwound. Now he builds them.

That shift creates a new leadership challenge. If building itself is the dopamine loop, then focus, market discipline, and commitment become even more valuable. Teams do not just need better tools. They need stronger filters for deciding which ideas deserve to survive contact with reality.

The lesson for technical leaders

Daniel's story is a sharp reminder that the post-prototype phase is not a softer version of product development. It is a different game.

The work changes from:

• shipping features to winning the right users
• proving the software works to proving the market cares
• generating ideas to protecting focus
• lowering build cost to increasing human adoption

That is the real zero-to-two transition. And for teams living through it, the hardest part is rarely writing more code.

If your team is in that phase now, LOJI helps companies move from prototype energy to production reality with the product, engineering, and execution discipline required after launch. Talk with LOJI about what comes next.