Most solo builders have a system. They just usually do not call it one. It hides inside their habits: what they pick up, what they finish, what they abandon, what they post about. The system is real, but it is invisible, which means it cannot be improved on purpose, and it cannot be enjoyed on purpose either.
Yonasol's system is named, and it has four steps. Each one is short. None of them are clever.
Build it. Run it. Document it. Sell it.
That is the loop. It runs on every product, every experiment, and most workflows that come out of the lab. The order matters. The fact that it is a loop, not a checklist, matters more. And the part nobody talks about: when the loop is humming, every step is genuinely fun.
Build it
Building is the easy part to romanticize and the easy part to overdo. It is also the part that pulls me to the keyboard at 5:30 in the morning before anyone else is up, so I am not going to pretend it is not the most fun step.
The rule is simple: the first build should answer one painful question. Not three. Not "what is the MVP." One question, framed sharp enough that a working prototype either confirms it or kills it.
For ReplyLead, the question was: can a small service business reply to inbound leads in under five minutes without hiring anyone? For the Chrome Extension Factory, the question was: can a repeatable discovery process surface validated extension ideas faster than browsing the store? For Open Brain, the question was: can a personal context layer make every AI tool I use noticeably better at the same time?
When the question is sharp, scope follows. You do not need a full product. You need the smallest thing that lets the question get answered honestly. That is usually less code than the founder ego wants and more decisions than the engineer brain wants, which is also why it is a satisfying puzzle to solve.
The trap in this step is starting to build before the question exists. That is how labs end up with five half-finished prototypes that all look reasonable and none of which can fail or succeed cleanly. If the question is fuzzy, the build will be fuzzy, and so will every step after it. Get the question right and the rest of the loop becomes a game worth playing.
Run it
This is the step most solo builders skip. Building is fun. Running is also fun, but in a different way: less dopamine, more truth.
Running it means putting the prototype against reality. A real lead. A real meal plan. A real seller. A real morning where the tool either earns its place in a workflow or quietly does not. Running is where most assumptions die (usually the ones you were most confident about) and where the only data that actually matters gets generated.
A few rules that have survived contact with the lab:
- Run it on yourself first. If a tool cannot earn space in the founder's own workflow, it will not earn space in anyone else's. Bonus: you get to use the thing you just built, which is one of the small joys of all of this.
- Run it on one real user, not ten imagined ones. One operator using the tool every day for two weeks is worth more than fifty signups who never log in.
- Watch the friction, not the feature requests. Where people stall, abandon, or work around the tool is the signal. What they ask for next is usually a distraction.
- Run long enough to be embarrassed. The first version is supposed to be rough. The point is not to look good. The point is to learn whether anyone needs the thing at all.
The output of this step is not a launch. It is a verdict: keep going, change the question, or shut it down. All three are acceptable answers, and there is real relief in killing something cleanly when the verdict says so. Pretending the verdict was different is the only failure mode.
Document it
Documentation is the step that turns a project into a system, and once you have done it a few times, it starts to feel like sketching in a field notebook. It is reflective, calm, and weirdly enjoyable.
Every build leaves behind something reusable: a prompt library, a build log, a teardown of what worked, a checklist of what did not, a small playbook of how the discovery happened in the first place. The discipline is to write it down before the next shiny thing pulls attention away.
This is also the step that compounds, and watching the compounding happen is one of the best parts of running the loop. The Chrome Extension Factory exists because the second extension was easier than the first, and the third was easier than the second, and at some point that pattern stopped being lucky and started being a process. The same is true of the GTM engineering work, the lab note pipeline, and the way new product ideas get scored before they earn a build slot.
What documentation looks like in practice:
- Build logs: what got built, why, and what surprised us.
- Decision memos: the call we made, the alternatives we considered, the reason we picked one.
- Recipes: a step-by-step version of a workflow that worked, written so it can be run again without rediscovering it.
- Teardowns: an honest account of an experiment that did not work, and what it taught the system.
Documentation is also the asset layer for the next step. Most of what gets sold later starts as something that was written down for ourselves first.
Sell it
Selling is broader than charging money for software, though that is part of it.
Selling means letting the work go meet other people. Sometimes that is a paid product with pricing and onboarding. Sometimes it is a free playbook that builds trust. Sometimes it is a recipe library, a workspace template, a Chrome extension, or a write-up that quietly becomes the case for a future product. The shape changes. The principle does not: the work has to leave the lab to finish the loop.
There are a few reasons this step matters more than it looks:
- Selling validates running. If running it produced a verdict, selling it pressure-tests that verdict against people who have no reason to be polite.
- Selling forces clarity. You cannot sell a fuzzy product. The act of writing the landing page, the pricing, the use cases often surfaces gaps the build skipped.
- Selling funds the next loop. Even a small amount of revenue, attention, or feedback is fuel. It tells the lab which loops to keep running and which to retire.
- Selling closes the documentation gap. Most documentation only becomes truly useful when it has to survive contact with a stranger. Selling is that contact.
There is also a quieter benefit: shipping something into the world, even at a small scale, feels great. That feeling is part of the fuel that makes the next loop possible.
Not everything that gets built earns a sell step, and that is fine. Some experiments end at run, with a verdict of "interesting, not now." The point is that sell is always on the table, and the loop is not finished until I have decided whether the work is going out into the world, getting parked, or getting killed.
Why it is a loop, not a funnel
The most important word in build, run, document, sell is the implied arrow at the end that points back to the start.
Each pass teaches the system something about what to build next. Selling produces customer signal. Documenting produces reusable assets. Running produces verdicts. Building gets faster, cheaper, and more accurate every time the loop runs, because the lab is not just shipping products. It is also shipping a better version of itself, which is honestly the most addictive part of the whole thing.
This is the part venture studios and one-shot launches usually miss. They optimize for the next launch instead of the next loop. Yonasol optimizes for the loop, and lets the launches fall out of it.
What the loop refuses to do
A few things this loop is intentionally not:
- It is not a funnel. There is no goal of pushing every idea through to sell. Most should die earlier.
- It is not an agile ceremony. No standups, no sprints, no rituals. The loop is the ritual.
- It is not infinite. Each pass has an end. A verdict gets reached. The lab moves on.
- It is not a brand. The loop is internal infrastructure. The fact that I am writing about it is a side effect, not the point.
The short version
Build the smallest version that can answer one sharp question. Run it against reality long enough to get an honest verdict. Document what was learned so the system gets better. Sell the work (as a product, a playbook, or a piece of writing) so it has to survive contact with people who do not owe it anything.
Then run the loop again, with a system that is slightly smarter than the one that ran it last time, and enjoy the fact that this is what you get to do.
That is how Yonasol builds. Everything else is decoration.
Lab Notes are field notes from inside Yonasol. They cover how products get built, how the operating system evolves, and what gets learned along the way.