Commodity code still creates ownership
A custom deployment script may take a day to write. Operating it can take years. Someone must handle partial failures, retries, permissions, upgrades, provider changes, deletion, and recovery. The important cost is not the initial implementation. It is the stream of future decisions the implementation creates. Before building a cloud capability, ask:- Does this capability differentiate the product?
- Do our requirements exceed the managed option in a material way?
- Can we staff its operation during incidents and upgrades?
- Is the control we gain worth the migration and maintenance cost?
- Can we replace the dependency later if our needs change?
Preserve control at the right layer
Avoiding reinvention does not require surrendering ownership. You can keep data and runtime resources in your AWS account while using a control plane to create and manage them. You can use managed RDS while retaining the database, backups, and network boundary in your account. Control and implementation are different questions:Build the differentiator
Teams often spend months on an internal platform because infrastructure work feels foundational. Meanwhile, customers experience no improvement in the product they bought. Build where your domain is unique. For a video company, that may be media scheduling, quality evaluation, and workflow recovery. For a payments company, it may be ledger correctness and risk decisions. A custom certificate renewal controller is rarely the differentiator.“Managed” does not mean “zero responsibility.” You still own configuration, access, data classification, recovery objectives, and vendor failure planning.
Prefer reversible choices
A good platform decision has an exit path.- Keep application code in ordinary repositories.
- Use containers and standard database engines where practical.
- Store backups in accounts you control.
- Export configuration and state needed for recovery.
- Understand which resources survive if the control plane disappears.
- Avoid undocumented behavior that only one operator knows.
A useful rule
Do not ask whether your team can build the infrastructure. Ask whether operating that infrastructure is the best use of the team’s next thousand hours. Use existing systems for undifferentiated work. Build the parts that change what your customers can accomplish. Keep enough ownership to verify security, recover data, and leave when the tradeoff changes.Frequently asked questions
What cloud infrastructure should a startup build itself?
What cloud infrastructure should a startup build itself?
A startup should build infrastructure only when it creates product differentiation, satisfies a requirement managed options cannot meet, or materially improves economics at measured scale. Deployment plumbing, certificate renewal, log collection, backups, and basic orchestration are usually better consumed as managed capabilities.
Does using managed cloud services create lock-in?
Does using managed cloud services create lock-in?
Managed services create dependencies, but lock-in varies by layer. Preserve portability with standard containers, common database engines, owned backups, exported configuration, and documented recovery. Avoiding every managed service can create a more expensive lock-in to undocumented internal tooling and specialist knowledge.
How do you decide whether to build or buy infrastructure?
How do you decide whether to build or buy infrastructure?
Compare confirmed requirements, lifetime operating cost, security ownership, migration options, team expertise, and incident responsibility. Include upgrades and on-call work, not only initial implementation. Prefer the smallest reversible choice that meets current reliability and compliance needs.