Buy vs Build?

Photo by Maja Petric on Unsplash

When working in any fields that involve technology, the buy vs build conversation inevitably comes up. There are usually two competing sides: The grizzled veterans burned out from multiple drawn out feature-creep ridden projects that will pay anything for any service if it avoids the “If this button were just blue it would be perfect” conversations and the overly ambitious engineer that estimates everything to be done in less that 6 weeks “Complete alternative OS to Linux? — 4–6 weeks max”. Both sides are passionate and have good reason to be — software development estimation is extremely difficult and most often wrong and conversely building your own solution has some benefits if done correctly. When given such polarizing options — what should you do? This situation represents a False dilemma in which only two choices are presented as options when in fact there is at least one additional option.

I would propose a third option — Renting

By renting, I am choosing to follow the path that allows me to achieve the desired outcome in the shortest amount of time without creating unreasonable vendor lock-in. The way this would look in application would be to first spend some time value stream mapping— which you need to be doing regardless. After you understand the needs and how software would fulfill your every last one (never gonna happen) you get to work on breaking it down into smaller pieces that can be offloaded where it makes sense. For a content heavy project this could mean using a SAAS CMS like Contentful or Prismic and building your own GraphQL layer on top of it.

Down the road if you find something that better suits your needs, you identify what it would take to support your legacy clients, and move to your preferred SAAS or custom develop your own after you gain the knowledge of what you didn’t know the first time you’ll actually be delivering value earlier to your user while gaining insight on what the “ideal solution” would be.

Which parts you “rent’ should be decided based on acceptable lock-in and things your team can currently do best. If you have a team that has a history of building top notch UI, but not great at understanding how to build backends that scale — you might want to offload the backend. Conversely, you might have difficulty leading towards a UI because of competing desires among teams and having a standard to learn from could be your best bet.

This is something I’m currently pondering and I figured I would throw this out to the wonderful Medium Community — I am specifically wrestling with a project around an API-first CMS (preferably GraphQL over a typical REST API (see my example didn’t come out of nowhere) — feel free to plug your product / solution / suggestion in the comments and play nice everyone.

Hoping to do this as I get inspiration, and need advice. Also, I’ll be using images that don’t make sense in context, but do if you figure out which term I searched for on the amazing Unsplash — which is a wonderful resource for pics of hipsters contemplating. Thanks!