DEV Community: Aleksandar Kovacevic

What I Learned Building a Dating App That Punishes Engagement

Aleksandar Kovacevic — Thu, 09 Jul 2026 11:11:58 +0000

Most dating apps make money when you don't meet anyone. Every night spent swiping is a night of subscription value and ad impressions. The product is quietly optimized for engagement, not for two people actually meeting.
I'm building the opposite — an app whose only job is to get you off your phone and into a real conversation, fast. I'm building it in Belgrade with a co-founder, and this is an honest write-up of what I've learned so far. I'm going to keep the exact mechanics vague on purpose (it's pre-launch), but the lessons are the useful part anyway.
Lesson 1: I designed a mechanic before designing the psychology
My first version demoed fine and was, when I sat with it honestly, bad. It was a flow, not a feeling. Nothing about it built anticipation or made anyone want to open the app twice.
The fix wasn't new screens. It was going back to actual research on how attraction and closeness form, and letting that research constrain the mechanic instead of decorating it. The meta-lesson: citing psychology papers while building generic features is worse than not citing them at all. If the research doesn't visibly shape what the user does, you're bluffing.
Lesson 2: symmetry is non-negotiable
Every interaction I designed that was one-directional felt broken the moment I prototyped it. One person acts, the other watches? Broken — that's a spotlight on one and a hunt for the other. One answers first? Broken — going first is exposure.
The versions that work are relentlessly simultaneous: both people act at the same moment, neither more exposed than the other. If you're building anything social, audit every interaction for asymmetric vulnerability. If one user is ever more exposed than the other at the same instant, you've designed anxiety into the product.
Lesson 3: your values will cost you revenue, and that's the point
I rejected freemium early — not for business reasons. In a dating product, any paid advantage means money buys romantic access. That corrupts the core promise. Revenue instead comes from the venue side, structured so users never pay to compete with each other. Sometimes the right monetization is the one your product values forbid, and you build around the hole.
Lesson 4: feel before finalize
The entire prototype is a single HTML/JS file. This sounds primitive, but it enforced the most important principle I've got: every mechanic sounded fine in a design doc — the bad first version included. Only tapping through a working prototype revealed which ones produced the feeling they were supposed to. A single file meant iteration in minutes and threw-away entire interaction models without ceremony.
Related: I've leaned on AI heavily for prototyping, and it taught me exactly where the line is. AI will hand you a polished, great-looking product almost instantly — screens, flow, structure, all of it. What it won't hand you is a mechanic that actually works. The surface is the easy part now. The core interaction, the thing the whole product depends on, is where AI kept giving me stuff that looked right and did nothing — and the polish is dangerous precisely because it hides that the hard part isn't solved. My honest take: you can't design good mechanics with AI alone yet. That part still needs a human who knows why it should work.
Why Belgrade, not San Francisco
I'm validating hyperlocally first, then expanding outward, with the US deliberately last. A location-dependent product lives or dies on density — you need enough of the right people in one place at one time. That's winnable neighborhood by neighborhood and unwinnable if you spread thin across a huge market on day one. It also means I can physically walk into venues and talk to owners, which is exactly what's happening now.
What's next
Field validation, then the production build — the genuinely hard engineering is real-time coordination between two live phones, which a scripted demo lets you dodge. I'll write a follow-up once real humans are meeting through it.
If you're building something whose job is to create a feeling rather than complete a task, I'd love to hear how you validate that. For me, prototypes said more than any spec ever did.

Crazy how you can go from a real problem to working solution in matter of days or weeks now

Aleksandar Kovacevic — Wed, 08 Jul 2026 08:23:58 +0000

I wander what life will be like in several years...

Retrieval isn't memory: building a reasoning layer for AI

Aleksandar Kovacevic — Mon, 06 Jul 2026 12:56:34 +0000

Anyone who codes with an AI agent knows the feeling. Inside a session it's sharp — it follows your patterns, respects your decisions, fixes the bug. Close the terminal, open it tomorrow, and it's a stranger. It re-suggests the pattern you rejected. It re-introduces the bug you already fixed.

The usual fix is a memory tool — mem0, Zep, Letta, a hand-maintained CLAUDE.md. We tried them and hit the same wall.

Retrieval is not the same as remembering

Every memory tool does the same three things: store text, embed it, find it again. Store → search → return chunks. That's retrieval, and it's useful — but it's passive. It waits to be asked, then hands back the closest matching text.

A coding agent rarely asks. It acts. By the time you'd want it to recall that this repo validates at the boundary, it's already written the code the wrong way. Retrieval that only fires on demand is a library nobody walks into.

So the question wasn't "how do we store more?" It was "how do we get the right guidance in front of the model before the mistake?" That reframing is the whole product.

Three layers over one database

Memory. One SQLite database is both source of truth and vector store, via sqlite-vec — no separate vector DB, no sync job keeping two systems honest. Work is recorded non-intrusively by hooks in the agent. Retrieval is hybrid: vector similarity plus BM25 full-text, then a cross-encoder rerank. This layer is table stakes — roughly what the other tools do.

Angel (reasoning). A persistent process that thinks over what's stored instead of waiting to be queried. It extracts patterns and decides when one is worth surfacing. Before a pattern is promoted, multiple independent passes have to converge on it — if only one run noticed it, it's noise; if several land on the same thing, it's real. That check keeps single-session bias out of long-term memory.

Whisper (behavior). The part worth its own section.

Whispers: steering the model at inference time

Static prompts don't scale. If you've maintained a CLAUDE.md, you know the failure mode — it grows, every rule is always "on," and by the third session the model half-ignores the whole wall.

So we inverted it. The static prompt shrinks to identity essentials. Everything situational — a rule, a lesson, a convention — becomes a whisper: guidance tagged with a trigger condition, dormant until it's relevant. At session start, and on any turn whose shape calls for it, a lightweight detector asks "is this a moment where remembered guidance helps?" If yes, the whisper is injected into context before the model responds.

The model then behaves as if it had internalized the rule — with no weight update. It's the closest analog to fine-tuning without access to the weights: steering through just-in-time context instead of gradient descent. Retrieval makes the model know more; whispers make it behave differently. A database versus a tutor.

The honest part: misfires

Just-in-time injection has an obvious failure mode — firing when it shouldn't. And the costs aren't symmetric: a correct whisper earns a little trust, a wrong one that interrupts your flow costs a lot, because people remember the annoying one.

So the bar isn't "never misfire" — chasing that makes the system too timid to be useful. The bar is: a wrong whisper has to be cheap to ignore. Non-intrusive, easy to dismiss, never blocking. Get that right and thousands of quiet correct nudges beat the occasional shrug.

Where this is

Code stays in your trust boundary — generation runs through your own local agent with your own credentials, not a third-party box in the middle. The reasoning and whisper orchestration is the part that's ours.

The engine runs daily across real projects and benchmarks competitively on long-memory. What we're building now is the boring, necessary part: making a stranger's first session good.

If you've fought agent memory — rolled your own, wrestled a .cursorrules file into the ground — I'd like to hear how you approached it, especially the misfire problem. I don't think anyone has fully solved that one yet.

Sonn is at sonn.dev.