The great martech debate: Build vs. buy
Debating whether you should buy, rent or build your own martech software? Columnist David Rodnitzky explains why building your own martech software is almost always a bad idea.
I recently worked with a very well-known “unicorn” (a private company valued at more than $1 billion by investors).
The unicorn’s founder proudly told me that they were building their own AdWords campaign management software and that they had even hired an engineer from Google’s AdWords team (because, you know, one engineer probably knows the entire AdWords code set…). I did my best to dissuade the company from this strategy, but my arguments were ignored.
It’s possible that the unicorn will build an amazing piece of software that will outperform any other tool ever invented, but it’s more likely that the company will waste millions of dollars, hours of precious engineering time and lots of advertising dollars before they come to the conclusion that they should never have tried to build their own campaign management software in the first place.
My experience suggests that it almost never makes sense to build your own martech software. In this article, I’ll explain the strong arguments against “build,” why you should be in favor of “buy,” and detail the limited use cases where building is a good strategy.
Build problem #1: Creating a legacy, in a bad way
Software development is never, ever done. Think you’ve built an iron-clad integration with the Facebook API? Just wait until Facebook completely rewrites the API — you’ll have to follow suit! The back end you built five years ago was best-of-breed then, but now it’s out of date.
And what happens when your lead engineer — the brains behind your entire system — quits? You’d better have really good documentation, or your new engineering team will have to spend most of their time reverse-engineering your entire system.
Building good software is hard and expensive, but maintaining it and keeping it best-of-breed is just as challenging. And every penny you put into your legacy software puts more pressure on your company to keep the software alive, even if it’s clear that there is third-party software out there that would do the work better and for less money (It’s a form of confirmation bias).
Build problem #2: Is this even your core competency?
If you had to describe the raison d’etre of your business in one sentence, what would it be? If the answer is something other than “building great martech software,” you probably shouldn’t be devoting many resources to building martech software.
You may have some great ideas around how technology can improve your marketing, but if building software is going to be one of many priorities in the company, the odds are that the finished project isn’t going to be as robust or as useful as you imagined it to be. Shortcuts will be taken, deadlines will slip, and you’ll have to settle for “good enough” software as your engineers juggle demands from other teams.
And again, if the purpose of the business is something other than building martech, your engineers will likely deprioritize your requests anyway.
Build problem #3: Resources you probably don’t have
Do you have hundreds of engineers, multiple data centers and access to trillions of data points? No? Guess who does: Google and Facebook! Both of these companies have put large teams together to build great martech. (Google is building an entire tech stack; Facebook is focusing on Facebook campaign management.)
No matter how great your engineering team is, Google and Facebook can simply use more engineers (and their engineers are pretty good, too), access better data and crunch more data than you can. The odds are against you.
Build problem #4: Benefiting from the race to the bottom
I generally think building martech is a terrible investment for any company for the reasons stated above, but by buying instead of building, you can take advantage of someone else’s misfortune.
Here’s the pattern I’ve observed with third-party software companies: Company A builds a great tool and sells it at a premium upon launch. The success of Company A’s platform inspires a lot of copycat companies who release the same software but at a lower price. This requires Company A to lower its prices and improve the existing software. Copycats respond by copying the new improved software and further lowering their prices.
This is known as a “race to the bottom,” where software providers rapidly improve their solutions while rapidly reducing their prices. In the end, the software providers have a hard time making a profit, but the marketer gets to continually realize cost savings while switching at will to whichever software provider currently has the best offering.
Why would any company want to build their own software when they can buy or rent awesome technology for pennies?
Now that I’ve laid out the argument for why renting martech is so much better than building your own, let me add a few exceptions to that rule.
When to build #1: Interoperability
One reason to build martech is to connect the dots between all of your third-party tools and your internal tools. For example, maybe your point-of-sale (POS) provider doesn’t integrate with your feed optimization tool.
Building an ETL (extract, transform, load) to connect two systems to improve your data could be a worthwhile investment. The challenges of updating software and avoiding legacy commitments still exist, but this sort of development may be important enough to override the risks.
And keep in mind that in this example, you aren’t building a new mousetrap or competing against Google or Facebook’s engineering team; you are simply trying to connect two software solutions.
When to build #2: Customization
Let’s say you are an umbrella manufacturer, and you know that you sell 50 percent more umbrellas when it’s raining outside.
Building a weather API integration, and then pushing the data into your third-party campaign management tool, may be a great competitive advantage that makes your third-party software even better.
When to build #3: You Are Amazon or eBay
If you are a giant company, and you can afford to assign a small city of engineers to building great internal software, then by all means, try to build the next great piece of martech. There may even be strong competitive reasons not to share your data with a third party or Google/Amazon/Facebook/Apple.
But we’re probably talking about fewer than 20 companies that fall into this category, so most people reading this can’t use this argument.
Ideas are cheap; software isn’t
More than 10 years ago, I developed an algorithm for AdWords bid management. (Ping me, and I will send it to you.) It was a truly awesome algorithm, and I’ve yet to see an algorithm that beats it. And so I got the company where I was working to give me a million dollars to build it.
After a year of struggling with the AdWords API, back-end stability and countless meetings trying to explain the algorithm to engineers who had barely heard of SEM, we gave up. It turns out that it is a lot easier to invent an algorithm than it is to make it actionable through software.
As a postscript, the COO of the company saw how painful it was for us to attempt to build this software and left and founded his own campaign management software company (which went public but has since struggled with the “race to the bottom” that affects all martech). And guess what? At my current agency, we use that software today and have nary an engineer in-house.
Final note: I want to give credit to Jonny Chan from ipsy for suggesting this topic!
Some opinions expressed in this article may be those of a guest author and not necessarily Marketing Land. Staff authors are listed here.
Marketing Land – Internet Marketing News, Strategies & Tips
(41)
