Among the innumerable details startups must get right to raise (or accelerate) their chances of success, striking the right balance between tackling technical tasks internally versus enlisting managed services can be a particularly vital one. Finding that equilibrium requires startup leaders to be realistic about the specific drivers that are most critical to their burgeoning product or service – and to cultivate an accurate appreciation for the value of their own time.
From my own experience, I’ve learned this to be especially true when managing data. The database is such a critical component to almost any technology product or service that it must be unequivocally reliable. This means ensuring the performance, availability and scalability of the database, and having the expertise readily in place to address all maintenance needs and emergencies that will inevitably arise. The question is: when does this reality support the hands-on approach of keeping database management in-house, and when is it best to enlist the most capable external expert you can find? Over the course of developing two startup projects, GetHuman and more recently the personal budgeting application Swish, I’ve found the more advantageous strategy to be pursuing the time and cost savings (and more acute internal product development focus) that managed services provide.
Actually arriving at this strategy, though, was a process. In our early days we actually adjusted several components in each direction across the internal/managed service divide. For example, we started out using Heroku as a Platform-as-a-Service solution in order to reserve our internal bandwidth. However, with performance playing an increasingly key role in enabling us to thrive as an SEO-dependent company, switching away from this service platform allowed us to overcome a few performance hiccups we were experiencing. In another example, we discovered the right balance in meeting our cloud and cloud computing needs by using AWS as a low-touch managed service, while adding Amazon OpsWorks for those situations where internal control was necessary to yield greater results.
As for our database itself, we initially planned to manage it all internally. We selected MongoDB because its JavaScript-like interface meshed with our plan to utilize full stack JavaScript, and also because MongoDB hosted services were an existing option in case we wanted shift in that direction.
Recommended for You
As it happened, we did set up our own MongoDB instance but, within a week of entering production, ran headfirst into an issue serious enough to make us rethink the whole approach. Quickly deciding that we ought to avoid wasting further time troubleshooting internal database management, we began searching for a MongoDB Database-as-a-Service (DBaaS) provider to do the job on our behalf. For that we ended up selecting mLab due to its handling of maintenance updates, instance upgrades to new MongoDB versions, database monitoring and debugging tools, automatic backups, and customer support reputation. But from the perspective of our rapidly iterating company, however, the best benefit was really that this strategy put our small internal team back on product development and not on database fire drills.
This decision quickly proved a wise one in this case because – of course – we soon had an incident where a developer accidentally deleted a sizeable volume of important data. A distressing scenario to say the least, but with hosted database support we were able to restore as much data as was possible, quickly and without the deeper panic we would have felt if we were on our own with the situation. The managed services strategy enabled systems to be brought back to full functionality (and we did increase the frequency of our data backups in the aftermath). Further, by relying on a managed service strategy across GetHuman and Swish, we save our team of senior engineers an estimated 50 hours of work each year, amounting to a tidy $10,000 annual savings in labor costs. Considering that the managed service route also helps us avoid two major site outages events every month – as a low estimate – we likely save another $20,000 each year by working with an external provider.
Entrusting duties to managed service providers can certainly conserve a startup team’s valuable time. In the case of database management, it also means avoiding the terrible episodes that can engulf your team with stress when issues come about. Accurately recognizing these opportunities may take some trial and error, but I’ve found the rewards make this exploration well worth it.
