Build or buy software dilemma
Fine, I get it. Your bias alarm has just gone nuts. I can’t blame you — after all our bread and butter is about shipping better software products faster. If you could however turn a blind eye for a second, I promise to answer interesting and useful questions that will help you make informed decisions, not just push a certain view.
While a sea of ink has been spilled on proving that custom software is the way to go emphasizing its flexibility, it’s certainly not a zero-sum-game. Buy is rarely just a “buy”. Vast majority of the time it means to “integrate”. And since the same applies to “build”, in the end they both require similarly skilled engineering talent. And this is the very source of the dilemma itself.
Does your business currently have (or can you build a team of product) experts capable of building, maintaining, and supporting the solution?
If the answer is no (and it really is ok for it to be so) that may limit your options to just one at the start and not reading any further may not be too bad of a choice. But what are the sacrifices?
The good, the bad and the fatal
I promised you not to enter the argument of rigidity vs flexibility. And the reality is buying an off the shelf package can often make sense in cases where your business follows well-established industry practices and innovation isn’t part of your game plan. Unfortunately that’s not where most businesses are today.
In practical terms buying a ready package often makes businesses passive and less resilient. Upon a glance on the first page of Google it’s apparent that one of the major perceived disadvantages of building your own solution is the necessity to understand the processes first (instead of just pulling the trigger). My years of experience building products that succeed (and closely observing those that do not) prove the very opposite. Sure, it is absolutely a necessity to nail a problem you are trying to solve before you even get it to end users hands, but this is the very advantage.
How complex does your solution really need to be to fit your business size and needs? Vast majority of the time it’s much simpler than you realise. The reason for this is once you get passed the bridge of accepting a longer wait time and higher upfront cost (which undoubtedly is true a lot of the time), you no longer think about essentials but instead on all the nice-to-haves that the ready package didn’t allow you to have which usually account for majority of the development. That doesn’t make it a fair game and you’re not comparing like for like. Building your own solution does not justify skipping the MVP stage.
You are not your customer
Most of the time, you are not even the end user. Majority of businesses begin product development making the same fatal mistake: they try to build something that their customers want. They assume that there’s one right answer to what their customers actually want.
Reality is a great deal messier and will continually surprise you.
Cindy Alvarez, the author of Lean Customer Development bestseller writes, “Customer development starts with a shift in mindset. Instead of assuming that your ideas and intuitions are correct and embarking on product development, you will be actively trying to poke holes in your ideas, to prove yourself wrong, and to invalidate your hypotheses”.
Seemingly, just buying a solution takes care of all these problems. And indeed, if the software product you’re after is about a do-it-and-forget-it automation, the answer is just buy.
One of the core principles of product development is not to reinvent the wheel (Silicon Valley forgets about this way too often). Experience tells me however that attempts to shorten the validation cycle end with a big chunk of the product budget being spent on unnecessary pivots born out of desperation to protect the initial investment.
The typical cycle I’ve observed is that an off the shelf system is usually fast and cost-effective to start with, then most businesses eventually find that the lack of customisation relative to their day-to-day operations ultimately leads to inefficient, manual processes. So back where you started.
Even if the decision to make a slow start is made for wrong reasons, the choice is right and still stands. Unless what you’re building is so innovative it has never been even remotely attempted before (in that case we should get in touch!), always seek ways to achieve 80% of the result with 20% of the budget (and off the shelf systems are usually great at that, even if just for getting a prototype up and running fast). That way you’ll be left with most of your cash available for reinvestment into a product that will actually help you truly innovate and excel beyond your peers.
No more cron jobs, orchestrate data pipelines with Azure Data Factory
How do you like maintaining lots of bash scripts defined in `crontab`. If you worked in a team responsible for a data flow you know what I mean. If it starts with one script it is OK. But if your crontab grows and grows it is no more fun. Or maybe you are running your BI processes which are doing well in your current warehouse but you encounter problems with the optimization and there are not enough resources to scale your workers up?
Left Join for Advanced Rubyists
Every now and then you will need to keep a track of user activities in the system. This can be approached in several possible ways – one possible solution is to store them as an activity log in the database. This alone can create some challenges and may require you to use less common SQL statements in the Ruby on Rails apps like LEFT JOIN, hence I’ve decided to shed some light on it.