One person runs two dozen products by making the marginal cost of the next product almost nothing. The first version of the memory layer, the ops layer, the audit tooling and the accounting automation is expensive; the second product to use them is nearly free. What does not scale is judgement, which product deserves to exist, what to cut, what "good" means, and that becomes the binding constraint instead of hours.
Ross Jones, Founder, The Hopium Lab. Last modified 22 July 2026.
Twenty-four products across fifteen sectors, no team, no funding. This is the mechanism, including the parts that do not work.
Why does the usual model scale with headcount?
The default way to build more is to hire more, because in a conventional shop the unit of production is a person's week.
Each product gets a pod, engineers, a product manager, someone on marketing, and output scales roughly with how many people you can recruit, manage and afford. It is not a wrong model. It is a slow, expensive one, and it has a hidden tax: past some size, a growing share of your day goes to running the organisation rather than doing the work. The org becomes a product you also have to maintain.
There is a second tax nobody prices in. Every product added to a portfolio adds coordination surface, releases to align, decisions to socialise, context to transfer. Ten products with ten pods is not ten times one product. It is considerably worse.
What replaces the team?
Infrastructure replaces the team, in five specific pieces that each remove a category of recurring work.
| Layer | What it removes | Why it compounds |
|---|---|---|
| skyMem, memory and cognition | Re-establishing context every session | Every product inherits the same memory substrate |
| Sky, ops, reachable from WhatsApp | The daily admin loop | The interface is a phone, so it works from anywhere |
| Night Sky, autonomous revenue | Scouting, qualifying, chasing | Runs while nothing else is running |
| Diablo, production-readiness auditing | Manual pre-ship review across 17 categories | One taxonomy, applied identically to everything |
| Entixx, multi-entity accounting | Bookkeeping across a group structure | Adding an entity is configuration, not a new process |
None of these is a product. All of them are leverage, and the distinction matters: a product earns money, leverage reduces what the next product costs to make.
A new product does not need a team. It needs the infrastructure to already exist, and the second product to use it costs a fraction of the first.
What is the actual cost curve?
The cost curve is steep once and then nearly flat, which is the entire argument.
Building the audit tooling took months and it now runs against everything with no additional effort. The memory layer was the hardest single piece of engineering here and it is now a dependency, not a project. The developer-tools line, deploy monitoring, domain management, LLM cost control, revenue aggregation, exists because each one was a Tuesday annoyance that the existing infrastructure made cheap enough to just fix.
The honest version of the numbers: the first product carrying a new capability costs what it costs. The second product reusing that capability is a configuration exercise. That ratio, not personal productivity, is what the portfolio is built on. Anyone claiming a person can do the work of twenty people is describing a different, less believable thing.
Where does the constraint move to?
The constraint moves from capacity to judgement, and judgement is the one you want to be limited by.
With a team, you are limited by hours and coordination. Solo with infrastructure, you are limited by decisions: what is worth building, what to kill, what "finished" means, which of two plausible architectures is the one you will not regret. Those do not delegate and they do not parallelise, but unlike headcount, they compound. Every decision made well makes the next one cheaper, because you have seen the shape before.
Fifteen sectors is the payoff. Patterns that are invisible inside one industry are obvious when the same architectural decision recurs in pharma logistics, aviation certification and hotel revenue in the same year.
Capacity is a constraint you solve by spending money. Judgement is a constraint you solve by having been wrong before, in public, on something that mattered.
What actually breaks?
Four things break, and pretending otherwise would make the rest of this untrustworthy.
Support surface accumulates and never leaves. Twenty-four shipped products is twenty-four things that can break at 3am, and no amount of leverage removes the obligation. This is the single largest hidden cost and it grows monotonically.
Depth per product is capped. A product with a dedicated team of eight will out-feature a product that gets a fraction of one person. Anywhere the market rewards feature velocity above all else, this model loses, and it loses badly.
Concentration risk is real. One person is one illness, one bad month, one bus. Every mitigation, documentation, escrow, runbooks, replayable state, reduces the consequence without touching the probability.
Selection gets harder, not easier. When building is cheap, the discipline of not building becomes the scarce skill. A portfolio can quietly fill with things that were interesting to make and that nobody needed, and the cost of that is invisible until you look at what each one earns.
When is this the wrong model?
This is the wrong model whenever the work needs sustained depth in one place rather than breadth across many.
If a single product can absorb everything you have and still reward more, a frontier research problem, a platform in a land-grab, anything where being second is fatal, hire a team and concentrate. The portfolio model optimises for surviving many small bets, not for winning one large one.
It is also wrong where the buyer requires organisational scale as a proxy for safety. Some procurement processes are structurally unable to approve a single-person supplier regardless of the work, and the correct response is to fix the supplier evidence, insurance, escrow, continuity, references, not to argue that the model is fine.
How would you start?
Build the leverage before you need it, and let the second product prove it.
BUILDING FOR PORTFOLIO LEVERAGE
The Hopium Lab · v1.0 · 22 July 2026 · take it, fork it, argue with it
BEFORE THE SECOND PRODUCT
[ ] What did you do twice while building the first? That is the first candidate
[ ] Can it be extracted without a rewrite? If not, it is not leverage yet
[ ] Does it work unattended, or does it need you present to be useful?
THE TEST FOR EVERY NEW CAPABILITY
[ ] Will a future product use this, or is it specific to this one?
[ ] Does it reduce recurring work, or only one-off work?
[ ] Can it fail quietly? Anything silent gets found during an incident
BEFORE ADDING PRODUCT N+1
[ ] What is the support cost of the twenty-four you already have?
[ ] What are you killing to make room? "Nothing" is the wrong answer
[ ] Is this a real problem, or was it just cheap to build?
THE HONEST CHECK: if your infrastructure disappeared tomorrow, how many of
your products could you still run? That number is your actual capacity.
The last question is the one worth sitting with. Leverage that only you can operate is not leverage, it is a dependency you happen to like, and it fails the same way a key person fails.
Ross Jones, Founder, The Hopium Lab. Last modified 22 July 2026.