Our approach to buy vs. build
Balancing fit and effort while keeping the ball rolling.
If you were asked to described your ideal system architecture, how much of it would be off-th-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.
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.
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.
Modularity is 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:
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.
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.
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?
Subscribe to our newsletter
Never miss a thing. Get our monthly newsletter to stay up to date on company updates, new feature announcements and more.