Our approach to buy vs. build
Balancing fit and effort while keeping the ball rolling
If you were asked to describe your ideal system architecture, how much of it would be off-the-shelf?
I admit that, for a while, my answer was… very little.
Before you judge me, I am in my thirties; I grew up way before the Internet, open source software and microservice-based architectures. Software was generally expensive and bulky…
…and I’ve always loved building stuff.
Why settle for less than tailor fit? — I argued…
But it’s 2018, and there is no shortage of applications — just take a second look at the technology landscape below.
It’s hard to believe there isn’t anything out there that ticks all the boxes, even when considering pricing. It’s also true that nowadays custom solutions can be built faster and more effectively than ever.
To buy or to build, that is the question…
In our experience, both buying and building can backfire at any time. So when we came together to build Nirovision’s architecture, we made a commitment to critically review software decisions based on a few guidelines that we’ve stuck to ever since.
Resource pragmatism
Lesson one of any management course mentions the fact that resources are limited. Nothing new there.
But even if someone is not fully assigned to own or maintain a service or application, it doesn’t mean he won’t indirectly spend time working on it:
- How long does it take to find and fix a bug?
- How many people end up being involved in troubleshooting?
- Does the language used to build it still play nicely with the rest of the architecture?
- How well documented is the solution?
- How comfortable does the team feel around it?
Only after considering all these caveats you arrive at the real time and effort allocated. It usually paints a grimmer picture.
We came to that realisation when assessing how to handle user authentication and authorisation, based on our previous experience with a fully custom solution. Spoiler alert: we finally went with Auth0 — I’ll leave the details for another post.
Just because a system is not someone’s full-time job, it doesn’t mean it involves little work.
Modularity as a design principle
Once you’ve nailed this exercise, it’s easy to logically arrive at a modular building approach. If we decide that we need off-the-shelf solutions we also have to accept the possibility of not choosing the right tool at the first shot. And even if we did, it is possible to outgrow systems or, in more drastic occasions, change direction.
We need to be able to pivot fast if we want to innovate.
Allow me to bring up an overly recited, but rarely reflected on Bezos’ quote:
Some decisions are consequential and irreversible or nearly irreversible — one-way doors — and these decisions must be made methodically, carefully, slowly, with great deliberation and consultation. (…)
But most decisions aren’t like that — they are changeable, reversible — they’re two-way doors. If you’ve made a suboptimal Type 2 decision, you don’t have to live with the consequences for that long. You can reopen the door and go back through.
— Jeff Bezos
If the architecture is built with a modular mindset, any component should be quickly replaceable, which means those become type 2 decisions.
Yes, even databases — I clearly remember the look our DevOps Engineer made when we voiced this.
Yes, even core systems.
Personally, this has been one of my biggest learnings, and what I believe is the greatest advantage of startups: the capacity to experiment, fail and recover quickly. Instead of spending a lot of time reviewing solutions on paper and going back and forth, we test them. The only way to achieve this while keeping the ball rolling is with modular, flexible architecture.
Modularity makes most architectural decisions reversible and, consequently, reduces the risk of trialling.
One final thought…
We’ve made this Buy vs. Build mindset a part of our culture: every piece of code we write or purchase is up for debate and update. That’s how we sustain the claim that the Niro app is always evolving.
Given enough time and money, your competitors can duplicate almost everything you’ve got working for you. They can hire away some of your best people. They can reverse engineer your processes. The only thing they can’t duplicate is your culture.
— Herb Kelleher
I’d love to hear about other team’s experiences. What have you found yourselves constantly rebuilding? What have you off-the-shelved straightaway? What guidelines do you use to make these decisions?
