I’ve been thinking a lot about how to make this decision and have recently put some interesting use cases together that have really helped me internalize and solidify what I believe is a solid foundation for deciding when to build it yourself.
If the component or feature in question is crucial to your core competency or factors in to your competitive advantage, you’re probably crazy if you don’t take some form of ownership. Giving another entity control over those elements in your organization is just shy of lunacy. No one has your company’s best interest at heart other than your company.
I’m writing this because the conventional developer wisdom I’ve encountered in the past is, “Why make X, use Y, it’s already there and you’re just reinventing the wheel.”. It’s not always wrong, but it’s certainly not always right. I’ve made the mistake of reinventing an inferior alternative before and it’s taught me a valuable lesson: how to know when to build your own.
Learning From Apple
I am not an Apple fan boy. Lots of things they do frustrate me or seem like mistakes in my opinion. Steve Jobs has been the occasional target of my snarky criticism in the past. It turns out Steve Jobs is perhaps one of the most brilliant business leaders in the technology industry. He took Apple from irrelevance to the second largest company in the world in terms of market capital. That’s not something one trips into. So how’d Apple get where it is today?
Academia has shifted its opinion regarding what makes for a successful strategy. Perhaps it’s due to the change in the nature of competition or globalization or both and more. Ultimately, SWOT analysis doesn’t cut it anymore. Company’s have to focus on internal resources and capabilities and select those that are relevant in the market and sustainable in order to build their competitive advantage and establish their core competencies.
What’s this got to do with Apple? As it turns out, this is exactly what Steve Jobs was doing in practice. When he returned to Apple as “interim CEO”, the first thing he did was inform the board and his executive team that they would be killing 20 of their 24 product lines. Why? I suspect Steve knew that to be relevant and differentiate themselves they needed to focus on complimentary products that they could excel at.
Apple isn’t known for partnering with a lot of vertical partners. Sure, Steve’s not making bread boards and soldering the chips all day, but they are very, very involved in every step of every product. They write their own OS. They roll their own software. Because no one else does these things? Of course not. Is it why they’re successful? You know it.
It turns out that the specific differentiation strategy they’ve implemented thrives on the “differentness” of Apple which just so happens to be relevant to their target market because Apple is very good at industrial design and user experience. And it’s not because they have lots of focus groups or give a crap what you and I think. They establish expertise in design and produce products that they love. If you don’t like their work, you aren’t part of their target market.
Protecting Your Competitive Advantage
It’s almost formulaic really. Determine the key success factors within your market, determine which resources and capabilities relate to those factors and build your strategy around those in order to create a sustainable competitive advantage. Sustainability is especially important here and is determined by factors such as scarcity, durability and how easy it would be for competitors to transfer or replicate the capability or resource.
At any rate, the take away here is, to survive and make a profit you have to have some competitive advantage and you must ensure that it’s one that’s going to be around for a while since establishing one requires a huge organizational commitment and investment to achieve.
Build It Yourself
Let’s make this a lot more concrete and less academic and “businessy”. LMAX allows users to trade futures and commodities online. Ok, that’s a really simplistic way to look at it. Effectively, they started out as the world’s largest online bookie. The interesting thing both customer bases have is that they’re extremely sensitive to any latency in their interactions and if they detect your system is lagging and exposing them to additional risk they’ll walk away from your service and you’ll stop making money. As you might imagine, there’s a fair amount of money to be made in either line of business and so LMAX could’ve just decided to throw tons of money into hardware and vendor solutions built for insane volume. Instead, Martin Thompson and Michael Barker decided to deep dive into the very deep subject matter of high, concurrent volume at low latency. What they have created is a system capable of handling 100,000 transactions per millisecond, per server. Granted, the servers were non-trivial. I believe it was 16 physical cores with 144 GB of RAM, not exactly a typical desktop machine.
The key here is that, at the core of their value proposition is the ability for customers to make trades/bets with the least latency imposed risk as possible. Relying on a vendor to supply them with this capability vs. owning it themselves would have made them extremely vulnerable as it makes a significant portion of their core competency unsustainable: their performance wouldn’t be scarce, it would be very transferable and the durability would be completely unpredictable.
Don’t Build It Yourself
On the other hand, let’s take a look at a very different business model. Let’s assume there’s a small technology start up called Mountain Top Technology. This technology company asserts itself as a technology company and has set a long term strategic goal of building a premier team of consultants for their region. Mountain Top Tech has the difficult choice early on of deciding whether to do without, purchase or build a back-office solution that will enable them to automate some billing processes. Now, I’ve already given away the answer here, but based on everything I’ve said so far, I’m sure you can pre-formulate the argument I’m about to make against building the solution in-house.
Why wouldn’t you? You have the beginnings of a great team and they’ve got capacity; why not have them put that to good use and save the company some money. Without addressing all the issues, the main reason is that you’re committing key resources that are crucial to your core competency to efforts that won’t improve your competitive advantage, are irrelevant to your core competency, irrelevant to your market and have no tangible profit impact.
I’d be very interested in other examples that anyone felt either illustrate or disprove these principals. I think it matters a lot, especially in the open source community, and even more so in the web stack space where there are so many different web frameworks under way. I’d be willing to bet that many of them sprung up from legitimate need to support the competitive advantage of the organization vs. a developers desire to roll their own.