I've seen it all. Enterprises scared of doing anything in-house. Startup engineers too proud to use a toilet if they didn't build it. In-house patchwork solutions that would make Frankenstein’s monster run in fear. 

It takes all sorts.

One thing is true for all product teams, though. They need to stop treating the product as a patchwork and start treating it like a hot rod. Sleek and powerful, it should look seamless to the outsider, but built with the best parts and service you can source, tweaked to the driver’s needs.

The New World Build or Buy

Product Manager. Founder. Engineer. We have all come across this situation: 

You need a seemingly simple solution - maybe an onboarding experience, marketing and transactional emails, user analytics, or maybe a map integration for your core product. 

You look into it and find more than a few options:

1. In-House: You have a couple of engineers who could build the tools in-house. BUT the time and cost is uncertain and you have no clue if the end product will meet your needs or be easy to maintain. Not to mention refactoring if you update your architecture. Example: Airbnb decided to build their own map view abstraction that would work on phones in developing nations. Uber has such a scale that it made sense to design a custom data store.
2. SaaS LEGO: You also have two or three ready-made SaaS solutions that could be patched together with or without some internal tooling. BUT that could run up some hefty monthly subscription costs as you scale, and integration may not be as simple as it seems (try adding any triggered event system to a Single-Page Application without a few engineer groans). Also, you may need to learn multiple disjointed systems. Example: You can link up Mailchimp, SendWithUs, and Mandrill (or SendGrid or Mailjet) to design, trigger and deliver automated marketing and transactional emails.
3. Open Source Jitters: You have a not-so-slick open source solution that requires quite a bit of developer work, but, well, it’s free. BUT it might stop working with its API access, functions might become deprecated, or it might entirely stop being supported or updated. Example: There are over 73 open-source tooltip plugins, but try finding a full-on in-app onboarding solution that has the same data collection, reporting, and support that you get with a cloud-based SaaS solution. I mean, open-source is often like a Vespa. It can get you to work, but sometimes it rains.
4. The Connector: You even find the holy hand grenade of SaaS solutions that promises to simplify your life by connecting all the other SaaS solutions together for you at the flick of a switch. BUT it can nearly double your cost, does not integrate with everyone, and you have to upgrade for certain integrations. Example: Segment promises to integrate many analytics, marketing automation, CRM, and even hosted business intelligence database services with a single integration. For the most part this is true in my own experience. I have, however, seen large organizations choose hybrid SaaS/in-house alternatives due to how much it costs as they scale. 

Welcome to the new world version of Build vs. Buy. Whether startup or enterprise, it can feel a bit like building a rocket ship with pricey LEGO sets and melty duct tape. What it really is, though, is an opportunity to build a hot rod of a product no matter your budget or timeline.

Hearing Voices

Whether you are a 30 person startup or 1,000-person enterprise, choosing a tool is really only half the battle. You also need to make a compelling business case and sell the story internally. You can hear the voices, now:

“Why should we pay these ridiculous prices now when we have engineers right here?”

“It is going to be more trouble than they are telling you.”

“We just spent three months building a solution last year! It may not be perfect, but you want to just throw it out?”

“$30,000 sounds like a lot. I don’t think we can approve that.”

“What if they hike prices on our subscription?”

The fact is that your team’s small Build vs. Buy decisions add up over time. You have no idea what your architecture will look like in a year, let alone two. Making choices that hamstring your flexibility can be costlier in the long run. Then again, maybe you need to defer those costs as a scrappy startup or new project division. 

So, how do we navigate this smorgasbord of alternatives and gotchas?

Let’s take a look at a few questions to ask yourself and some doses of reality.

1. Does using a third-party vendor compensate for the engineering, building, and maintenance costs?

“In the long-run, we are all dead.” - John Maynard Keynes

It can be difficult for any startup or new team to think about long-run costs and “net present value” of their decisions. In a startup, the “long-run” can mean less than 1 year, and - as the renowned economist John Maynard Keynes put it -  “In the long run, we are all dead.”

Take two examples:

1. Startup: If a startup builds a customer feedback tool in-house now, they would save $1,000+ per month now over the SaaS solution, but while their equity-paid developers will build the product now, they will need to hire developers to maintain, QA, and update (or even have to refactor) the tool going forward. Those are expensive development hours that could be used for the core product, and will certainly cost more than the subscription cost, both in dollars and strategic flexibility. Recommendation: They should buy the SaaS solution...Right? Not so fast. The startup only has enough runway to pay payroll and current bills for the next 3 months until they hopefully get their next funding round. They also need the tool right away. So, most startups will build in-house.
2. Enterprise: An enterprise product team, on the other hand, may have a 4-month release cycle and a 2-year product version lifecycle, plus a service contract with their clients. They can make that net present value calculation of recurring subscription costs versus ongoing implementation, maintenance and refactoring costs. Recommendation: Subscribe to the SaaS solution. They actually have the cash flow to make the cost-effective decision in the long-run.

“Move fast or die.” - Every business & startup pundit ever

On the other hand, your team’s greatest resource is your speed and agility. Tying up your engineers with building and maintaining custom tools and add-ons that other companies have invested 1-2 years in perfecting can be a huge drag on your ability to build core product features.

I cannot tell you how many times I have seen an engineering team start building a tool, then continually put off its completion to add a new feature for a customer or fix important bugs in the system. In the end, weeks or months go past without the feature and the team might end up implementing the third-party version anyway.

2. How good is “good enough”?

“Performance is a feature.” - Jeff Attwood, Co-Founder of Stack Overflow

Users Care

Know your team’s abilities and what your user values. If you need to get your Enterprise software feature used by as many people as possible, maybe that jQuery plugin tooltip is enough to get user adoption. If you value user experience (as you should) or need the experience to move smoothly, adapt across browsers and devices, and always function as expected, you might want to pay for that third-party solution.

Your Team Cares

Your team can build the most custom analytics solution you can think of, but if it does not look professional or work quickly and reliably enough, you will not get the adoption and utility you wanted. Not to mention that you need to have an internal support team or risk engineers being distracted from value-adding work.

3. What is your burn-rate?

You can make all the calculations you want, but the fact of the matter is that if you add up 10 different expensive SaaS solutions, you might run out of cash.

This does NOT mean that you should choose not to use third-party services, though. If it is a strategic benefit for your company and will make your team faster, your product better, and your headaches less frequent, sell this story to your investors or internal budget-handlers. There is an ROI story for a lot of the services out there. They cost what they do for a reason. 

4. Is that the final offer?

SaaS vendors want your long-term business. In fact, the lifetime value of your business over years is the core of their business model.

If you need a break until your next funding round or some time for a free trial to test out their services, ASK FOR IT. You would be surprised how often a little reasonable negotiating works. 

I have advised both Fortune 500 companies and startups on selecting vendors. These up-front negotiations have saved anything from $200 for a pre-seed startup with no runway to 10s of thousands of dollars for enterprises. Adding trial periods also helped avoid poor Build or Buy decisions.

One caveat: Don’t be a jerk. Your providers are your partners in the long-run, and although you are a customer, they will not provide you great service if you ruin your relationship up front or they think they will get squeezed by you at every turn. 

Build or Buy Is Dead. You Need Both.

I mentioned earlier how Uber needed to have a custom data solution at its large scale and with logistics being a core of its business - but Uber still uses Twilio for texting and other user communications (and pays a lot for it). Why? It works. It works well. It is certainly not the only link in their communication chain, but it is one thing that they can rely on and not have to worry about, even at scale. A lot of the issues with old-school build or buy are gone with scalable SaaS solutions and layers and layers of providers linking them up. We live in a beautiful time. Do not complicate your life and ensure you are spending your efforts working on the parts that will really make your hot rod the one to beat.