Trying not to architect for a scale problem I don’t yet have

Yesterday I sat down to refactor how Hyp pulls in product and collection data from Shopify's product catalog.

I haven't even sold to a single customer, but I still think about scale. Will my architecture support 1,000 tenants? Will it support 100,000? What happens if a large e-commerce customer with 1 million products onboards? Do my databases fall over? What's that going to do to my Redis storage costs?

When you're a startup, should you be designing for the scale you'll need eventually, or deliberately ignoring that and building only for the customers you're trying to land first?

I'm a bit of a perfectionist. I want everything to work as it would in production at scale. Google Cloud Platform (where I'm building because it's what I know) is obviously a very scalable platform, but only if you architect correctly. And that takes time.

Multi-region setup, Pub/sub scaling, minimum numbers of Cloud Run worker instances, correct BigQuery partitioning, relevant Postgres indices, and Redis caching. There's so much to decide upon, and a decision today could come back to haunt me if I do ever get lots of customers.

Even when I was designing my own little side projects, I'd always build them in a way that would scale to thousands of users just in case.

None of those projects ever got past 1 user (me).

So I'm trying to land on a middle. Whenever I'm sitting down to write code or design the architecture, I remind myself to reel it in. I'm finding it difficult as I don't like building something sub-par. But then I see people with no coding experience, who don't even know what scaling means, vibe-code a product in days and win customers.

The version I'm aiming for now is: build for ten to a hundred medium-sized clients, not ten thousand. If I do get ten clients, all of whom are paying me money, then I can worry about scale. If I get to a hundred, that's a hire-someone problem, and I can worry about it then. Done is better than perfect, especially when I haven't even validated the concept yet.

Andy Budd, an ex-Seedcamp EIR, put it nicely: "perfect is the enemy of shipped."

The hard bit for me is that "perfect" doesn't feel like polish but feels like doing the work properly. Skipping a scale consideration today feels like leaving a known bug in the system, even though the system has no users yet to hit it.

Security is the part I won't be scrappy on. It's hard to retrofit cheaply, and I'm not going to leave it for later. Plus it is important to be that I respect my potential customers' data.

So the middle I'm landing on is this: don't over-engineer for scale, do take security seriously from day one, and build in a way that could scale later without needing to be rewritten end-to-end.

I don't feel great about it (even though I know it's the right decision logically, my character traits of wanting things to be perfect are very deeply ingrained), but I'm reminding myself daily that validating it is the next job, and weeks spent over-engineering doesn't get me any closer to a paying customer.