Building for scale vs building for right now -- the decision we keep facing

In September, we had a decision to make about Scheduloo's notification system. The current implementation sends appointment reminders through a simple queue: a job dispatched via Laravel's built-in queue, running on the same VPS as the rest of the application. It works. At our current volume, roughly 800 to 1,000 appointment notifications per day, it handles the load easily.

The question was whether to replace it with a dedicated message broker, RabbitMQ or Redis Streams, ahead of a planned feature expansion that would increase notification volume significantly if things went well.

The "build for scale" argument is familiar: do it now while the codebase is young and the refactor is relatively cheap. The "build for right now" argument is equally familiar: do not build infrastructure for a problem you do not have yet. Every hour on infrastructure is an hour not spent on the features that will determine whether scale ever becomes a real problem.

What we decided and why

We kept the current system and added a monitoring alert that would tell us when queue depth exceeded a threshold we agreed would be the early warning signal for actual load problems. The alert has not fired. The notification volume from the planned feature expansion is still three to six months away, if it comes at all.

The decision was not because we are lazy or unserious about infrastructure. It was because we have made the opposite mistake before. On a different project, we spent two months building a multi-tenant architecture for a product that never got more than forty users. That architecture was technically sound and practically pointless. The two months did not return anything useful.

The pattern I try to recognise

The instinct to build for scale is often indistinguishable from the instinct to work on interesting engineering problems. Database sharding is a more interesting problem than adding a booking status filter. Event-driven architecture is a more interesting design than a simple cron job. I have to actively ask myself whether I am making an engineering decision or satisfying an engineering preference.

The right question is: what is the simplest thing that could work for the next six months? If that question has an obvious answer, build that. If the simple thing has a clearly visible scaling failure point, build slightly past that. Do not build for two years from now.

When scale planning actually makes sense

There are scenarios where early architectural decisions become genuinely expensive to undo. Database schema is one: adding a proper multi-timezone support structure early is much cheaper than retrofitting it across a schema that assumes UTC everywhere. Authentication and permissions design is another: changing the data model for user roles after you have hundreds of users and complex role assignments is painful.

For these categories, we do invest early. Not because scale is certain, but because the cost of the wrong early decision is disproportionately high. Everything else, we try to build for the problem we have, watch it carefully, and refactor when the data says it is time. The data has always been honest about when that moment arrives.