Technical Independence
How we saved money and reduced technical obligation
--
I am convinced that saving costs while running a startup is an undervalued skill. Unless actively managed, costs will quickly bloat out of control and sink a startup. Developers often talk about technical debt, but there’s an equally dangerous phrase I call technical obligation. Technical obligation also has an equally dangerous side affect, financial obligation.
Technical obligation in a startup is when a startup relies on various pay-as-you-go services as a solution to their technical problems.
Technical obligation in a startup is when a startup relies on various pay-as-you-go services as a solution to their technical problems. This usually takes the form of a SaaS product. While the SaaS product solves immediate technical problems and needs, the startup quickly finds that it is difficult to function without these services — they have acquired technical obligation.
Identifying Technical Obligation
When I took over the Simplecast infrastructure, I had two responsibilities. 1) Make sure our infrastructure could handle exponential growth and 2) keep our costs from increasing exponentially with that growth.
As I started evaluating Simplecast’s infrastructure I noticed we were extremely heavy on costs. While everything was built on a great platform, full of great features, those features came at a high price.
In addition to the servers we were already paying for, we needed to add at least another $300/month worth of servers to handle our current traffic. To make matters worse, we were also looking at another $1,000/month to grow with our expanding user base. To put this into perspective, our RSS feed endpoints alone handle over several million requests a day.
Despite user growth, our server costs were disproportionately high compared to our revenue. Swapping multiple servers is not an overnight job, nor is it something that can be accomplished in a week. We were technically, and financially, obligated to our server infrastructure (and the companies providing it) in a way that was significantly hurting Simplecast.
It should be noted that not all technical obligation is bad. In our case we needed to find a different server infrastructure solution, we weren’t about to build our own server farm, but we did need to be on a system that wasn’t going to cripple us financially both now and in the future.
Reducing Technical Obligation
We needed a solution that would be low cost, have a robust API and could handle fast infrastructure scaling. We were also looking for great customer support, simplicity in services (we are Simplecast after all) and a service that was backed by industry leaders. It didn’t take us very long to see that DigitalOcean met all of these requirements.
While DigitalOcean is not necessarily the lowest cost out there, I believe they strike a great balance between cost and quality. By migrating our primary hosts over to DigitalOcean we were able to scale to handle our current traffic load and reduce our immediate monthly server costs by $700/month. We also made big changes to our CDN, which helped reduce costs and improve global audio file delivery, but more on that in my next article.
By switching over to DigitalOcean we were able to scale to handle our current traffic load and reduce our immediate monthly server costs by $700/month.
In addition to moving our servers over to DigitalOcean, we took advantage of their robust API by building our own server management system. Using DigitalOcean as the backbone we can now spin up new server clusters, deploy with zero downtime, monitor all our servers, quickly scale servers up or down, receive text alerts when things go wrong and much, much more.
The Road Ahead
While a podcast listener might not ever know, or care, about what we’ve done with our infrastructure, they will most certainly “feel” it. A better foundation means a faster and more reliable service. A faster and more reliable service means that listeners will receive a much more enjoyable experience overall.
