A needs-and-offers network is worthless until it is dense
An OG indie hacker building tools that make you happy
Octavian named Intersect's real constraint without flinching: it is not a missing feature, it is a missing crowd. An intent graph only surfaces a useful intersection when enough people have added enough cards, so with a handful of users the cleverest matching engine finds almost nothing. This is the cold-start tax every marketplace and matching product pays, invisible in a seeded demo and brutal in the wild. The takeaway for anyone building two-sided or network-effect software is that the first job is density, not polish: seed the graph yourself, recruit the first cohort by hand, and only judge the product once it is full enough to fire. Until it is dense, the thing you are testing is not your algorithm, it is your ability to fill it.
Related advice
Turn fuzzy intent into structured cards a machine can match
A conversation about what everyone is building evaporates the moment the room empties out. Intersect keeps it by asking each person to file their intent as typed cards: what they are working on, what they need, what they can offer, what they are questioning, what they are thinking about, and what they have discovered. Once intent has a fixed shape instead of being buried in chat, software can do the introductions a busy human never gets to: cluster the projects, find the topics two people share, and pair a need on one side with an offer on the other. The general lesson is that matching people is only hard while the inputs are unstructured prose, so give the same information a small, fixed schema and the overlaps compute themselves. The next time you reach for a feed, ask instead what the handful of card types are, because typed intent is the thing a machine can actually act on.
Be prolific, because a large body of small tools compounds
Octavian has shipped more than two hundred projects, most of them small tools, since before anyone in Romania called this indie hacking. That volume is not noise, it is the strategy. Every finished tool sharpens your taste, widens the surface area where luck can land, and leaves behind an audience and a reputation that a single big bet never accumulates. Indie hackers tend to over-invest in one idea and agonize over whether it is the one, while the prolific builder simply ships the next thing and lets the portfolio do the arguing. You cannot predict which small tool finds its people, so the rational move is to keep the cadence high and let quantity manufacture both the quality and the lucky breaks. Longevity in this game looks less like one masterpiece and more like a long, unbroken streak of finished things.
Store generated content in the user's browser, not on your servers
Every minute of audio Naramine generates is cached in IndexedDB on the listener's own machine, sometimes tens or hundreds of megabytes of it, with a clear-data control and a download option for the user. Andrei's servers never store the stories or the audio derived from them, and that decision does double duty. Economically, his storage bill is zero and stays zero as usage grows, which matters enormously for a solo founder with an 80 percent margin target. Legally, it keeps him a tool rather than a distributor: a service that hosts copies of authors' copyrighted stories, or audio derived from them, has built a library it must defend, while audio generated on demand and held only on the reader's device looks like the reader's own personal-use copy. When your product transforms content you do not own, ask where the transformed bytes live, because that answer decides both your infrastructure costs and which side of a copyright argument you are standing on.
Run the free tier on the user's hardware and sell the GPU as the upgrade
Naramine's Basic tier is the same open source engine as Premium, Kokoro, but executed as Kokoro JS in the listener's own browser, so every free user brings their own compute and Andrei's marginal cost for the entire free tier is zero. The limits of local execution, roughly 1.3x listening speed on a good laptop but stuttering below realtime on weak hardware, and English only, are exactly the pitch for Premium, which runs bigger models on Modal GPUs with two to three second cold starts, better voices, and more languages, at under a dollar per 50 chapters. The elegance is that the free tier demos the paid tier by being honest about its own ceiling: the user who feels the stutter understands precisely what the upgrade buys. If your workload can run client-side at acceptable quality, that is a free tier that cannot bankrupt you, with an upsell built out of physics instead of feature gates.
Extracted from
Indie TM #11: An Intent Graph and the Hunt for Users