One problem that all developers and companies struggle with is trying to decide if they should “build it” or “buy it”. Software developers love to build things. That is what we do! Their natural reaction tends to lean towards building things. We are also always up for a new challenge.
There are very good reasons for building or buying software. There are also good reasons to use open source projects, which is a third option!
I started my last company in 2003. In the early days of that company, I decided that it was easy enough to store customer credit card numbers in a database table and process them via Authorize.net. Simple stuff, right?
Billing systems always seem simple. Until you have to figure out how to handle if someone cancels in the middle of a billing cycle, switches plans, free trials, discounts, and a million other little things that add up to a nightmare.
What we did at my last company was also way before PCI compliance. The idea these days of even touching a credit card number sounds like a terrible idea. Plus, in my new company Stackify, our billing needs are much more complicated.
In my opinion, the last thing you ever want to build is a billing system.
A few years ago, I was talking to the CTO of a really large software company. I was actually having a whole conversation with him on this topic of build vs buy. Because they had so many employees, they felt that it was cheaper for them to build software rather than pay expensive licensing fees for every one of their employees. They had thousands of developers. Hiring a couple more was no issue to them.
He said they went as far to build their own version of Excel. This literally about knocked me out of my chair. These days there are lots of Excel alternatives, such as OpenOffice, Google Sheets, etc. OpenOffice is free and definitely a good alternative. I think they went down the path of writing their own spreadsheet software before free alternatives like OpenOffice came to market.
These days, perhaps they are a major contributor to OpenOffice. This is why open source products like OpenOffice exist. It doesn’t make sense for someone to make their own version of Excel, but it might make sense to work with several other companies as a community to build an open source solution.
These days, developers use a huge array of open source tools to actually build new software. Virtually every programming language, including .NET, is now open source.
There are also a lot of open source monitoring tools that developers can use.
In the old days, most people used the open source monitoring tool Nagios for just about everything. Not because it was good, but because everyone used it. These days, monitoring has morphed in two directions: application monitoring tools vs infrastructure monitoring tools.
Infrastructure monitoring is still pretty simple. It is primarily based on monitoring servers, storage, firewalls, and other hardware. Some also support monitoring key metrics from things like SQL, Redis, etc. Using Nagios, PRTG, Zabbix and other tools are pretty sufficient for a lot of people.
Application monitoring is much more complex because it requires several sources of data. This includes basic server monitoring, metrics from your application runtime, application logs, application errors, and code-level performance data.
Building your own application monitoring stack is hard because it requires so many pieces. To build your own, you would have to combine things like Nagios, Graphite, Elasticsearch, StatsD, and Sentry. You would still need add an APM solution to the mix to get the code-level performance data.
Trying to correlate problems across all the tools and keep your entire team trained on all of them is nearly impossible. These are key reasons why so many development teams are signing up for Stackify Retrace. We combine all of these key features into one application monitoring platform. Retrace is also extremely affordable, which makes it a no-brainer decision.
Most people would say that you never want to build anything unless it provides strategic value to your company. Like most companies, we use products like Google Analytics, Zendesk, Hubspot, billing systems, appointment booking software, chat, and other things. Trying to build any of these would be a pretty huge waste of time.
Sometimes you do need to build things though. A friend of mine has a company that relies heavily on partners to sell his software. He needed a really good way to distribute information to these partners and keep them organized to sell his software. Having success with these partners was mission critical to his go-to-market strategy.
After doing some research, he couldn’t find any off-the-shelf solutions to manage these partner relationships. He had to build it. It was very strategic to his success. The product he built around managing partners ended up being so successful that it turned into a second software service that he could sell!
I know someone else that has a business that buys a lot of concert and sports tickets and resells them. They buy them all with credit cards, which causes them to accumulate a massive volume of credit card points. To help optimize the value of the points, they figured out how to sell them for a premium. As entrepreneurs, they decided to make a business out of that.
This same entrepreneur sent so many tickets with UPS and Fedex that he also figured out that many times they were not being delivered on time. If the shipping carriers don’t deliver on time, you technically are due a partial or full refund of some form. They also spun this out into its own business.
For some companies who are run by very entrepreneurial leaders, building something in house could lead to a new profit center!
One of the great analogies I learned from a coworker is that every line of code that you write is another line of code you have to forever carry around with you. You have to support that code. It weighs down your backpack as you are trying to climb the mountain.
What is your time worth? If you can spend $100 on a 3rd-party component to send FTP files or something, why spend many hours writing your own version? Spend a few bucks on something that you know will work and you also don’t have to support.
Opportunity cost is another big factor. What could you have gotten done that would have made a big difference to your company?
I could easily write my own version of a lot of things. But the quality of it would never be the same. Someone who wakes up everyday focused on creating the best X in the world is always going to do provide a much higher quality solution than I would cobble together.
[adinserter block=”33″]
As software developers, we love to build things. It is in our blood to say “yeah, I could build that”. Building things that are not of strategic value can be a distraction and definitely take away your opportunity to work on something else that could have been very strategic.
One good reason to build something in house is if you think you could sell it to other companies. Smart entrepreneurs are always looking to solve problems and build businesses. Learning first hand how to solve problems that others have is a good way to start up a new business.
Working with other companies on open source projects is another great solution. Building your own version of Elasticsearch would be a huge undertaking. Forking it or submitting a pull request with a new feature would be a great idea.
Stackify's APM tools are used by thousands of .NET, Java, PHP, Node.js, Python, & Ruby developers all over the world.
Explore Retrace's product features to learn more.
If you would like to be a guest contributor to the Stackify blog please reach out to [email protected]
