Infrastructure should develop with the needs of the product. In this lesson, Carlos Sanabria explains why a founder can start with a lean stack while still taking security, reliability and operational readiness seriously.
The central decision is when a change becomes justified. A more complicated architecture is useful only if it addresses a real requirement or constraint.
What you'll learn.
- Separate the need for stronger safeguards from the desire for a larger stack.
- Look for concrete security, reliability, performance and cost signals.
- Treat infrastructure options as choices, not a mandatory progression.
Start with the current need.
The recording names managed platforms as examples of ways early teams can build quickly. The point is to avoid paying for infrastructure complexity before the business needs it.
A small product still requires care. Understand what the service provides and what your team must configure, monitor and operate. Choosing a lean starting point does not remove the responsibility to protect the product or recover from a failure.
Strengthen the foundation before replacing it.
Carlos describes a frequently overlooked step: improving security, scalability and monitoring within the current setup. Engineering expertise can help distinguish a missing safeguard from a limitation that requires a different architecture.
Consider backups, restoration practice and visibility into failures alongside product requirements. These improvements may address the actual risk more directly than moving to a new provider or splitting the system into additional services.
Look for observable triggers.
A customer’s security requirement, recurring reliability problems, performance limits or rising costs can justify a closer review. Compare the signal with business needs: which users are affected, how often the problem occurs and what it costs to leave it unresolved.
Team friction is another signal. If engineers cannot understand the code or make changes safely, investigate boundaries, documentation and ownership. A tangled codebase is not automatically solved by deploying it across more services.
Choose a proportionate change.
The lesson discusses dedicated backends, larger cloud setups and, for some products, distributed services or multiple regions. These are options with different trade-offs, not milestones every startup must pass.
The direction of change can also be toward simplicity. A clearer modular structure may serve a team better than additional operational components. Explain which requirement the proposed change addresses and how you will tell whether it worked before committing to the migration.
Let observed needs set the pace of infrastructure work. Strengthen the current foundation where possible, and introduce additional complexity when you can explain the problem it will solve.
