Somewhere around the fourth or fifth tool — I think it was the YNAB budget tracker, though it might have been the Reddit reader — I realized I was not building what I had originally set out to build.
What I had sketched earlier was an integrated personal AI system. One codebase, one database, one architecture document, one large vision. What I had actually built was a set of CLI tools that each solved a specific daily irritation: one to query my budget without opening a browser, one to capture ideas before they evaporated, one to post to LinkedIn without logging into LinkedIn. They each worked. None of them knew the others existed.
The platform I had planned — unified, orchestrated, coherent — did not exist. What I had was nine terminal commands and a growing sense that I had been building the wrong abstraction first.
The Correct Sequence
Jon Yongfook launched 7 products in 7 months in 2019. By his own account, the challenge failed: $0 in monthly recurring revenue after 7 attempts. He burned out and stopped. One of those 7 products was a tool that auto-generated social media preview images. It hit Product Hunt's front page and got lukewarm response. He set it aside, came back to it, pivoted the positioning, renamed it Bannerbear, and spent two years iterating. By 2023, it was generating $50,000 a month.
The challenge failed. The discovery it enabled succeeded.
Yongfook did not figure out what he was good at by designing a platform for it. He shipped 7 things, watched which one refused to stay buried, and then committed. The platform — Bannerbear as a product with users, infrastructure, and revenue — came after the tool that showed signal. Not before.
Daniel Vassallo left Amazon in 2019, where he had been earning roughly $500,000 a year in salary and equity. He started shipping small products. His SaaS, Userbase, made about $10,000 in its first year. His ebook, The Good Parts of AWS, made $140,000. His online course on audience-building made $150,000 in five months. He eventually sold the community platform he built around the course for $3.6 million — approximately half cash, half equity.
The product he expected to be the business was his worst performer. The products he shipped to explore what would land told him where the actual leverage was. In his case: information products built around his own experience, not SaaS. He could not have designed his way to that conclusion. He had to build his way to it.
What Small Tools Actually Measure
Each Via plugin was a test of one question: will I actually use this?
The YNAB integration was a test of whether I would check my budget more often if it was a terminal command instead of a browser tab. The answer was yes — I check it daily now, checked it weekly before. The Obsidian capture tool was a test of whether I would capture raw ideas during working sessions if the friction was low enough. The answer was yes, and the inbox it populates is the most-used part of my note-taking system. The LinkedIn poster was a test of whether I would publish more consistently if publishing was a single command. The answer is complicated: I publish more, but not proportionally more thoughtfully.
Each test cost a few days to build. Each one produced a real signal about actual usage instead of hypothetical usage. Together, they told me something I could not have known from an architecture document: which problems were real enough to solve daily, and which ones sounded useful until they ran into the actual structure of a working day.
Pieter Levels has shipped over 70 products. About 6% became profitable. He generates roughly $3 million a year from the top four. "Over 95% of everything I ever did failed," he told Lex Fridman in 2024. "Ship more."
That number — 6% — is not demoralizing if you understand what the other 94% is for. It is not waste. It is customer development you run on yourself, at a cost of days instead of months, producing real signal instead of pre-launch survey assumptions. The question is whether you can sustain the 94% in terms of time and morale, and whether you have the self-awareness to recognize signal when it shows up.
The Failure Mode
There is a counterargument I want to name directly.
An anonymous builder on Indie Hackers posted in July 2025: "I've launched 37 products in 5 years and not doing that again." The strategy, they argued, is less effective in 2025 than it was pre-2020. Every product now faces competition from people who are committed to just one thing. Spreading across many products means no one achieves the depth that a focused builder does.
This is the failure mode micro-product shipping produces when it runs without a commitment mechanism. Shipping 37 products in 5 years with no breakout is not a failure of the strategy — it is a failure of the exit condition. Levels stopped the 12-startups challenge when Nomad List showed traction and doubled down. Yongfook stopped the challenge when he burned out, but came back to the one product that had shown signal. Vassallo went deep on the products that outperformed his SaaS. All three had a moment where they stopped exploring and committed. The 37-products case suggests that moment never came — or that the criteria for signal were never defined precisely enough to act on.
The heuristic is not "ship many things." It is "ship many things, define in advance what signal looks like, and commit when you see it." Without the second and third parts, you get a perpetual launch loop instead of a discovery process.
The Coordination Layer
Via today runs 9 plugins across five domains. 175 missions executed. The orchestrator handles sequencing, memory, and cross-plugin coordination. None of that architecture was in the original sketch.
It emerged from a specific problem: the individual tools needed to share results. A research mission needed to pass findings to the content tool. A budget query needed to feed into a weekly summary. The coordination layer came into existence because the tools that needed coordination already existed and were already being used daily. The platform was the smallest possible wrapper around nine things that were already working.
The platform I had planned at the beginning was too large to build and too abstract to validate. The platform I actually built was defined by what the individual tools required of it — their shared data needs, their retry patterns, their failure modes. I could not have designed that architecture correctly in advance because I did not know which tools I would actually use, which ones would be abandoned after a week, or what the failure modes of each would look like in practice.
This is not a story about being smart. It is a story about building in the order that produces information.
Honest Limitations
The survivorship bias in the practitioner cases is significant. Levels, Vassallo, and Yongfook write about this strategy publicly because the strategy worked for them. The population of people who shipped 37 products and never found signal is not writing posts on practitioner blogs. The anonymous countercase is the only honest counterpoint in the public record, and it is a single data point without a methodology.
I also cannot tell you, cleanly, whether AI coding assistance has changed the calculus for this strategy. The evidence base for micro-product shipping — Levels 2014, Vassallo 2019–2021, Yongfook 2019 — was built before AI pair programmers existed. Via's plugins were built with Claude's help. If AI assistance has compressed per-plugin development from two weeks to three days, the optimal portfolio size and the threshold for signal are both different. I suspect they are. I do not have clean data on it. The strategy's parameters may have shifted in ways that the published practitioner playbooks do not account for.
What I can say: the platform you are willing to maintain is not the platform you design in advance. It is the platform that the small things you shipped tell you to build. I did not commit to Via as an orchestrated system until the individual tools had already proven they were worth orchestrating. That sequencing was not a strategy I chose. It was what happened when I followed the friction instead of the architecture diagram.
In retrospect, it was the only sequence that would have produced something I actually use.