Build vs Buy: age old dilemma

Table of Contents

The age-old dilemma that technical co-founders get confronted with: should I build it from scratch or buy some off-the-shelf solution? I’ve asked myself this question many times over the last years and it’s not as black and white as it seems. It can be one or the other, or a gradient mix of both of them as long as it fulfills the particular purpose and pushes the company further.

We’re not talking about building tools that surround your company’s non-critical operations. That’s never a good idea unless you hit specific bottlenecks and have the resources (not VC money) to invest. If you’re a 2-year-old startup and want to write your own CRM or ERP system — sure you can do that not. Is it reasonable? Absolutely not.

I’ve noticed an interesting trend — non-tech people are usually the ones who suggest going with a third-party vendor, while developers are eager to build it. I mean, writing a piece of complicated software sounds fun, I agree, but in the end, neither of them is right.

There is no right way here, only tradeoffs — between speed, cost, control, and functionality. And that’s exactly what I’d like to discuss with you, some of the factors that need to be considered before you decide on the build VS buy and the extent of it.

Build VS Buy

First thing first — it’s subjective. Some people will tell you that building everything from scratch worked wonders for them, while others say that Salesforce has all the features they need. Great, now moving on.

Two things you need to keep in mind:

1. If you’re in the prototyping / Proof-of-Concept phase — build it from shit and bricks, it doesn’t matter as long as you can showcase the core aspects.
2. If it’s your core business, you shouldn’t build it with third-party vendors long-term. For example, if you’re building an AI business, you can go with openAI chatGPT API for the first year, after that it makes more sense to revue more cost-effective and efficient ways of scaling — dive deep into the research papers and roll your own language models.

Here are some other factors you should keep an eye out for:

Costs: Building always requires a big chunk of money and effort upfront. And if you plan XX’000$ for the MVP, you can plan double that for the bugs and changes you will need to do along the way while getting more user feedback. However, after you have that initial version ready — it’s easy to continue scaling, in comparison to the white-label solution, where the money and effort come later when you decide to customize the software or migrate away from the vendor.

Step ahead: Another advantage of building your own solution is that it can provide a competitive advantage. The more in-house technology you have, the more ahead you are of the copycats, and the harder it is to copy your in-house technology the safer you are. If you rely on an off-the-shelf solution — others can do the same.

Timeline: Custom solution =  longer initially, but may result in a shorter timeline in the long run. Purchasing a SaaS solution = quicker, but it may take longer in the long run once you realize there are things that need to be adopted.

Security & Data Privacy: When you buy a COTS solution, you don't own the data, and you need to sign data processing agreements. So it’s a tradeoff between not owning the data VS owning the data but getting compliance. For young startups, this can be a disadvantage as getting compliance is not cheap — both mentally and $$$. Another point — SaaS solutions are often targeted by hackers, so there is a slightly elevated risk of leaking data.

Flexibility: Another advantage of building a custom solution is that it provides complete control over design and functionality, allowing you to tailor the solution to your unique needs. COTS by default is a standardized solution. If the stuff that you need can be done out-of-the-box — great. However, purchasing a SaaS solution means relying on someone else to build and maintain the solution, which can limit your ability to make customizations.

Until you’ve hit product market fit, you shouldn’t build anything other than what is unique to your product. If you are spending time on authentication or forms or worker queue architecture, you’re wasting time.

Frameworks and plug-ins exist to allow this to be all plug and play, so you can focus on building something potentially useful enough for people to pay for it. Product market fit is generally achieved when you can’t keep up with demand for your product. “Can’t keep up” is generally an operational problem first, then a technical problem (the Do Things That Don’t Scale stuff catches up to you basically).

- Comment from Hackernews on buidilng with a Framework

If you're looking to build - lets build together.

Nocode VS Build

For a few years, there’s been a new player in town — NoCode tools. They’re slightly more flexible than the standardized solution and slightly more cost-effective than building from scratch, a sort-of middle ground.

NoCode solutions are a wildcard in the build vs buy dilemma. On the one hand, they allow you to build custom solutions quickly and easily, just like a SaaS solution. But on the other hand, you still have the control and customization options of building from scratch. So it’s like a 50% buy 50% build.

NoCode is great if you don't have a technical co-founder but still want to build your business.

If you’re leaning more towards the buy option, it might be better to consider going with NoCode. Use a it to quickly build a proof of concept, extend it as much as the no code allows, and once you have the product market fit and have a scalability issue — invest in building a custom solution base on the noCode logic. The beauty of NoCode solutions is that there are so many of them that offer different levels of flexibility, so you can pick what works best for you.

Buying properly

If you decide to buy an off-the-shelf solution, it's important to do your due diligence to avoid being taken advantage of.

Full demo: A big No-No is to make a decision based on a few presentations where the sales people promise you that “yes, most definitely our software can do everything that you need”. Unless you see it in action and it’s adapted to your use case do not sign any agreements. There’s nothing worse then the feeling of getting bamboozled by the feature sale.

Hidden costs: Some SaaS solutions may have hidden costs, such as monthly fees, upgrades, or maintenance charges. Make sure you understand all the costs associated with the solution and whether they fit within your budget.

Data privacy and security: Make sure the SaaS solution you choose has the necessary security protocols in place to protect your data. Check for certifications such as SOC 2 and PCI DSS, and consider the provider's track record for data breaches.

User reviews and feedback: Look for customer reviews and feedback to see what others have experienced with the solution. This can give you an idea of its reliability, ease of use, and support.

Lack of customization: Some SaaS solutions may not offer the customization and flexibility you need. Check the features and functionality of the solution and whether they match your needs.

Integration issues: If you're using multiple tools and solutions, make sure the SaaS solution you choose can easily integrate with them. This can help avoid compatibility issues and ensure seamless operation.

Support and Maintenance: Consider the level of support and maintenance offered by the SaaS provider. This can help you avoid downtime and ensure your solution is always up-to-date.

Need more advice — let me know.

Conclusion

So that’s basically it, not black and white, just a list of tradeoffs that you base your decision on. Have a huge pile of cash? Might be good to build it yourself? Have a small pile of cash? Better to go NoCode. A few dollars — go with the standardised SaaS. In the end, all of those are viable solutions if they bring you closer to your goal.

Eventually though, as you scale more and more, everything turns to building it in-house.