All advice

Turn fuzzy intent into structured cards a machine can match

Octavian Chiș
Octavian Chiș

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

Business & Legal·Octavian Chiș 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.

Mindset·Octavian Chiș 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.

Product·Andrei Gudiu Andrei Gudiu

Encode the counter as procedure plus scenario, not as a blog post

Andrei did not start from a CMS article about "how to register a car." He started from a physical board that already grouped cases, then noticed that nine to fourteen requirements collapsed to seven shared ones. That observation produced a compiler. A procedure plus a scenario creates a versioned JSON plan of questions, steps, fees, and documents. Each requirement records whether the user needs a copy, an original, or a legalized copy. A blog post goes stale when the counter reprints the board. A recipe can be cloned, versioned, and asked a new question. If you are digitizing a bureaucracy, model the counter's own categories before you write marketing copy. The panel is the schema. The article is the residue.

Product·Andrei Gudiu Andrei Gudiu

Clone the ninety percent that is already the same

Andrei's builder treats transfer-of-registration and first-registration as cousins, not as two products. He clones the shared questions, steps, and fees, then overrides the labels and the required flags that actually differ, parents' IDs at kindergarten, motorcycle plates at 22 lei versus car plates at 56. That is cheaper than maintaining two trees that drift, and it is more honest than a single checklist that lies to half the room. The rule for any procedure product is to find the seven common requirements before you design the fourteenth unique one. Clone first. Override second. If a change to a question does not propagate, you do not have a system. You have a pile of copies.