Speed Up Software Development and Scale Faster by Investing in Infrastructure

This post is based on my latest book: How to Transform Your Ideas into Software Products

Last year when I planning my birthday party, I waited until the last minute to decide whether to bake a cake or buy one (my favorite kind of cake is German Chocolate). I called a couple bakeries to ask if they could bake a cake with a 48-hour notice. Many said it wasn’t possible, and the ones who could do a 48-hour turnaround didn’t have German Chocolate.

I decided I’d bake the cake instead. I looked up several recipes, read through them, and realized that I needed to bake the layers, make the coconut pecan frosting, frost each layer, and then assemble the whole cake. I’d also need to head to the store to buy all the ingredients and a cake pan.

It would end up taking me 2 to 4 hours — time that I didn’t have!

I decided to call upon the help of my good friend Betty Crocker. I went to the store and bought pre-made coconut pecan frosting, chocolate icing, a simple cake mix, and a single-layer square pan that would produce a cake large enough to feed 20 people.

When I got home I “baked” it. It cost me $10 and took about 1 hour. I served the cake to my friends and no one was the wiser. They thought it was delicious!

Software is like a cake: you can choose to make it yourself from scratch, you can pay someone else to make it for you, or you can opt to buy some ingredients and then assemble it to meet your needs.

Over the past 10 years of my career, I’ve built, launched, and scaled a number of software products. While I love the process of building software just as much as I love baking a cake, I’ve learned that I cannot build everything because of the following constraints:

• Time: Successfully shipping a product without sacrificing quality takes time.
• Resources: My team and I have limited bandwidth.
• Budget: I’m working with limited capital.

I’ve been faced with these constraints at startups and big companies, so I believe they’re ubiquitous problems. I’ve found that in some cases, like common infrastructure projects, it’s best to purchase software from a vendor, but sometimes building in-house is the clear winner.

So, when should you build and when should you buy?

Let’s first take a look at some situations where purchasing off-the-shelf software will save you time and money.

Travel Back in Time

My life and the lives of other engineers back in 2006 was pretty difficult. While I was working at my first startup, Mint.com, my team and I had to do ALL of these things 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
• Build a campaign management system to send out notifications via SMS or email

Being a small, scrappy development team meant that we had to balance infrastructure projects with 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, 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 also helped keep my current team pretty lean. Back in 2010, when I was just starting to build BizeeBee, I thought I’d need to hire a DB administrator or a DevOps person. When I interviewed a couple candidates, they were pretty candid and recommended products for me to purchase instead of hiring them. They didn’t want to reinvent the wheel!

How much cheaper is it really?

Here are a few of the products I’m using right now: New Relic for performance monitoring,Airbrake or Nagios for site monitoring, Loggly for managing log files, MemCachier for caching, and Mixpanel for tracking analytics.

Let’s do some simple math. I’m paying about $10-$100/month for roughly 10 products: that’s a max bill of $1000/month. Compare that to the $5,000 to $10,000/month investment I’d have to make in hiring a developer to build, test, and maintain a code base. Not to mention how long it would take to actually recreate the depth of detail each of these products offers!

The monthly cost is much cheaper than building them in-house.

The next time you’re thinking about building an internal tool, instead of jumping into building it, find out if one already exists that you can buy. You can look in a marketplace like Heroku, and if you don’t find it there, then I’d also highly recommend perusing through GitHubrepos. Chances are someone has already built it in the form of a gem, plugin, or open-source product.

Do some due diligence!

If you can push a button and have the product automatically integrated into yours, then you’re pretty much good to go! But if it’s a product that requires integration, meaning that it’s an API, gem, or plugin, that’s when you need to take the time to do a little bit more investigation.

Example of how easy it is to add on Memcachier in Heroku.

Here are 5 questions that you MUST ask:

1. Who else uses the product?

I want to see some social proof that other companies or developers have been able to integrate the product. Here’s an example of a great customer page from Stripe.

Stripe’s customer page.

But testimonials don’t quite tell me how long it took them to get the product up and running. I know that integration time might vary depending on the scale of the company and size of the dev team, but I’d still like to have a ballpark estimate.

So my next question would be:

2. How long does it take to integrate?

To answer this question, I’ll start by calling up some of their customers, starting with people who are in my network.

If their customers aren’t in my network, then I’ll just send out a short email mentioning that I noticed they were highlighted in a case study or testimonial and asking if they’d be open to a quick call. I really just want to know what their decision-making process was, how happy they really are, and how similar of a situation they are in to mine.

Then I’ll try to get a sense of the time it’s going to take me and my team. To determine how steep the learning curve is I’ll take a look at the documentation. Here’s an example of a good documentation page from Firebase.

Firebase’s developer documentation page.

Firebase also does a good job of answering my next question.

3. Is the API, framework, plugin, gem, etc. compatible with our tech stack?

Firebase makes it easy for me to quickly navigate and see examples based on my product’s tech stack.

4. How do they handle customer support?

Everyone says they offer great support, but I want to know exactly what I’m going to get. Some offer 24-hour email or live chat support. Others provide a dedicated account manager, but sometimes that costs a premium.

While I appreciate hand holding, I’m also OK with diving into tutorials (preferably video tutorials), but I want to know that they are up-to-date! So, I’ll check when the tutorials were published or updated.

I also 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. Knowing what is coming up is a nice-to-have, but not a requirement, because I know a lot of companies are reluctant to tell customers their feature launch plans. Instead, I want to know if they have a newsletter or blog dedicated to developers and how often they post, because it will contain product updates and enhancements. Heroku does a great job with this.

Heroku’s developer-centric blog.

If you’re using a gem or a plugin built by a single developer, you’ll definitely want to take a look at their GitHub repo and look for things like how many people have forked the repo.

Some gems or plugins may be neglected, but I have come across many where the developer is responsive because it’s in their best interest to fix the issue and maintain a quality product. To find out, read through their changelogs and README files.

5. What will the experience be like for my customers?

Remember, you are always responsible for your customers, even if you’re using a vendor’s product, and especially if they are housing some of your customers’ data.

I prefer using white-label solutions so that my customers feel like I’m taking care of them, not sending them off to someone else. Often there is a cost to removing the product’s branding, and you’ll want to figure out if it’s worth it.

If you opt for a co-branded experience, you’ll want to make sure that the customer is going to have a good experience and that they trust your vendor.

Uptime is another important factor. Check to see if the vendor has a status page. Here’s a great example of Olark’s status page.

Olark’s status page.

What to watch out for

Depending on the size of the product you’re going to be integrating, you may have to sign a contract. If you go down this path, be careful about SLAs (service level agreements) and what is and isn’t included. If you can, opt for a short contract and make sure there are clauses that will let you renegotiate once the contract period is over!

If the integration is based on data, make sure you have a sense of its accuracy. Some vendors are notorious for providing amazing demo sandboxes, but their production environments are often throttled, have uptime issues, or just have poor data quality.

Many people opt to build their product on a third-party platform in order to attract an initial set of customers. If you chose to go down this path, then make sure you understand the Terms of Service. There have been a number of applications and gaming companies that have unfortunately had to shut down their business after the platform provider either made one of their products obsolete or changed the Terms of Service, essentially making it hard for companies to do business with them.

So what should you buy vs. build?

Honestly, you should buy anything that isn’t core to your product’s value proposition or doesn’t speed up its development time — such as gems or plugins. Here are some examples of best-in-class products I’ve purchased and integrated into my products over the years:

• Application Hosting and Database Management: Heroku
• Billing: BalancedPayments
• Email: MadMimi, MailChimp, SendGrid
• Analytics: Mixpanel
• Performancing Monitoring: New Relic
• Support: Olark, ZenDesk
• Load Balancing: f5

If there isn’t a good solution provider or you have a particular business process that precludes you from buying a solution, then consider building it. If you go down the path of building, you’ll want to factor in the amount of time it’s going to take to build and maintain. People often overlook the time it takes to maintain in-house.

Remember: time is NOT free.

When you outgrow off-the-shelf products you’ve purchased

You might discover at some point that an off-the-shelf software product doesn’t meet your needs because you’ve grown a lot, your business process has changed, or you have a new set of needs that it’s not addressing.

Before you decide to build, you can talk to the vendor to see if they have a more advanced solution that will meet your needs, or if they’d be willing to build and maintain it for you. This might come with an additional cost, but hopefully it’s less than what you’d incur if you built it yourself.

You’ll also want to see if there are other vendors who service businesses that are similar to your new size or share the same processes.

If none of these options work, then you’ll need to come up with a plan for phasing out the vendor’s product over time and building a custom solution in-house.

Now it’s your turn to decide whether to build or buy!

Start by making a list of what you absolutely need to build and is core to your product. Next, make a list of things that you’d consider buying, like common infrastructure or products that may replace the need to build an internal tool.

Learn more about the process for building, shipping, and selling software products in my book How to Transform Your Ideas into Software Products. It will give you a step-by-step process for validating your ideas and bringing them to life, plus save you the agony of having to learn it all on your own!