Finding the right trade-offs

In an ideal world, everything is designed from the beginning to be able to scale effortlessly to accommodate future growth of product, company, and customer base. But in the real world, products and teams may start small and resource-strapped so every extra effort is judged based on its ROI. Oftentimes baking-in code that makes it easier later to expand internationally is deemed unnecessary and is postponed.

The purist may dismiss this as being always bad and always wrong, but if you built the wrong product or your startup ran out of money, not being able to geo-expand may not be your biggest problem.

The general guideline is to make sure things that are difficult to fix later are done right from the beginning. Things like database schemas or URL structures that may be expensive to change later should be done with growth and flexibility in mind.

When it comes to other features that can easily be fixed or extended later may be good candidates for some initial shortcut.