Software: Make Or Buy?
Software: Make Or Buy?
My experiences after 15 years of decision-making
As a CTO in a small to medium-sized business (SMB), I've spent the last 15 years making tough decisions about whether to build software in-house or buy existing solutions. This "make or buy?" dilemma is something every tech leader faces at some point, and it's never a one-size-fits-all answer, and it hurts me a lot.
I would recommend thinking deeply about this topic since decisions are long-lasting and often rigid to revert.
Additionally, I want to warn you to postpone the decision to a later stage when there are:
More Budget
More Time
More Developers
More <Fill in the word> …
This situation will never be the better one. There will always be the next challenge, problem, or obstacle. The sooner you learn and understand, the earlier you can make the right decision for the future.
PS: I still work down technical debt caused by decisions made before I was in place; those things are long-lasting.
In this article, I want to share my experiences and what I've learned and hopefully help you make more informed decisions.
The 'Buy' Approach
Let's start with the most straightforward option: buying an off-the-shelf product or subscribing to a SaaS (Software as a Service). At first glance, buying seems like the easiest path. You get a ready-made solution a minimal setup, and you're off to the races.
Pros:
Less Initial Effort: One of the most significant advantages of buying a solution is the speed at which you can start. There's no need to build anything from scratch, saving you time and effort, especially if you're short on resources.
External Maintenance: Another benefit is that someone else is responsible for maintaining the product. They handle updates, bug fixes, and new features, allowing your team to focus on other priorities.
but…
Cons:
Limited Control: However, this convenience has a downside—you're often not entirely in control. You depend on the vendor's roadmap, which might not align with your needs.
Extensibility Issues: Many off-the-shelf solutions aren't very flexible. If you need custom features, you might be limited by what the product can do or, worse, stuck with an overly complex workaround that feels like duct tape on a sinking ship.
Legacy Problems: Over time, extending a boxed product beyond its intended use can lead to horrible architecture and technical debt. I've seen this happen when companies try to make a product do something it wasn't designed for, resulting in a mess that's hard to maintain and upgrade.
When to consider Buying?
For me, after all these years, I would ask myself the following questions:
Does the solution fit all my requirements?
Is the dependency on another company/team a risk I am willing to take?
Will buying help me significantly speed up the time-to-market (TTM)?
(Target should be 60–80%)Does the solution cover at least 80% of my requirements on day one?
Am I sure that buying a product won’t cause me to develop around it in a way that starts to hurt me, and I would have better build it myself?
(Those solutions are the weirdest ones; I inherited them; I know what I am talking about 😀)
When to avoid Buying?
Avoid buying a solution of any kind when you have a combination of the following:
Complex changing Requirements.
You already have a strong team of developers.
Long-term plan for your software endeavor.
(5–10+ years)The buyable product can’t grow with your needs.
The buyable product initially doesn’t cover 80% of your needs.
or…
You want to sell the product as a software solution.
Rule of thumb:
If you want to sell it, build it. I stopped believing in “Buy” or composable when you want to sell the software.
The 'Buy the Making' Approach
Another option is to outsource development to another company or team, essentially "buying the making" of your product. This can seem like a great middle ground between making and buying. Personally, I try to avoid that since I am on both sides of the coin often and dislike both outcomes.
Pros:
Less Hassle for Initial Development: Theoretically, outsourcing means you don't have to worry about the initial build—someone else handles it for you. This can be a relief if you're stretched thin.
Good for Non-Core Projects: It's a good option when the project isn't core to your business and you just need something functional without investing too much time and energy.
Capacity Management: If your team is already at full capacity, outsourcing can help you get things done without overloading your staff.
but…
Cons:
Lack of Influence: The downside is you have less influence over how the product is built. You might end up with a solution that doesn't quite fit your needs, and making changes can be costly and time-consuming.
Dependence on External Teams: When heavily dependent on the outsourced product, you also become dependent on the people building it. You're in trouble if they go out of business or change direction. This can create silos and a lack of knowledge within your own team about the product.
When should you avoid “Buying the Making”?
I say always avoid it. This is why we made fellowships with companies and have mentors with tech leads. Messed up relationships between companies, bad software outcomes, and unhappy clients.
It’s a lazy way that has become prominent in the last few years, and you get spammed by 10 agencies a day who offer you brilliant services.
The most obvious problem:
No agencies are really taking ownership of your product. The effort you put into getting it done right often exceeds the effort of building it yourself.
🍪 If you don’t have the expertise to build it yourself, you won’t have it later on when you suddenly become the owner.
PS: There are successful projects, but those are so rare that I recommend avoiding that approach, as well as avoiding gambling.
The 'Make' Approach
Then, there's the DIY route: building the solution in-house from scratch. This is often seen as the most challenging option, but it has benefits.
Pros:
Full Control: The most significant advantage is your full control. You can build exactly what you need without compromises. You set the roadmap, prioritize features, and decide how things work. That is a single, compelling aspect.
But are you prepared for this?
Cons:
Slow and Expensive: The major downside is that it can be slow and expensive. Building something from the ground up takes time and requires a significant investment of resources.
Need for Expertise: You must also have the competence and experience from day one. If your team lacks the necessary skills, you could end up with a product that's not up to par, which might require more time and money to fix down the line.
When to consider DIY?
When speaking to teams and tech leads, they often prefer to build themselves.
I saw two significant drivers pushing people to think like that:
An inner fear of lacking control later on.
(Fear; we want to prevent that.)The fascination of a new greenfield experience.
(Excitement; this is what we came for)
Those two factors are most often dominant but not always the perfect pick. Both describe an extreme (Fear vs. Fascination) and have nothing to do with a calm decision-making process.
When DIY does make sense:
You have very complex requirements you cannot change.
You want to sell the software itself later on in any form.
You build an “engine” for further products and must ensure the foundation is in your control.
You have a very experienced team, including leadership and good architectural experience.
When to avoid DIY:
A newly formed team without experience.
Lack of good leadership or architectural skill set.
Relative simple requirements could be covered by off-the-shelf SaaS / Open Source.
The 'Composing' Approach
Lastly, there's a hybrid approach: composing. Combining ready-made components with custom development means combining the best of both worlds. A well-known approach based on this idea is MACH1 (Microservices, API-First, Cloud-Native, and Headless).
Pros:
Balanced Control: Composing offers more control than buying but is faster and often less resource-intensive than making. You can pick and choose the components that work for you and build the rest.
Best-of-Breed: Not so commonly used anymore, but the idea is to pick the best specific solution for your requirement context. This drives the chances of having 80–90% coverage of your requirements by buying SaaS or using open-source.
Substitutability: One of my favorite NFRs, you can substitute entire contexts with new solutions when components don’t fit your needs anymore.
but…
Cons:
Complexity Risks: However, this approach can get VERY complex. The more you compose, the harder it can be to manage and integrate all the pieces. Sometimes, the effort of stitching everything together can surpass the effort of making it yourself from scratch.
Hidden Costs: As you add more components, you may encounter hidden costs, both in terms of money and time, that can outweigh the benefits of a faster start.
The Glue: You must orchestrate and compose all the pieces with the services you build yourself. This orchestration can become a heavy burden and quickly outweigh the initial benefit, driving you straight into the legacy trap.
When to consider Composing?
I don’t recommend it any more for small companies or startups, but I recommend considering it for medium-sized companies. More precisely, when you build a software backbone for your company long-term with several teams, you don’t want to focus on becoming an eCommerce, Authentification, or CRM software vendor.
I do not advocate for this approach, but it’s a good idea to think about it. I simply wouldn’t use it again as a small company.
What to avoid when Composing?
Avoid young open-source projects at all costs.
There is no guarantee, and you don’t want to become the maintainer. And if you want, you have a problem with your business vision :)
If there is an option for buying a support SLA for an open-source product, and it seems to be too expensive for you, you avoid Composing. You are simply too small to take multiple dependencies, and the risk is too high. Avoid it.
Decision-Making Framework
Deciding whether to make, buy, outsource, or compose your software solution can be daunting, but with the proper framework, you can make an informed choice that suits your business needs. Here’s a straightforward guide based on what I’ve learned over the years:
Assess the Importance of Control:
Do you need full control? If having complete control over the solution is critical for your business, you should probably build the software in-house or go with a composing strategy. This way, you can tailor everything to your needs and stay flexible for future changes.
Can you compromise on control? If control isn’t a big deal and you’re okay with letting someone else take the reins, buying an off-the-shelf solution might be the way to go, especially for non-core applications where you don’t need to customize much.
Evaluate Resource Availability:
Do you have the resources? Building in-house could be a good fit if you have a solid team with the right skills, enough budget, and time. This is especially true if you’re working on something requiring a lot of custom work or planning to sell the software.
Strapped for resources? If your team is already maxed out or you’re working with limited resources, buying a ready-made solution or outsourcing development can help you get things moving without stretching your team too thin.
Consider Speed vs. Customization:
Need it fast? If getting to market quickly is your top priority, buying an existing product or outsourcing the development can save you a lot of time. Look for solutions that cover at least 80% of what you need right out of the box.
Need it custom? Building in-house or going the composing route might be better if your project has specific needs or requires complex integrations that off-the-shelf products can’t handle.
Analyze Long-Term Implications:
Thinking long-term? Building in-house or composing might allow you to adapt and scale if you have a big vision for your software and anticipate growing or changing a lot over time.
Focused on the short-term? If this is more of a short-term project or you don’t expect the software to evolve much, buying or outsourcing could be a quick, cost-effective solution.
Evaluate Risk Tolerance:
Not a fan of risk? If you don’t like the idea of being dependent on someone else’s roadmap or an outsourced team’s stability, it’s probably safer to build in-house.
Okay, with some risk? Buying or outsourcing might be excellent if you’re willing to take on a bit of risk, like relying on a vendor or third-party developers.
Consider the Complexity of Requirements:
Do you have complex needs that won’t change? If your requirements are particular and unlikely to change, DIY might be the best route to ensure everything is exactly how you need it.
Dealing with more straightforward or more flexible needs? If your needs are straightforward or you expect them to evolve, buying or composing might be more practical and less of a headache.
Think About Knowledge Retention:
Want to keep knowledge in-house? Avoid outsourcing if your team needs to learn and retain knowledge about the software. Building in-house or composing lets your team stay in the loop and maintain control.
Not so worried about retention? Outsourcing or buying might be better if you don’t need to keep all the know-how in-house and just want a quick solution.
By thinking through these factors, you’ll be better equipped to decide whether to make, buy, outsource, or compose your software. Remember, there’s no one-size-fits-all answer—each choice has pros and cons, and the right one depends on your unique situation.
Conclusion
At the end of the day, there's no one-size-fits-all solution. Each option has pros and cons; the right choice depends on your needs, resources, and goals. The key is to weigh these factors carefully and make the best decision for your situation.
I'd love to hear about your experiences with the "make or buy?" dilemma. What has worked for you, and what hasn't? Feel free to share your thoughts or ask questions—let's learn from each other!
Adrian
https://machalliance.org/