Scalability begins well before traffic arrives. It starts with boundaries that let a product evolve: clear API contracts, data models that reflect the business, and a frontend that can change without turning every release into a negotiation.
My default is to make the simplest durable decision. That means building small, well-defined services around the work people need to do, then keeping the connection points observable and intentional.
On Friisbee, an HR and accounting platform I built for a UK firm, this meant separating employee lifecycle logic from the accounting ledger from day one, even though a single service would have shipped faster. Two years later, when the client needed a standalone time-off approval workflow for a subsidiary, that boundary was the reason it took a sprint instead of a quarter.
Data models deserve the same discipline. I default to normalized schemas with explicit foreign keys and constraints, even when an ORM would happily let me skip them. Postgres has never once complained about the extra thirty minutes of schema design, and it has saved me from far more than thirty minutes of debugging inconsistent state at 2am.
The frontend gets the same treatment. Typed API contracts — TypeScript end to end — mean a backend change surfaces as a compile error, not a support ticket. It is not a glamorous practice, but glamour was never the goal. Systems that are ready to grow before they have to are the ones that let the next engineer, often future me, move quickly without guessing.