DEV Community

Cover image for Scaling a 950K Company Directory Solo: What Actually Breaks First
Serhat Soruklu
Serhat Soruklu

Posted on

Scaling a 950K Company Directory Solo: What Actually Breaks First

Building a large-scale platform solo sounds exciting until you hit the parts nobody talks about.

I’ve been building Coupyn, a referral + coupon platform with ~950,000 companies, entirely on my own.

Here’s what actually breaks first.


1. Not performance. Not code. Reality.

Your system will work.

Your queries will be fast.

Your pages will load.

But users won’t come back.

The real bottleneck is not infrastructure.

It’s:

  • No retention loop
  • No outcome signal
  • No reason to return

You can build something technically solid and still have a “ghost system”.


A split scene showing a perfectly working system on one side and an empty, lifeless platform on the other. Everything works technically, but no users return.

2. Scale exposes weak assumptions

At small scale, everything looks fine.

At large scale:

  • 950K entities ≠ 950K value
  • Most pages get zero interaction
  • A small % carries all activity

You start seeing:

  • “Dead zones” in your system
  • Mismatch between traffic and value
  • Actions that don’t translate into outcomes

This forces you to think differently:

Not “how do I scale more pages?”
But “which pages actually matter?”


Small scale looks healthy, but at large scale most pages are inactive. A few hotspots carry all activity while the rest become dead zones.

3. SEO is not a growth loop

Getting indexed is not the win.

I have hundreds of thousands of pages indexed.

That doesn’t mean:

  • users trust the platform
  • users return
  • users convert

SEO gives you visitors
You still need to build:

  • trust signals
  • feedback loops
  • repeat usage

Thousands of indexed pages driving traffic, but users don’t trust, return, or convert. Visitors come in, but the loop never closes.

4. Solo building changes your architecture

When you’re alone, you optimize differently:

  • Simplicity > abstraction
  • Control > flexibility
  • Debuggability > cleverness

Every system has to be:

  • understandable at 3am
  • fixable without context switching
  • stable under partial failure

A lone developer working late, prioritizing simplicity, control, and debuggability. Systems designed to be understood and fixed without complexity.

5. The real system is behavior, not code

Your backend is not your system.

Your frontend is not your system.

Your system is:

user → action → outcome → trust → return

If that loop is broken, nothing else matters.


A central loop visualizing user → action → outcome → trust → return. Code surrounds it, but the real system is user behavior, not the stack.

Where I’m focused now

Not features.

Not redesigns.

Just this:

Turn first visit into a second visit.

That’s the entire game.


A lone developer at night, system running perfectly, but paused in thought. Not debugging code, questioning outcomes. “What broke first for you?”

If you’re building something at scale, especially solo, I’m curious:

What broke first for you?

Top comments (0)