Build/Buy/Partner

Making a wedding cake out of a cupcake. Illustration: Adrian Hogan

When presented with a customer problem to solve through technology, the age-old question when it comes to engineering & product and one that can exert a heavy influence on the success of a technology company is whether to build, buy or partner.

From one perspective, if done right it can enable internal teams to move with speed. From another perspective it can enable 3rd party platform costs to be managed. And from a third perspective it can bring valuable IP in-house, creating competitive advantages that can create a moat around the product you’re building and preventing competitors from breaching the castle too easily.

For me (with the loving backing of our finance team), the decision comes quite easily when determining whether to build or partner (we’re not at a point where we can buy) — is the purpose and feature set core to the product and platform or not? If it’s not then we look to best-of-breed platforms to partner with and if it is, we use the fantastic team we have in-house to build, iterate on and lovingly tend to from time to time to ensure technical debt doesn’t accrue to a point where it slows us.

Examples of functionality/platforms we partner with include;

• Identity (security and personal information storage is too important to do half-heartedly) — we chose Auth0 (soundbite why is here)
• Anything to do with telephony or SMS (we’re not telcos) — we chose the Seranova platform which has Twilio under the hood
• Anything to do with logging, alerting and monitoring (it’s too important to trust home-grown tooling) — we’ve gone with New Relic and Logz.io primarily
• Analytics (there is no need to re-invent the wheel) — Snowplow and Google Analytics 360 being the primary tools of choice
• Code quality tooling (because machines do a much better job at being binary than humans) — we like Codacy
• Cloud computing (because on-prem hosting is so passé) — we run our workloads on AWS

While on the other side of the fence, we trust the team internally with the likes of;

• Data (which we see as a long term competitive advantage)
• CI/CD architecture (so we can be masters of our own destiny and move with speed) — we use a mix of CircleCI, Helm, Kubernetes
• Coding — I’m a big believer that you can have 2 out of cheap, fast or good when it comes to coding and I’d much rather not do it on the cheap if it’s something core to the experience. The medium-long term return on investment far outweighs any short term tactical wins from doing something cheap and/or fast

I touched on it earlier that we make decisions with the loving backing of our finance team. In that sense we’re lucky that they back our judgement, that they trust us to know when building and maintaining something is going to be detrimental in the long run. This piece from Intercom’s blog has one of my favourite phrases of all time:

“Features are like children…once they’re born you’re stuck with minding them and saving for their college fund.”

And it’s SO true. The cost of building an Identity platform that stores a username/password and some basic data might sound trivial compared to a 3rd party platform. But that Capex cost isn’t comparing like for like. There’s a hidden Opex cost associated with iterating on it, “just” adding a new field that can be stored against a profile, regularly ensuring it meets regulatory standards for personal information storage and more importantly, ensuring that knowledge share within the engineering and product org is ongoing so that the platform doesn’t become a monolithic black-box over time that engineers are scared to touch out of a fear that something, somewhere will break and make as much sound as a tree falling in a forest when no one’s around.

We’ve all either worked for or worked with companies that have built things they should have bought or partnered for with and we’ve also had the same experience with teams and companies that have bought or partnered when it was more important to retain control and be masters of their own destiny with it.

Next time you’re at the crossroads, have a think about how core to the business the next problem you’re about to solve is and think long and hard about whether you want to build/buy or partner. It can set the business and the team up for success or it can just as easily also cause drag, inhibiting future success.

See our stacks here and here.

This story was originally posted on our engineering blog.