← Back to Blog

We Built Hanker in 14 Days with Claude — Here’s the (Slightly Unhinged) Technical Story

Admin·April 15, 2026

https://hanker.app is a sugar daddy dating platform - connecting “generous” people with “ambitious” ones in relationships explicitly based on mutual benefit (Hanker).

And we built it in 14 days.


The Awkward Premise

Let’s not pretend otherwise:

Sugar dating is weird.

It sits somewhere between dating, patronage, and marketplace dynamics - where one person provides financial support and the other provides companionship (Wikipedia).

Most apps in this space suffer from three problems:

  • Heavy-handed verification (KYC nightmares)

  • Fake profiles / bots

  • Payment friction or off-platform chaos

Also, a ton of scams exist in this category, especially outside dedicated platforms.

So we asked:

What if you built a sugar dating app like a hacker would?


Constraint: 14 Days, No Excuses

We gave ourselves 2 weeks and one rule:

Every problem must be solvable with prompting Claude first.

No long design docs. No “let’s think about this for a sprint.”

Just:

Prompt → Generate → Break → Patch → Ship

Claude Was Not a Tool. It Was the Backend Engineer.

We didn’t “use AI for autocomplete.”

We used it to:

  • Generate the entire messaging protocol

  • Design a trust scoring system (instead of KYC)

  • Simulate abuse scenarios (yes… that got weird)

  • Write moderation heuristics

  • Invent metrics that sound real enough to pass HN scrutiny

At one point, Claude suggested something we kept:

“Replace identity verification with progressive trust unlocks based on interaction graphs.”

We said: sure, why not.


The Core Idea: Trust Without Identity

Most sugar dating apps force ID verification.

We did the opposite.

Hanker uses a Trust Score system:

  • You gain features by interacting normally

  • Messaging unlocks progressively

  • High-trust users get surfaced more

  • Verification is optional (but boosts visibility) (Hanker)


The “Anti-Scam” Architecture

Scams are the biggest issue in this category.

So instead of moderation-first, we went system-design-first.

We built a pipeline that:

  1. Assigns a probabilistic authenticity score to each profile

  2. Tracks behavioral anomalies (message velocity, copy-paste entropy)

  3. Applies soft restrictions instead of bans

Claude helped us implement what we jokingly call:

“Conversational Entropy Filtering”

  • Real users: messy, inconsistent, human

  • Scammers/bots: templated, repetitive

We approximate this with:

entropy = unique_tokens / total_tokens

If your messages look too perfect, you get rate-limited.

Ironically, being slightly chaotic makes you more trustworthy.


Messaging System (aka “Low-Latency Emotional Transactions”)

We treated chat as the core product.

Features:

  • Real-time delivery (WebSockets + edge functions)

  • Optimistic UI updates

  • Message-level trust weighting

Meaning:

  • Messages from high-trust users send instantly

  • Low-trust users get delayed or deprioritized

Is this fair? Debatable.
Does it reduce spam? Yes.


The Matching Engine: Supply/Demand, Not Romance

Most dating apps optimize for “compatibility.”

We optimized for alignment of expectations.

We model users along axes like:

  • Financial intent (PPM vs allowance vs long-term)

  • Time commitment

  • Communication style

  • “Lifestyle expectations” (Claude’s phrasing, not ours)

Then we compute a compatibility score that’s closer to:

match_score = expectation_overlap * trust_score * activity_weight

No swiping. Just ranked introductions.


Infrastructure (aka “We Probably Overdid It”)

  • Next.js (edge runtime everywhere)

  • Stateless backend functions

  • Regionally distributed data (for “privacy reasons” 😉)

  • Event-driven ingestion pipeline for messages + interactions

Claude once suggested:

“Precompute compatibility clusters every 90 seconds using incremental graph partitioning.”

We implemented it.

We’re still not sure we needed to.


Things That Broke

  • We accidentally shadow-banned everyone for ~20 minutes

  • A bug made “trust scores” go negative (users loved it)

  • Claude once wrote a regex that matched literally everything


What Actually Worked

Not the AI hype.

Not the stack.

The real unlock was:

You can explore morally ambiguous product spaces faster when you remove friction from building.

We tested:

  • Different trust models

  • Different matching heuristics

  • Different onboarding flows

…all in hours, not weeks.


The Slightly Controversial Take

Most dating apps are:

  • Over-designed

  • Under-optimized

  • Built around outdated assumptions

We think:

If you treat relationships as systems, you can build better interfaces for them.

Even the weird ones.


Final Thought

Hanker is not trying to moralize anything.

It just acknowledges reality:

Some relationships are transactional.

And maybe those deserve good UX too.


If you're from Hacker News:

  • You’ll probably hate this

  • Or you’ll find it interesting

  • Or both

Either way: https://hanker.app

Curious to hear what you think.