Developers — I need your honest feedback on my matching app concept
Hello IndieHacker Developers,
I’m a solopreneur currently prototyping a mobile application, a social networking app designed to better connect founders, businesses, partners, and investors.
We’ve all seen the crowded landscape of networking apps, but I kept running into the same frustrating wall: endless swiping based on superficial preferences rather than actual, high-intent alignment.
🤔 The Core Problem
Most platforms match people by broad categories or high-level goals. They miss the crucial layer of precision pairing based on active, unique operational pain points (e.g., exact tech-stack hurdles, specific go-to-market roadblocks, or targeted investments).
I am building a matching engine focused strictly on granular problem-solving to cut down the noise and streamline connecting.
💭 The Honest Feedback From This Community:
I'd love your brutal, honest feedback on two fronts:
-
The Product Concept: What would a platform like this need to do for you to actually use it? Where do you see immediate technical bottlenecks?
-
The Co-Founder Ask: I am currently bootstrapping and prototyping solo. What does it take for an experienced developer to see the value in a concept like this, and what would convince you to join forces as a technical Co-Founder (for sweat equity up to 50%/ early stage)?
Drop your thoughts, critiques, or advice below. I’m ready for the honest developer perspective!
I'd make proximity an option rather than the default tie-breaker. It matters for an in-person cofounder; for a specific technical blocker, available expertise and compatible working hours may matter much more. Let the person state that constraint explicitly.
For the first prototype, a match card could answer: what exact need this person can help with, what evidence supports that, and whether they're available now. Then ask each side why they accepted or declined. Those reasons would give a future model better feedback than swipes alone.
For the cofounder conversation, a small set of real users and documented attempted matches would be more informative than a long feature specification. Include failures: no available expert, unclear request, budget mismatch, or poor timing. That shows a developer what problem remains to solve.
I'm building Portunio around clarifying incoming opportunities, so I share your interest in matching on actual needs. Have you chosen one narrow group where you can supply both sides of those first matches?
The granular matching idea is interesting, but the quality depends on how much detail users will actually provide.
Have you tested whether founders describe their problems specifically enough for the matching engine to produce useful matches?
That is what I'm currently working on in prototype. I am matching by an offer and needs through filtration and then it prioritizes by whose closest in proximity. I figure there's a balance between getting too granular but also too broad categories.
I want to work with a developer with and understanding of Machine Learning that can keep that rythm stable and then as it keeps learning users needs and offers it could get more precisional with time.
That makes the input side the interesting constraint. Before the matching gets more precise, I’d want to know whether users naturally give enough detail in their offers and needs, or whether they default to broad descriptions.
Suppose I join your platform today with a very specific problem. What guarantees that there will already be someone capable and willing to solve it?
although, I liked the Granular Matching Idea, same details issue...