Spring

Loneliness isn’t a shortage of people. It’s a shortage of being known. Spring’s AI gets to know you first, then introduces you to someone real. No swiping. No deck of strangers.

Comment

Inspiration

Singapore is 734 square kilometres with almost six million people packed into it, so you are never more than an hour away from anyone, and yet I can think of few harder places to be single.

What I kept noticing through my late twenties and thirties was that none of my friends had actually given up on meeting someone, they had given up on the apps. These were warm, funny, generous people, the sort you would introduce to your closest friend without a second thought, and they had all quietly arrived in the same place, which was that an hour a day spent judging strangers on four photographs was no longer worth what it cost them. They still wanted the relationship, they had simply stopped believing the interface would ever produce it.

That is the part the category will not say out loud, because a swipe deck only ever knows your photographs and was never built to know anything more, having been designed to keep you swiping, and every hour spent swiping is an hour that did not become a date. When the business model and the outcome pull in opposite directions, the user is the one who absorbs the difference.

So instead of trying to build a better deck I started somewhere simpler, from the idea that loneliness has never really been a shortage of people so much as a shortage of being known. If that is true, then the first job of a dating product is to understand you well enough to make an introduction worth showing up for, in the way a good friend does it, or the way a matchmaker has always done it for the small number of people able to pay several thousand dollars for the privilege.

Spring is what happens when you try to give that to everybody else.

What it does

Spring is an AI matchmaker, and there is no swiping anywhere in it.

Rather than filling in a form you have a conversation, in which Spring's AI asks you the kind of question a perceptive friend asks somewhere into the second drink, and then keeps asking across days and weeks instead of extracting everything from you in one sitting. It remembers what you tell it, so that something you mentioned about your last relationship in the first week will shape what it asks you in the third, and will shape who it puts in front of you.

When it has someone, it makes an introduction, which means one person and a reason rather than a hundred faces to sort through. Spring explains in plain language why it believes the two of you should meet, where you overlap, where you differ in ways that might turn out to be interesting rather than fatal, and what you could actually talk about, all of it written in the register of a friend making an introduction instead of a compatibility percentage stamped on a badge.

It stays with you after that, nudging conversations that stall, and when you are ready to meet, Date Quests hand you the hardest message in the whole exchange, the one that proposes an actual date, so that it arrives as something the app offers you rather than something you have to work up the nerve to send.

Underneath all of that sits the machinery that protects the promise. Photos pass through moderation and a face check before they reach anyone, matching runs automatically, and no human being reads your conversations, because a product that asks people to be honest with it has to make that guarantee without qualification.

Every decision was measured against one idea, which is that a smaller number of better introductions beats a larger number of worse ones, and anything that pushed the count up while pushing the experience down did not survive the cut.

How I built it

I am a solo founder, so all of this, along with the entire operation around it, is one person working with a great deal of AI leverage.

The app is React Native and Expo on a bare workflow, written in TypeScript, with Expo Router handling navigation and TanStack Query handling everything that comes off the wire. Supabase carries the backend, which means Postgres with row level security, Realtime for chat, Storage for media, and a substantial fleet of Deno edge functions where most of the actual thinking happens. Long term memory runs on pgvector behind an asynchronous extraction pass that pulls durable facts out of conversations, embeds them and retrieves them by similarity, so that the matchmaker's picture of you accumulates rather than resetting every session. Claude powers the conversational layer, ElevenLabs handles voice, AppsFlyer does attribution, Sentry watches for things breaking, and both the marketing site and the admin portal deploy on Vercel.

Three decisions shaped the product more than anything else did.

Aliveness is a question of timing well before it is a question of wording. Streaming raw tokens to the client is easier and it is also an unmistakable tell, so the server streams over SSE while the client re-chunks the response into separate bubbles, giving each one a typing time proportional to its length, pauses between thoughts, and a pace that varies by persona. The words had been fine all along, and it only began to feel like a person once the rhythm underneath them was right.

The matching engine is not a prompt wearing a costume. It runs to well over a thousand lines with a comparable weight of tests behind it, living in its own edge function, because anything Spring says about why two people should meet has to be defensible by something deterministic underneath, and a matchmaker that invents its reasoning does more damage than one that says nothing at all.

Monetization is part of the product rather than a layer bolted on at the end, which is where RevenueCat earned its place. Spring resolves a user's tier by taking the higher of their RevenueCat entitlement and their server side subscription record, and although that sounds like plumbing it is the reason I can grant genuine paid access to an early cohort, reward both sides of a referral with a free week, and comp an account for support, without any of those becoming a special case in the client. Every one of them is a growth lever, and every one of them would have been a fragile branch in the code if entitlement had not had a single source of truth.

Challenges I ran into

The first outside tester I put it in front of told me it felt dead, and handed me five separate pieces of feedback that I initially read as five problems when they were really two. It felt lifeless because latency, motion and turn taking are all cues that something is alive and I had gotten all three subtly wrong, and the intelligence in the product was doing sophisticated work that the user had no way of seeing. I tore up the entire conversational layer and rebuilt it before launch instead of after, which cost me weeks and was still clearly the right call.

That same tester could not find a single match among fifty test accounts, and that one finding taught me more than the rest of it combined. The hard problem in this category was never the algorithm, it is density, and an app with brilliant matching and no liquidity is a beautifully engineered empty room. It sent me back to rebuild the entire launch plan around making one market genuinely dense before opening a second, which is slower than every growth playbook tells you to be and is the only thing that actually works here.

Then there was a full production outage that I spent hours diagnosing in precisely the wrong direction. Everything timed out at once, I was certain it was a bad over the air update, and the rollback I reached for fixed nothing while quietly reverting every other improvement I had shipped that week. What had actually happened was that the database exhausted its disk IO budget on undersized compute and throttled the whole instance. The downtime itself was survivable, and the confidence with which I chased the wrong cause was the part that cost me.

The bug that frightened me most never announced itself at all. My photo moderation was scoring nudity as the maximum of the adult and racy signals, which in practice held back almost every ordinary photograph a real person would upload, silently, in a queue, with nothing surfaced to the user. Onboarding would have died at the photo step on launch day and I would have spent a week blaming the funnel.

Accomplishments that I'm proud of

Mostly that it exists at all, and that one person built it.

Beyond that, I am proud that the matching engine has real test coverage sitting behind it rather than a prompt and some optimism, that the conversational layer makes people forget they are talking to software because its rhythm is right rather than because it pretends to be human, and that the design system has proper tokens so the product looks composed instead of assembled. The decisions I am proudest of are the ones I made against my own short term interest, above all the refusal to build the swipe mechanic that would have lifted every engagement metric I have.

What I learned

The clearest lesson is that aliveness lives in latency and cadence long before it lives in the words, and that no amount of rewriting will rescue a conversation whose rhythm is wrong. Close behind it is that liquidity outranks polish every single time, because the most elegant product in an empty room is still an empty room, and I spent longer than I should have making things beautiful for a market that did not yet exist.

I also came to understand that trust is a product surface with a genuine build cost, and that it tends to be the first thing an AI product spends without noticing it has spent anything. Monetization turned out to be product design in much the same way, since getting entitlements right early is what made every later growth experiment cheap instead of turning each one into another fork in the code.

The lesson that cost the most, though, was that the failures which really hurt were never the loud ones. They were the ones that returned success and quietly did nothing.

What's next for Spring

The next thing to ship, in October, is Introductions. Today the matchmaker learns you and then hands you a curated feed. With Introductions it does the last part as well: you tell it you are ready, it goes and asks someone on your behalf, and each side gets a reason written for them, so neither person is left staring at a stack deciding who deserves a message. That is the thesis finally closing.

Underneath that, the work is getting Singapore genuinely dense before opening the corridor outward, because the person no incumbent in this region serves on purpose is the one whose life already spans more than one city, and that is exactly who Spring was built to reach.

After that, Date Quests grow into a real marketplace of things to actually do together, compatibility gets a deeper version for the people who want the long read, and I keep holding the line on the only number that has ever mattered here, which is not how many matches somebody collects but how many times they end up sitting across a table from someone.

Try it at spring.dating.

Built With

Share this project:

Updates

Submission history