DEV by Hookay
Deep Dive 2026-05-12 · 2 min read

Testing a social app that has no users yet

Proximity discovery, feed ranking, k-threshold suppression — every core feature of Hookay depends on crowd behavior, and our crowd doesn't exist yet. How we build and test a location-based social product pre-launch: synthetic populations, simulated cities, and the bugs only fake people can find.

A social app before launch has a chicken-and-egg problem that goes deeper than marketing: the software itself can't be exercised without a crowd. Our discovery feature aggregates people over hexagonal cells. Our feed ranks what's happening nearby. Our privacy layer suppresses any cohort smaller than a threshold. With three test accounts on a staging cluster, every one of those features renders the same thing: nothing. Empty states all the way down — and worse, the privacy suppression should render nothing at that scale. Correct behavior and broken behavior look identical.

So the first substantial system we built wasn't a feature. It was a population.

Synthetic Hamburg

Our load and behavior harness simulates a mid-sized launch city: thousands of synthetic users with home cells, schedules, and habits. They wake up, commute between cells, post content that expires, RSVP to each other's plans, and go quiet at 2 a.m. The generator is deliberately unglamorous — weighted random walks over the cell grid plus daily rhythm curves, not machine learning — because we need plausible aggregate density, not convincing individuals.

Three rules keep the simulation honest:

  • Synthetic users go through the front door. They hit the same public API as the real apps, rate limits and auth included — no seeding rows directly into databases. A fleet that bypasses the API tests nothing but the database.
  • The population is reproducible. Every run is seeded; when a ranking anomaly shows up at simulated Tuesday 23:00, we can replay the exact same city and bisect.
  • No real-world data, not even "anonymized". The temptation pre-launch is to bootstrap behavior models from public datasets. For a queer app, location-behavior data is exactly the substance we exist to not hold. The fake city is fake from first principles.

The bugs only a crowd can find

The harness paid for itself within weeks. Cohort suppression had an off-by-one that only manifested when a cell's population crossed the threshold downward — invisible with three users, who never cross anything. Feed ranking starved sparse rural cells in ways no unit test of the scoring function predicted, because the bug lived in the interaction between proximity weighting and an emptying corpus of expiring posts. Cell-border commuters produced duplicate discovery entries at exactly one geometry — found because synthetic commuters cross borders thousands of times a night, which no QA engineer will ever do.

None of these are exotic. All of them are population-shaped: properties of densities and distributions, not of any single request.

What the fake city can't tell us

The limits are worth stating just as plainly. Synthetic users don't get bored, don't misunderstand the UI, and don't behave adversarially in creative ways — the harness validates the system's mechanics, not the product's appeal, and our launch-day distribution will certainly differ from our random walks. What it gives us is narrower but real: when the first actual users arrive, the load envelope, the suppression edge cases, and the empty-to-sparse-to-dense transitions will all have been crossed thousands of times before anyone real crossed them once. The crowd is fake. The confidence is not.

// Published under CC BY 4.0 — take the patterns, cite the source. · ← All articles