ProductTurn fuzzy intent into structured cards a machine can match
An OG indie hacker building tools that make you happy
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.
Related advice
Octavian ChișA needs-and-offers network is worthless until it is dense
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.
Octavian Chiș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.
Andrei StatescuBuild inside the platform instead of pulling its readers away
The existing text-to-speech tools all make the same move: extract the story from the platform and play it in their own app. That works until you notice whose lunch it eats, because web novel platforms live on ads, comments, and community, and a tool that siphons readers off the page is a traffic devourer they have every incentive to fight, in court if necessary. Naramine is an extension precisely so it can stay on the page: it reads the chapter where it is published, follows the pagination, and leaves every pageview, comment, and vote where the platform can count it. That shape is what lets Andrei position it as an accessibility layer platforms could tolerate or even endorse, rather than a parasite they must kill. When your product feeds on someone else's content, the architecture is also the legal strategy: pick the shape that adds to the host's metrics instead of draining them, and you convert a future plaintiff into a future partner.
Andrei StatescuMake the first audio chunk tiny so playback starts before the file exists
A chapter of a web novel runs around ten thousand characters, and synthesizing all of it before playing would mean a long silent spinner. Naramine instead generates a very small first chunk so the play button responds within seconds, then produces progressively larger chunks until the pipeline reaches normal flow, pre-buffering ahead of the listener and preprocessing the next chapter in the background before the current one ends. Minutes of compute still happen, but they hide behind consumption time the listener was going to spend anyway. This is the streaming insight applied to generative products: what users feel is latency to first value, not total processing time, and the two can be decoupled almost completely. Whatever your product generates, slice the work so the first slice is nearly free, ship it the moment it exists, and let the rest of the job run behind the experience instead of in front of it.
Extracted from
Indie TM #11: An Intent Graph and the Hunt for Users