For many years, we at IMG.LY and our partners at 9elements have been developing various applications for customers and ourselves. Often, we had to decide whether to build everything from scratch or to consider third party components. Sounds familiar?
As developers, makers and tinkerers we often tend to build everything ourselves. It seems to be in our nature and part of who we are. Truth be told, this is the point where we often got irrational.
Taking a good look at modern application development, we quickly realize that everything is getting more complex in a tremendous pace. While it was feasible to develop apps without any third party libraries back then, it has become more or less of a standard to employ third party libraries or tools that solve certain problems for us. Nowadays, there are a lot of features that are must haves and simply expected to be in your product.
Thus, we are more aware than ever when it comes to the decision whether to build or buy.
Decisions
Most often, our resources are not endless. With limited time, money, and labour power we always struggle to make the decision whether to build a certain component of our software ourselves or buy it from a third-party.
But why do we struggle? Are we sure we can do it better than everybody else? Are we not trusting the third-party? Do we just think it is cheaper to do it ourselves? Or, do we just underestimate the amount of work that is required to build that one component?
Most certainly we know that software, even a small app, can be a complex beast that is comprised out of a lot of components. Even more surely, our idea or product should stand out of the masses. So, should we really spend too much time building a component or rather focus on getting things done efficiently? How do we set the priorities?
Priorities
Probably, we want to focus on the things that set our product apart from all others, may it be a singular specific feature or a novel combination of already existing ones.
Surely, most of us will never consider writing their own relational database like PostgreSQL. But, what about features such as payment, authentication or a content management system?
Speaking from experience, most of us won’t even think about implementing payment themselves and eventually, we will use a popular SaaS such as Stripe. But, what about authentication? Would we build that ourselves?
Thinking about all the details that you need to account for when building an authentication system, it becomes obvious that more is needed than just providing a simple registration with username and password. Depending on the software we are developing, people might expect to be able to login with their social logins via e.g. Facebook or GitHub. Also, we would need to provide a way to reset passwords, send emails on registration and so on. Over time, the list of requirements will grow and we will be forced to spend our precious resources on it, whether we want it or not.
So, why not just let someone else do the job for you and solve all these problems?
Don’t we trust services like Auth0 to solve all these problems for us, or what is the reason we build those things ourselves? Evidently, if our product is an authentication system we should build it ourselves. But, let’s be honest, most of the time it is just something we need for our product and nothing we care about deeply.
Unfortunately, we know that everything comes at a price. In case of Auth0, the login data may not be any more in our possession. However, are we sure that it is really bad? We tell ourselves that we can protect our data in a way that no one else would have access, no data would be leaked and so on. At least, that is what we would be thinking, right? But, are we sure that we can protect the data better than the service whose one and only task is to care about exactly that? And what about backups? Do we really want to put our resources into creating and checking that our data is properly backed up and restorable in case of a server failure? Probably we won’t and in many cases it would be a good idea to let someone do the job who does it on a day to day basis. Being completely honest with ourselves, we realized that:
By zeroing in on one specific problem, we can build better and more advanced tools than we could by trying to solve multiple problems at once.
We experienced first hand how much time and effort is required to tackle one specific problem when we needed a photo editing solution as part of one of our projects. In that particular case, we needed to go down the rabbit hole and build it ourselves. Back then, we didn’t have any other option as there was no component available that we could have used.
Was it a good idea? Probably not for the project but while building the components we realized that others could benefit from our learnings. This is basically why we started building and advancing our PhotoEditor SDK.
Apart from the previous mentioned pros and cons about building and buying, there is also another important factor: These services cost money and most of us will look at the pricing and believe it may be too expensive. Especially, if you have to take out your credit card and start a subscription that may feel like slowly draining your bank account. Even more so if you’re a small business or startup and every additional expense poses a threat to your project as a whole. However, this is the time to really weigh your options.
Time is Money
We always hear and rephrase the good old time is money slogan. And this is true in many ways. Even if we don’t care much about the cost of our own time, we would still have to invest it to build said feature and by that might delay the whole product. Do we really want to spend that time and delay our whole product?
Ok, assuming we don’t do it ourselves and we have a team of developers and parallelize our efforts, we still need to pay for it with, and let’s be honest … money.
According to PayScale the average salary of a software developer is around 45k€ in Germany. Considering that we work around 220 days per year, each day would at least cost us approximately 200€, but to be fair it will surely be more. Depending on the software component you are considering to build or the SaaS we consider to use, we most surely would get a lot more for our 200€ than what we could build in one day. And, if we are honest, 200€ are definitely not enough to develop any feature that requires more than just a few lines of code.
Final words
Summing it up, we should definitely not just buy every component from a third party or subscribe to every SaaS, but we should weigh carefully in which cases we really have to build it ourselves or when buying is the better option.
The whole point is that whether you buy some of your components or build everything yourself really doesn’t matter as long as it’s the smartest decision for your business. And if you automatically shy away from solutions that cost you something and decide to build it yourself no matter what, that decision might cost you a whole lot more.
The good thing is, that there is a trend that third parties tend to focus on more granular problems, which allows us to make the distinct decision whether to build or buy a specific component of our application.
Thanks for reading! To stay in the loop, subscribe to our Newsletter.
