Startup Journey From Engineer to Founder, Lesson 2: Invest in Infrastructure
By Poornima Vijayashanker A little over 4 years ago I decided to transition from being a founding engineer to a founder. I knew that …
By Poornima Vijayashanker
A little over 4 years ago I decided to transition from being a founding engineer to a founder. I knew that I could build a product and recruit a team, I had learned those skills at my first startup, Mint.com. But I was really curious to know what it was like to be a founder. I wanted to build a company and a business. Here are some takeaways on my journey from engineer to founder.
Most recently I’ve met many engineers out there who are contemplating this transition from engineer to founder, and maybe filled with enthusiasm and some anxiety. I know I’ve been there. This is the primary reason why I want to share what I’ve learned with them. The goal of this series is to:
Save others from the trial-and-error process that I went through and fast-track their learning in becoming a successful founder
Give them a hint of what to expect on the path from engineer to founder
Provide motivation for why the journey and transition can be worthwhile
I won’t be covering step-by-step methods in these posts. If that’s what you’re looking for then I’d encourage you to read through my blog, and check out my FREE email course: How to Transform Your Ideas into Software Products.
In my previous post about navigating the journey from engineer to founder, I talked about being honest about the skills that you don’t have, and how to deal with those limitations. In this post, I’m going to talk about why you need to invest in infrastructure tools from the very beginning and how to evaluate them.
Travel Back in Time
My life and the lives of other engineers back in 2006 was pretty difficult. While I was working at Mint.com, my team and I had to do ALL of the following ourselves:
Create deploy scripts and take down the site to do a deployment
Manage the entire database chain from schemas to sharding and replication
Manage hosting (this was for security reasons given that we were a financial services company)
Manage log files and their growth
Build a performance monitoring system
Build a caching system
Run SQL queries to mine data for analytics and metrics
Being a pretty scrappy and small development team meant that we had to balance infrastructure projects with building features that would add value to the product and attract and retain users!
We would have gladly paid for off-the-shelf solutions! In fact we were buying a lot of tools and APIs at the time, but we still had to build a lot because the market for tools was pretty nascent.
8 years later, as a founder and as an engineer I am thrilled that there are solid infrastructure tools that have significantly cut down on development time and saved me money!
The tools in the market have kept my team at BizeeBee pretty lean.
I remember back in 2010 when I thought I’d need to hire a DB administrator or a DevOps person. When interviewing them, they’d recommend products that I should be using instead of hiring them, probably because they didn’t want to be re-inventing the wheel themselves!
Build vs. Buy
If all you have to do is push a slider, buy it!
OK it might seem lazy, but so what?! I might be an engineer but I’m also a founder, which means I care about cost, and shipping! The cost of many products out there today like New Relic for performance monitoring, Airbrake or Nagios for site and error monitoring, Loggly for managing log files, MemCachier for caching, and Mixpanel for tracking analytics is much cheaper that building each one of these in house.
How much cheaper?
Well let’s do some simple math, right now I’m paying about like $10-$100/month for about 10 products, a max bill of about $1000/month. Compare that to the $5,000 – $10,000/month investment I’d have to make in hiring a developer to build, test, and maintain these various products. Not to mention how long it would take to actually re-create the depth of detail each of these products offer!
So think about that the next time you’re caught building an internal tool. Find out if one already exists that you can buy. And if you don’t find it in a marketplace like Heroku, then I’d also highly recommend perusing through Github repos to find what you’re looking for. Chances are someone has already built it!
This is especially the case if you are doing development in Ruby on Rails. There have been many gems that have saved my team and I countless development hours.
Now for the caveats…
Whenever there is a product that requires integration, meaning they have an API, that’s when I take the time to do a little bit more investigation. In the case of APIs, I want to know the following:
How long does it take to setup? I usually want to see some social proof that other developers (and not just the rock stars) have been able to do the integration quickly and smoothly.
Is the API or it’s framework compatible with our tech stack?
What is the level of customer and technical support offered? I don’t mean performing the integration, but at least helping with it. If there are some great guides available that is good too. I know the company Stripe has developed some amazing ones and set the bar pretty high.
I want to see a change history! It’s not enough to have technical support, I want to know that people have reported bugs and they have been resolved recently.
If all that checks out then I’m cool with using an API-based product, and taking the time to integrate it with ours.
If you’re developing on Rails and using gems, note that gems will have imperfections. So be sure to read through the changelogs and README file. And if you do run into an issue, know that you can contact the developer. It’s usually in their best interest to fix the issue before others complain!
Don’t Forget You Are a Founder First
One of the lessons I’ve learned having been a founder now for 4 ½ years is that I have to resist the urge to build. I instead focus on unit economics when it comes to the time it would take to build, test, and maintain an internal tool vs. buy, possibly integrate, and deal with some support issues.
In an upcoming post I’ll talk about when it is necessary to build a tool in house, so stay tuned for more posts on the Journey From Founding Engineer to Founder.
If you’re ready to start your journey, have an idea, but don’t know what the next steps are, then sign up to join my FREE email course: How to Transform Your Ideas into Software Products. Unlike these blog post the email course is meant to provide you with a little bit more direction and ongoing feedback for me! While the course is FREE you need to sign up by April 18, 2014 to participate, click here to learn more and sign up!
