Many small products, and whether that is a strategy
Exploration is only worth doing if something gets exploited
Thesis
I want to make the case for a strategy I have followed, and then be honest about the condition under which it fails, because I have failed that condition.
Building many small products in sequence, rather than one product over years, is a defensible approach. It is not dilettantism and it is not indecision. It is a search procedure, and search is the correct response to genuine uncertainty about where value is.
But it is only a strategy if two things are true. Each build has to actually reduce uncertainty, which means it needs a question and an audience rather than just a repository. And the search has to terminate in a commitment, which means at some point you stop sampling and pick.
Exploration without exploitation is not a portfolio. It is a hobby with good version control. That is the failure mode, it is extremely comfortable, and it is the one I fell into.
Context
There is a real position here that deserves better than the caricature it usually gets.
The single-product argument says depth wins: you cannot understand a domain in a month, compounding requires continuity, and every great product took years of narrow attention. All true.
The many-products argument says the expensive risk is not shallow execution, it is a well-executed answer to a question nobody asked. Startup outcomes are famously skewed, with a small number of large winners carrying everything, which means the number of distinct attempts matters. If you do not know where the value is, spending three years finding out through one attempt is an expensive way to sample once.
Both are right about different periods. The disagreement is really about when you are entitled to focus, and the honest answer is that you are entitled to focus when you have information, and the many-products approach is a way of buying that information.
Research
March, 1991, "Exploration and Exploitation in Organizational Learning". The foundational treatment, and it is worth reading rather than summarising because the summary loses the sharp part.
March's characterisation: returns from exploration are variable, distant in time, and often negative, while returns from exploitation are proximate, predictable and positive. Organisations therefore drift toward exploitation, because the feedback is faster and clearer. That is the well-known half.
The less-quoted half is the mirror failure, and it is the one relevant here. Systems that explore too much "exhibit too many undeveloped new ideas and too little distinctive competence". They pay all the costs of experimentation and capture none of the returns, because capture requires the sustained, unglamorous work that exploration keeps interrupting.
That sentence describes a seventeen-repository GitHub account with two packaged projects better than anything else I have read.
The secretary problem, and optimal stopping generally. In the classic formulation you see candidates one at a time, cannot return to a rejected one, and want to maximise the chance of choosing the best. The optimal policy is to observe roughly the first thirty-seven percent without choosing, then take the next candidate better than everything seen so far.
I am using this as an analogy, not a calculation, and the assumptions do not hold cleanly: you can return to a shelved project, and quality is not a fixed ranking. What transfers is the shape of the policy. Sample a bounded number, then commit to the next thing that beats what you have seen. Both halves are load-bearing, and the many-products approach usually implements only the first.
Markowitz, 1952, on portfolio selection. The reason to hold several assets rather than one is variance reduction, and it works only to the extent that returns are uncorrelated. Perfectly correlated assets give you a single asset in several wrappers.
Now apply the condition to a solo builder's portfolio. Same builder, same taste, same technical choices, same distribution channels, same audience, same blind spots. The correlation between those products is high. Which means the diversification benefit is much smaller than the count suggests: you are not holding twelve independent bets, you are holding one bet on your own judgement, expressed twelve times.
I find this the strongest argument against the strategy, and it is stronger than the usual focus argument, because it does not appeal to virtue. It is just a condition that is not met.
Ocasio, 1997, on the attention-based view of the firm. Ocasio's argument is that the binding constraint on organisational action is the allocation of attention rather than of capital. For a solo builder this is not a metaphor. Attention is the only input, and unlike capital it cannot be borrowed or saved.
Rubinstein, Meyer and Evans, 2001, on task switching. Measured costs to executive control when switching between tasks, with the cost rising with task complexity and unfamiliarity. Product contexts are about as complex and unfamiliar as tasks get. The switching cost between projects is real, it is not recovered by enthusiasm, and it is invisible in a repository list.
Argument
A build is only an experiment if it has a question, an audience and a kill rule.
Otherwise it is an artifact. Artifacts are not worthless: they demonstrate range, they teach implementation, they can be picked up later. But they do not reduce uncertainty about where value is, which is the entire justification for building many of them.
The question does not need to be sophisticated. "Will anyone reply to a cold message about this" is a question. What it cannot be is "does this work", because you already know you can build it.
The audience has to be a person, not a segment. And the kill rule has to be written before you start, because after you build something you will find reasons.
Correlated bets do not diversify, so buy diversity deliberately.
If your products all sit in one taste and one channel, add variance where it is cheap. Different buyer types, since consumer and business products fail differently. Different distribution mechanisms, since a search-acquired product and a community-acquired product teach different things. Different problem sources, meaning some ideas from your own irritation and some from watching a domain you are not part of.
The last one matters most and is hardest. Products drawn entirely from your own experience are maximally correlated with each other, because they share a single source of hypotheses.
Sample, then stop. The stopping is the whole strategy.
Decide in advance how long the exploration period runs. Six months, or twelve builds, or whatever fits your circumstances. When it ends, pick the best thing you found and give it a period long enough to matter, meaning a year rather than a fortnight.
Without a declared end the strategy has no stopping condition, and a search with no stopping condition never returns a result. It just keeps searching, and every new build feels like progress, and March's undeveloped-ideas failure arrives without ever announcing itself.
Recurrence is the signal the strategy exists to produce, and it is genuinely hard to get another way.
This is the strongest thing I can say for the approach, and it comes out of my own record rather than the literature.
Looking back at what I built over five months, the clusters are visible. Creator economy tooling appeared three separate times: a reverse influencer discovery product in March, a conversion-focused link-in-bio builder in May, and an influencer co-pilot in June. Nobody asked for any of them, they were built at three-week to eight-week intervals, and I did not notice the pattern until I listed the repositories by date.
Returning to a problem space unprompted, more than once, after having moved on, is a strong signal. It is different from finding a space interesting, because interest does not survive a gap. And you cannot get this signal by introspection, because introspection is exactly what produced the belief that each build was a new idea. You get it by having a dated record and reading it.
That is a real return on exploration, and it argues for the strategy. It also argues for a specific stopping rule: the second unprompted return to a problem space is the signal to stop exploring it and commit. Not the third. I got three, which is one more than I needed.
The costs are in attention and liability, not in build time.
Build time is what the strategy appears to cost and it is the cheapest part. The real costs are switching, which is measured and nontrivial, and accumulated surface: every deployed thing has dependencies, a security posture, and eventually a person emailing about it.
Which suggests a specific discipline that costs nothing. Keep the repositories, retire the deployments. The artifact carries almost all of the signal, and the running instance carries almost all of the cost.
Examples
Twelve tiny products in twelve months, no distribution attempted. Not a strategy. Twelve artifacts, no learning about demand, and twelve times the switching cost. This is the common version and it is what March described.
Four products in twelve months, each shown to twenty people, three killed on schedule. A strategy. Uncertainty falls with each one, the kill discipline is real, and the survivor has evidence behind it rather than affection.
A cluster of three products in one space, built months apart without planning it. The most valuable output of the approach, and the point at which exploration in that space should end. The cluster has told you where your attention actually goes, which is information about you rather than about the market, and it is the harder of the two to obtain.
One product for three years, in a domain the builder worked in for a decade. Frequently the best choice, and no part of this argument disputes it. Prior knowledge substitutes for search. If you already have the information, buying it again is waste.
Counterargument
"Focus is how everything good was built. A portfolio of prototypes is a way to avoid the hard part, which is staying with one problem after it stops being interesting."
The strong version of this is difficult to answer and I do not think I fully can. Compounding requires continuity: users, domain understanding, reputation and distribution all grow with time in one place and reset with each switch. The hard, valuable phase of a product begins after the interesting phase ends, at roughly the moment a serial builder starts a new repository. Selecting for novelty means systematically avoiding exactly the work that produces outcomes.
There is a sharper inversion of my Markowitz point, and it is a good objection. If a solo builder's products are correlated through their own taste, that correlation is the asset. A distinctive point of view expressed across several products compounds into something recognisable, which is how small studios build audiences. Treating correlation as a flaw imports a framework built for financial assets, where the goal is variance reduction, into a domain where the goal is a distinctive position. Under that reading, correlation is not a bug in the portfolio, it is the portfolio.
Where this is right. The continuity point is straightforwardly correct, and it identifies the actual failure in my own record: not that I explored, but that I never exploited. Seventeen builds with two packaged is the outcome the objection predicts, and it predicted it accurately.
The correlation inversion is also partly right, and it changes the recommendation rather than defeating it. Correlation through taste is an asset for building an audience and a liability for finding a market. If you are running a studio with a recognisable point of view, lean into it. If you are searching for demand, it is a hidden concentration you should price.
Where I think it is wrong. The objection assumes you know which problem to stay with. Focus applied to the wrong problem is the most expensive mistake available to a founder, and it is expensive precisely because focus makes it invisible for years. Search is how you earn the right to focus, and the argument for search is strongest exactly where the objection is weakest: the case of someone with no domain background and no evidence.
And the caricature is worth rejecting. Structured search with kill rules and a stopping date is not avoidance. Unstructured accumulation is, and the two look identical from outside, which is why the objection keeps landing on the wrong people.
Practical implications
Write the question before the repository. One sentence, and it cannot be about whether you can build it.
Name the person you will show it to. Not a segment. If you cannot name one, that is the finding, and it costs nothing to learn now.
Write the kill rule before you start. No user contact in two weeks, it gets archived. Decide once, apply mechanically.
Declare a stopping date for the exploration period, and put the commitment in the calendar. A search with no end never returns anything.
Buy uncorrelated variance where it is cheap. Different buyers, different channels, and at least one idea sourced from a domain you are not part of.
List your builds by date every quarter and look for clusters. This is the highest-value hour in the whole practice and it requires nothing but a table.
Treat the second unprompted return to a problem space as a decision point. Commit or leave, and do not take a third pass.
Keep repositories, retire deployments. Signal without maintenance surface.
Count switching as a cost. It is measured, it is real, and it does not appear anywhere in a plan that lists only build estimates.
My perspective
Opinion, and the record is public.
Seventeen repositories between February and June 2026. Two packaged into anything a stranger could assess. That ratio is the clearest available statement of what I got right and wrong: the exploration ran well and the exploitation never started.
What the exploration produced that I could not have obtained otherwise is the cluster analysis. Three separate returns to creator economy tooling, unplanned, across four months. Two returns to page and template infrastructure. That is real information about where my attention goes, and I only have it because the dates are public and I eventually read them.
What it cost me is harder to see and larger. Five months of switching, no user contact on almost any of it, and a set of artifacts that a reader cannot rank because six of them have no description. The undeveloped-ideas failure March described in 1991, arriving on time.
The rule I would give myself in February: build as many as you like, and the second time you come back to a problem space without being asked, that space is the choice. Stop sampling and spend the next year there. The signal arrives early. I received it in May and kept exploring until the end of June, which is not a research method, it is just enjoying the part that is fun.
Conclusion
Many small products is a search strategy, and search is the right response to not knowing where value is. It produces one thing that focus cannot: an honest record of where your attention returns when nobody is directing it.
It fails on two conditions that are easy to miss. The bets are far more correlated than the count implies, because they all run through one person's judgement. And search without a stopping rule never terminates in a commitment, which converts a strategy into an accumulation.
So run it deliberately. Question, audience, kill rule, stopping date. And when a problem space pulls you back a second time, treat that as the answer the search was for, and go and do the unglamorous part.
Sources
- J. G. March, "Exploration and Exploitation in Organizational Learning", Organization Science 2(1), 1991, 71–87.
- H. Markowitz, "Portfolio Selection", Journal of Finance 7(1), 1952, 77–91.
- T. S. Ferguson, "Who Solved the Secretary Problem?", Statistical Science 4(3), 1989, 282–289.
- W. Ocasio, "Towards an Attention-Based View of the Firm", Strategic Management Journal 18(S1), 1997, 187–206.
- J. S. Rubinstein, D. E. Meyer and J. E. Evans, "Executive Control of Cognitive Processes in Task Switching", Journal of Experimental Psychology: Human Perception and Performance 27(4), 2001, 763–797.
- github.com/TheDevChopra, repository dates used for the cluster analysis:
Inflio27 March 2026,tapbio4 May 2026,creatoros29 June 2026. Recorded as A8, A12 and A19 inSOURCE_INVENTORY.md. https://github.com/TheDevChopra
Related reading in this archive
- The Build Archive: the dated repository table and the cluster analysis
- Inflio, tapbio and CreatorOS: the three-visit cluster treated as one investigation
- Shipping MVPs with AI coding tools
- What seventeen products in five months actually taught me