If You Buy It, Users Will Still Come

A number of years ago — I think it was 2008 — I went for a job interview at NorthJersey.com, a popular news website in New Jersey. It was for a web content editor position. I remember sitting down with the managing editor, who also oversaw the print newspaper, The Record. We had a deep conversation about the state of the industry and where it was going in terms of digital — whose predictions were right or wrong, I can’t remember.

I also interviewed with one of the deputy web editors, who I do recall having an elitist mentality. After the interview, I remember getting an email from the woman, who viewed the source code of my website and found some Javascript code, which had the author’s copyright info. She wanted to know why I was using someone else’s code (she actually copied and pasted it into the email) to design my website. In fact, she made the assumption that my entire website was a sham and perhaps I didn’t code any of it.

Javascript

Looking back, it’s crazy to think I probably didn’t get the job because I had embedded someone’s open source Javascript code on my website. To this day, I can still code in HTML and CSS — some things you can’t unlearn, even as you move up the career ladder. I ended up uncovering the original job description the other day, which asked for HTML experience, not Javascript. That means that even being able to integrate the Javascript code meant that I was overqualified for the role.

My response to this deputy web editor was simple: efficiency. While I had coded the site myself, the Javascript was complex and so rather than coding that myself, I simply used someone else’s code. (I also think I was legally required to keep the copyright info in there, but there’s only so far you want to go in a response to a prospective employer.)

I have an idea why I thought about this for the first time in years a couple weeks ago — that managing editor’s name popped up in my LinkedIn feed. I think it’s also because across all industries I’ve worked, we get into this conversation of build or buy.

Build vs. Buy

Build is ideal — you control every aspect of the code and experience. Buy is often more expensive, but you give control to the experts, who will continue to innovate while you’re company is not even close to catching up. That need to keep up also won’t creep into your team’s development queue, freeing them to focus on your own “product.”

Do you build your own analytics solution or go with Google Analytics? Do you just implement the SDK of your preferred push notification vendor or build something using Amazon SNS? Do you integrate open source Javascript code or write your own version? I’ve experienced these questions and more. The answer is: it depends.

What I will say is it’s much more accepted these days. If it wasn’t, GitHub, an open-source repository that anyone can tap into for code, wouldn’t be so popular. Neither would third-party APIs (The New York Times did a great paid post on them) or SDKs. As I teach my students at NYU: think about the early days of e-commerce, when small businesses had trouble selling online because they couldn’t process payments. There’s no way a potential customer would send their credit card details via email, meaning buyers would have to call the store to provide their details — and we think paying on mobile today has friction! Now any business or individual can just sign up for Stripe or PayPal and start collecting revenue in minutes.

For a long time, Winery Passport and Brewery Passport used Parse to power its push notifications. When Parse announced it was shutting down, it hurt. They gave developers a year to get off their platform, but where was I going to go? After speaking to the founder of another popular wine app, they recommended Amazon SNS. I would host on a third-party but manage the code and experience myself — no SDK. It was the best move I could have made, especially considering I now have more control over when and which notifications go out.

Snap Goes Buy Route

The other day it was announced that Snap is going to spend $2b with Google to use their cloud storage solution and another $1b with Amazon. Why is that as opposed to building out their own storage center? Not only would that take a lot of time (one could argue that this buys them time to build their own solution), it would also be costly, cash which they need to have on their balance sheet as they prepare to IPO. Once they do IPO, that will infuse the company with capital to potentially build their own infrastructure, if they choose.

Additionally, Snap is a camera company. They’re not a cloud storage solution. They are leaving the storage space to the experts and focusing on what they know best. And this is precisely what companies forget: unless you’re a technology company, focus on what you know best, or ways to amplify your product or service.

Netflix uses Amazon to host their data. AirBnB and Spotify use them, too. Even Apple, which has their own cloud service, uses a third-party to house a lot of their data. (This very site and all of my apps are hosted on AWS.) This allows these aforementioned companies to focus on entertainment, home sharing and music — not a storage infrastructure. Uber, on the other hand, built theirs from scratch, and have publicly said it’s saved them a lot of money in the long run.

I had coffee with a senior executive with the Google Cloud service a couple weeks ago. He explained that Google’s sales pitch to potential clients is that they’re Google. If they can power some of the world’s most widely used products (seven have more than one billion users), they can power anything, and reliably. I buy that.

I’m not saying build is better than buy, or the other way around. What I’m saying though is that your company needs to remain focused. It needs to know what its primary objectives are and its mission is. If building can’t get you closer to or aligned with those, it must buy. The company, however, must not feel like it is cheating by buying. It must feel efficient.

Snap is definitely making the right decision. So was using Javascript on my website in 2009.

Post Post: After I wrote this, Wired Magazine wrote a feature on The New York Times. There were some similar thoughts to build vs. buy (not in those exact terms, but are alluded to) in the piece from my collegues.

Sign up for my bi-weekly email newsletter where I’ll share what I’ve written about or read from around the web related to digital media, tech strategy, emerging platforms, sports & more. The newsletter is sent 8 p.m. ET on Sunday and appears on ScottStanchak.com 10 a.m. ET on Monday.

Listen to This Post
Voiced by Amazon Polly

Related Content