I work on NOVAI alone right now. No team to argue with, no senior engineer to catch the thing I can't see, no reviewer to tell me the idea I am in love with is a bad one. That absence is the real problem a solo founder has to solve, and most of the ways people try to solve it are wishful. You do not get more careful by trying harder. Trying harder is drawn from the same judgment that produced the mistake in the first place.
So instead of trusting myself, every decision runs against a framework and a criteria list I spent days building specifically for NOVAI. It is tuned to exactly this chain, what it is, what it is for, and where it has to go, and it is the first thing any idea has to survive.
The framework filters, hard
The way I work is that I write everything down. Every idea, every feature, anything I think could be useful for NOVAI, whether that is for right now or somewhere down the line. I do not filter at the point of having the idea, because that is when I am least objective, when I am excited and the thing feels obviously good. I just capture it.
Then I take that entire list and run it against the framework and criteria list. And it filters out more than 80% of it. Most of what I thought was worth building does not survive contact with the criteria. Those ideas either never get shipped at all, or get deferred to a later date when the context around them has changed. What is left is a small batch of features that actually earned their place.
From that surviving set, I organize by order. What needs to be done first, what depends on what, what can wait. That ordering is not arbitrary, it follows the roadmap and where I see NOVAI going, so a feature that passed the criteria can still sit and wait for months because nothing depends on it yet, while something far less exciting jumps the queue because three other things are blocked behind it. Then I group the near-term set into batches, and I start shipping.
Shipping a batch is never clean. It includes fixing the bugs and the unforeseen issues that always surface once real code meets real conditions. That is expected and it is fine. The plan is a direction, not a promise that nothing breaks on the way there.
Then I run the Musk algorithm over the finished batch
Once a batch is shipped, clean, running, and stable, I run a second process over it. This one is not mine. I took it from an Elon Musk interview, and online it is usually called the Musk algorithm. It is five steps, and the order matters more than the steps:
Make the requirements less dumb. Every requirement is guilty until proven innocent, and the ones that came from a smart person are the most dangerous, because those are the ones you question least. I start by attacking the spec, not the code.
Delete the part or the process. If you are not putting some of it back later, you did not delete enough.
Simplify or optimize. Only after deleting, so you are never
optimizing something that should not have existed in the first place.Accelerate cycle time. Speed it up, but only now, not before.
Automate. Last, always last.
The ordering is the whole thing. The most common mistake is to accelerate or automate a step that should have been deleted, so the wrong thing ends up running faster, and running by itself.
Here is the part that trips people up: everything in the batch already passed my framework and criteria list. So why run another pass over it? Because those two processes catch completely different failures. The framework decides what should exist. The algorithm checks how cleanly what I actually built ended up. Passing the criteria means the feature deserved to be built. It says nothing about the dead code, the leftover scaffolding, and the general trash that accumulates in a codebase while you are heads-down coding and three problems deep.
What the algorithm actually catches
This is the part worth sharing, because the abstract case for process is easy to nod at and ignore. Here is what running it over real NOVAI batches has actually surfaced.
Step one, the requirements pass, caught a constraint I had inherited from myself and never questioned. A chunk of a batch existed only to satisfy an assumption I was treating as fixed, and when I finally pressed on whether the requirement was even real, it was not. The requirement was dumb. Once I fixed that, the code underneath it did not need to exist at all, and it got deleted at step two.
Step two, deletion, catches dead code every single time. When you are alone and deep in a problem, you leave things behind without noticing, a helper function nothing calls anymore, a branch that a later change quietly made unreachable, scaffolding from an approach you abandoned three problems ago, a config path that no longer has a caller. In the moment you never see it, because you are already downstream working on the next thing. The delete step is where all of that gets swept out, before it hardens into code I am afraid to touch six months later because I no longer remember whether anything depends on it.
Step three, simplify, repeatedly caught the difference between simple and fast. I would go in wanting to make something faster, and the algorithm forced me to first ask whether it needed to exist at all. More than once the honest answer removed the need for the speedup entirely, because the fastest version of any piece of code is the one that is no longer there.
And the discipline of the whole pass, running each batch hard against itself before I build the next one on top of it, recently surfaced a real problem I would never have found from unit tests. Everything passed in isolation. The failure only appeared when the system was pushed the way it would actually be pushed under real conditions, on my own infrastructure, before it ever reached a single user. That is the process doing its job. A problem I find myself, hard and early, is a problem that never becomes an incident in front of the people I am trying to earn.
Why I actually do it
The reason is not tidiness for its own sake. It is that every batch ships on top of the last one. Before I deploy the next set of features, I want to be certain the code I am adding is landing on a strong base, not on a codebase that is full of holes and structurally weak.
If I moved on to the next season of work while the current batch was still bloated, half-simplified, and quietly carrying dead paths, I would be building the next floor on a structure that is already leaning. Every batch after that inherits the weakness, and it compounds, until one day something small tips a codebase that was one incident from collapse the whole time. So I do not advance until the batch is not just shipped but genuinely clean and stable. The chain the next batch lands on has to be solid. Running the algorithm, and refusing to move on until it is done, is how I keep that true.
Why a solo founder needs this more, not less
The reflex is that process is overhead for big teams and a solo builder should just move fast. I think that is backwards. A team has adversarial review built in, someone disagrees with you, someone reviews your change, someone asks why before it ships. Alone, you have none of that, and your own second look is not independent of your first, it is the same mind returning to the same blind spot. A framework I built and an algorithm I borrowed are the substitute for the review I do not have. They are how I argue with myself using something that is not me. For a chain that is supposed to settle value between autonomous agents, that discipline is not optional.
The cost, honestly
This is slower up front, and the hardest part is not building the framework, it is obeying it. The real discipline is refusing to move to the next batch while the current one still needs cleaning, when every instinct is screaming to go build the next exciting thing. Deleting work you already half-built, because it did not survive a question, feels like waste in the moment and it is not. Most of what this saves is invisible, the incidents that never happened and the code I never had to maintain. You have to trust the invisible savings are real, and that trust is the price. Alone, I would still run it exactly this way. The process is not bureaucracy. It is the closest thing I have to a second set of eyes.
One more thing: I am looking for a technical co-founder
I want a technical co-founder for NOVAI, someone who shares the vision of NOVAI and wants to own a real part of it long term.
If you have experience with AI, blockchain, Rust, distributed systems, consensus, or anything adjacent, go read the codebase: github.com/0x-devc/NOVAI-node. The code is the pitch.
If you are still interested after that, reach out, on X at https://x.com/NOVAInetwork or at NOVAInetwork@protonmail.com.