Build or Buy?

This post is a thread I posted on twitter about making a build vs buy decision for software.

This question has likely come up for discussion at every organization, be it a startup or a big company. If you are a startup, the answer should be ‘buy’ by default. A textual flowchart on how I arrived at this. We’ll call the software ‘X’.

Does building X lead to differentiation or unfair competitive advantage for your startup? If the answer is no, you should buy.

Is X critical for your startup’s survival? If the answer is no, you should buy.

Do you have the luxury to wait before X is ready to use? If the answer is no, you should buy.

Do you have the right people to start building X today? If the answer is no, you should buy.

If you answered yes to all questions above, you are one step closer to making the decision to build. However, here are a few more points to consider before committing to building X.

Hiring engineers is hard. Would you want to use your team’s valuable time and energy on building something that is secondary to the success of your business or obsess over solving the most important problems for your customers?

Building software is hard. There will be curveballs at every stage (scope creep, changing requirements, bugs, delays, etc.,), Costs will usually be higher than estimates.

Speed is a startup’s greatest advantage. If building the software is important to you, and you can’t start today don’t lose heart. Buy the software today. Build clear abstractions. Start building. Change your buy decision when ready.

If you still end up choosing to build, congrats. You are likely a big co with 1000s of engineers solving for exploring new tech/domain, optimizing for scale + ballooning costs, building foundations for long term advantage. None of these matter, when you are a startup.