In software development, technology decisions are rarely black and white. Context matters, and the choices you make—especially when deciding between managed services or building everything yourself—depend on the situation.

Despite this, nuanced discussions don’t gain much traction on social media. Instead, controversy drives clicks, polarising the debate. You’ll more often encounter people advocating for the “Not Invented Here” (NIH) mindset, saying, “Just do it yourself, it’s easy.” However, these arguments often ignore the broader context of time, resources, and specific project needs.

hetzner deleted 8TB of data from a customer randomly and there's a thread on HN where people are saying you should own your own hardware and colocate no matter what you do there's always other people demanding you to do their hobbies

— dax (@thdxr.com) December 10, 2024 at 3:47 PM

This article aims to add nuance to these decisions.

Focus on Shipping Features, Not Infrastructure

In the crucial market fit phase, the priority is shipping features and getting feedback. Time is critical, and setting up complex infrastructure can slow down progress. 

Your product is not the DevOps setup—your product is the experience and value it delivers to your users. Managed services that provide hosting, authentication, serverless deployments, or databases (DBaaS) allow you to focus on your product rather than the underlying infrastructure.

Simplicity is sometimes not having to worry about things.

These platforms often offer valuable features. For instance, automatic preview URLs or database branching mechanisms enable faster iteration and testing without requiring custom setups. These features save time and help you ship features more efficiently.

Team Composition: A Key Driver

The size and composition of your team can play a big role. Smaller teams or solo developers, often strapped for time, can benefit greatly from managed services that offload infrastructure management, shifting focus towards shipping. Larger teams (with dedicated roles) may be more suited to build custom in-house solutions. Even then, managed services can provide a quicker start while teams transition to more tailored infrastructure as the product scales.

The question often is: do you want to hire for a specific skill, or would you rather pay for a service that takes care of it for you?

The Importance of Educating Yourself

Education is key when committing to a managed platform. You need to be fully aware of the costs, potential hidden fees, and cost spikes that may occur as your application scales. It’s essential to map out and document the costs of those external services to avoid surprises down the road. Knowing these costs upfront helps you plan effectively.

Equally important is understanding platform limitations—whether technical constraints, performance issues, or missing features. This ensures that your chosen platform aligns with your long-term goals. By staying educated on these factors, you can balance convenience with long-term adaptability.

Avoiding Vendor Lock-In and Big Refactors

Vendor lock-in becomes a concern when platforms offer specific features that aren’t easily transferable. These features, while convenient, can make switching providers difficult later. This is where the trade-off between convenience and flexibility becomes clear. Writing service-agnostic code from the start helps maintain flexibility as your needs change. 

Be mindful of the export options provided by any service you use, as they will impact how easily you can retrieve your data if you need to switch later. There are open-source tools that can assist with this process, it’s important to be aware of them.

Conclusion

Technology decisions are time and context-bound. Managed platforms offer immense value early on when speed is critical. Later, as your product matures, it may make sense to bring solutions in-house. Your product is the value it provides to users, not the infrastructure behind it. Preparing your code to be flexible and service-agnostic ensures you can adapt as your needs evolve.