Building for Two Clients vs Building for Scale

I built a POS system that now serves two gaming cafés. Real money, real transactions, real users every day. Here's what I learned.

The Context

When a café can't bill customers, they lose money. Every. Single. Minute.

This isn't a side project where bugs are "learning experiences." This is someone's livelihood depending on my code working correctly.

What I Prioritized

1. Reliability Over Features

I said no to a lot of feature requests. Why? Because every new feature is a potential failure point.

Instead, I focused on: - Offline-first architecture - Works even when internet drops - Local data backup - Nothing gets lost - Fast recovery - System comes back up in seconds

2. Direct Feedback Loops

With 2 clients, I can literally walk to their café and watch them use the system. I did this regularly.

What I learned from watching: - Features I thought were obvious weren't - Workflows I designed "efficiently" were confusing - Speed matters more than I expected

3. Saying No to Customization

Client A wants feature X. Client B wants feature Y differently. The temptation to build custom solutions is real.

I learned to find common ground and build one solution that works for both. Custom code is maintenance nightmare.

The Key Insight

Build for your current scale, but keep the path to the next scale clear.

Don't over-engineer for scale you don't have. But don't paint yourself into a corner either.

Two paying clients taught me more about software engineering than any side project ever could.