Challenging traditional dating apps: "what if they were designed for meetings, not swipes?"
Hi Indie Hackers,
We’re working on a project called Soulmate.
Most dating apps are optimized around engagement metrics:
endless swiping, prolonged chatting, profile accumulation, and ambiguity.
These dynamics keep platforms alive, but often delay or even prevent real-world meetings.
Soulmate starts from a different premise.
What if a system was designed to discourage those behaviors instead of reinforcing them?
The project is web-first and built around a set of intentional constraints:
time-limited visibility, reduced digital permanence, privacy by default, and mechanisms that favor clarity and in-person encounters over continuous online presence.
The conceptual model and ethical framework are already defined.
We’re now opening the project to collaborators interested in helping translate these ideas into a focused MVP, without falling back on standard social or dating patterns.
We’re not looking for a single role or profile.
Anyone interested in working on the technical implementation of a system based on already defined constraints and rules is welcome to contribute.
Happy to share more details with those curious.
— Francesco
The structural-constraint angle is interesting. How do you prevent users from gaming the system once the rules are known?
Hi Sam
Great question. I approached this primarily as an incentive-design problem rather than a rule-enforcement problem.
The system isn’t protected by hidden mechanics. Instead, it’s structured so that no single action can generate compounding long-term advantages. Every relevant action updates the user’s state, and future opportunities depend on that evolving state.
If someone tries to optimize strategically, any short-term gain produces diminishing returns over time — reduced priority, constrained access, or lower incentive weight. In other words, gaming the system doesn’t scale.
Explicit sanctions (like bans) exist for clear abuse, but the core protection is architectural: the incentive structure is designed to make manipulation structurally inefficient.
Designing that balance between transparency and robustness is one of the central challenges of the system.
Francesco
I thought about this a lot last night as I wasn’t able to really fall asleep.
I think if you want to go against the traditional incentives of dating apps, which is mostly engagement, then you need a really strong hook. Otherwise you’re fighting yourself by incentivizing behavior that ultimately makes your users leave your app.
The hook I envision is a dating app that fights the primary issue with dating apps, which is safety and trust. Lying is detected and punished, so to speak. Poor behavior is downvoted. Etc.
Hi Flatts,
I think you’re right that going against engagement-driven models requires a strong structural hook.
But the hook isn’t just safety — it’s intentional scarcity.
Traditional dating apps optimize for time spent. This system optimizes for outcome quality. The constraint itself becomes the differentiator: limited visibility, structured cycles, and state-dependent access create higher signal and lower noise.
The goal isn’t to make users leave quickly. It’s to align platform incentives with successful interactions rather than endless browsing.
Trust and safety are foundational, but they’re not the core hook. The core hook is a different incentive architecture: one that rewards completion and commitment instead of activity volume.
That shift changes user behavior dynamics entirely.
Francesco
Hello Francesco, I can contribute tech and on behavioral design. I'm ultra good (25+ years exp.) at coding and WebRTC (audio/video conferencing)
Hi, thanks for reaching out.
Just to clarify a small misunderstanding: the core behavioral logic and system rules behind Soulmate are already defined and have been refined over time. I’m not looking to redesign the behavioral model from scratch.
That said, I’m open to constructive improvements, as long as they work within the existing framework and strengthen it, rather than replace it.
At this stage, the main challenge is translating a rule-based, constraint-driven system into code.
The core of the project revolves around enabling and guaranteeing real-world meetings — something traditional dating apps structurally fail to do — through explicit rules, states, and enforced flows rather than engagement mechanics.
With that context, I’d like to understand more concretely: what you feel you could contribute at a technical level, which parts of such a system you’d be most comfortable implementing, and any relevant experience with complex, stateful or rule-heavy systems.
This will help me assess whether your skills align with what the project currently needs.
Francesco
Hello Francesco, I'm good at webrtc (video calls) part mainly which is core trust model of the system also I'm married with foreigner wife which I found on dating website and I've good knowledge on how to find real or fake people from their online presence patterns and behaviors. But also all of the application may need some professional touch as I have some really solid experience of coding on many industries, automotive, defense industry and uncountable softwares delivered which doesn't fit this textbox. Just imagine the 25 years. I'm also quite good at infrastructures and server systems like docker kubernetes
Hi, thanks for the detailed reply — I appreciate the context.
What you mention around WebRTC, trust signals and infrastructure is definitely interesting, and likely relevant at a later stage of the project.
Right now, though, my focus is very specific: building the core system structure first. That means implementing the existing rules, states, and flows that make the system work as intended, before layering additional components like real-time interactions, trust mechanisms, or optimization.
Once the foundational structure is solid and behaving correctly, contributions around areas like trust, real-time communication, or infrastructure could absolutely become valuable.
For now, I’m prioritizing people who can help establish that initial backbone.
Let’s stay in touch and reconnect when the project reaches that stage.
In the meantime, feel free to share your name and an email address — just so I can keep a reference and reach out when it makes sense.
Francesco
My name is Goksel, you can reach me out at gdarcan@gmail.com. btw, initial backbone, I've ultra experience on database architecture, backend frontend stack, server side microservice architecture. WebRTC comes after these knowledge. Also I had good experience on GDPR law which I was cofounder of a related company
Hi Goksel, nice to meet you, and thanks for taking the time to explain your background.
Your experience across databases, backend/frontend stacks, microservices, infrastructure, and GDPR is clearly solid and valuable. However, for the current phase, I need to stay narrowly focused on establishing the system’s initial backbone before moving on to additional layers.
That said, if you happen to know someone with deep experience in implementing complex, rule-driven systems — where the core logic and constraints are central and already defined — I’d be very happy to be introduced and discuss whether there could be a fit. I’d gladly loop them into the conversation.
In any case, I’ll keep your contact and would be happy to reconnect at a later stage, when areas like infrastructure, compliance, or trust-related components become more relevant.
Thanks again for reaching out.
Francesco
Hi Francesco,
Love your vision, it is a breath of fresh air in dating world where you will focus on searching the right soulmate rather than engagement metrics.
We can help you with the MVP development and later as a full fledged product. Would you like to discuss in detail?
Thanks,
Patrick
Hi Patrick,
thanks for the message — glad the direction resonates.
To add a bit of context on the core objective: Soulmate starts from recognizing a structural limitation shared by all dating apps. They can facilitate attempts, but no system today is designed to guarantee an actual meeting. When attempts fail, responsibility is pushed entirely onto individuals, often creating frustration and unhealthy dynamics.
Soulmate explores whether a system can be designed to guarantee a real encounter within the community, without promising attraction or outcomes, but without leaving everything to chance or persistence alone.
This shift in objective is the foundation of the project and drives all design decisions. Before talking about MVP scope or timelines, it’s important for me to understand whether working within this kind of constraint-driven, non-standard approach is something you’d be genuinely interested in.
Francesco