Make or Buy - An essential decision with a high impact.

In the past decades, creating custom features in custom applications was very common. However, in the last years, the SaaS market exploded with solutions for every problem.?The modern approach to creating software on the web is the composable one.

Some days ago, I chatted with Laurence Cohen ( Laurence Cohen ), CEO of raion.io. We were talking about a feature for the upcoming platform, typically resulting in deciding to buy a ready-to-use SaaS service or to create something by the own development team.

In the past decades, creating custom features in custom applications was very common. However, in the last years, the SaaS market exploded with solutions for every problem. The modern approach to creating software on the web is the composable one.

The composable architecture combines custom services with SaaS to complete an application, but avoid building everything yourself. There are even official movements like MACH (Microservices, API-First, Cloud-Native, and Headless), where top-tier companies advocate for composable architectures. These companies promote the approach to using best-of-breed SaaS and combining them with microservices.

Make or buy is not an obvious decision.

So, how do we get to a decision? First, even if many SaaS ready-to-use solutions exist, it doesn’t mean they are ready to solve your problem quickly.

This is because of our business domain(s) which, in most cases, have a lot of unique requirements, and users might have specific demands. To meet those, SaaS solutions often need to be customized. So even if SaaS is cheaper to acquire at first glance, in a total calculation, it could be more expensive to buy in terms of money and effort than it would be to build yourself.

Everything you create yourself must be maintained and will likely create technical debt early on. But this applies to complete custom features, as well as to SaaS products.

This is the reason why every product owner needs to determine time and time again the best way to go per use case.

Unknown problems mean a lot of technical debt and issues in the future

We’ve decided to go with SaaS; here is?why

In this specific case, the custom solution would need raion.io to store a lot of data and process it by custom services, which can lead to an unknown amount of problems. Unknown problems mean a lot of technical debt and issues in the future. The developer would most likely waste a lot of time finding problems that will only occur once because of their uniqueness. Here, we speak of the corner- or edge cases.

On the other hand, using SaaS would also not be worry-free, but raion.io would reduce the risk to a minimum. In my opinion, the risk isn’t even one anymore; it’s completely controllable.

I am still an advocate for keeping the core functionalities in your own hands, especially when you have a highly unique business domain model

Conclusion and personal?opinion

Even if I say it’s a decision that needs to be made every time, I tend to go with buy instead of make. Of course, this wasn’t always the case, but in the last years, I could create value with this approach and avoid unnecessary costs and problems for bitsinmotion and other companies.

But I am still an advocate for keeping the core functionalities in your own hands, especially when you have a highly unique business domain model. Of course, you can always extend with SaaS, but if your business depends on technology, take special care in decision-making!

Buying SaaS is good when you know you use it primarily as it is supposed to

A rule of?thumb

It can also be tempting to pick a ready-to-use solution because you think it fits. Still, after years of developing, you realize you have built an entire custom solution on top of an existing one, which should be avoided because that wasn't the initial intention.

Buying SaaS is good when you know you use it primarily as it is supposed to. Using an API or custom modules is acceptable, as long as it’s not feeling like rebuilding the complete solution yourself anyway.

Keep the following rule in mind:

The higher proportion of custom work on a feature is, the less likely you need SaaS.

Was this article helpful for you?

If you are interested in these topics, feel free to subscribe to my daily/weekly CTO Newsletter @ https://adrianstanek.dev/subscribe