"Should we build it or buy it?" is often argued by whoever speaks most confidently. One person likes the control of custom software, another likes the speed of a product that already exists. Both are partly right, and neither argument can be checked.
This article offers five questions that can be answered by people who know the process, in about an hour. It is about ordinary business software, such as a tool for approvals, scheduling, quoting or internal reporting. If you want the wider framework, see our build versus buy decision framework. If your starting point is a spreadsheet that has outgrown itself, from spreadsheet to a small internal tool in 30 days covers that path. Here we stay on the decision itself.
Question 1: How unique is the process?
Describe the process in five sentences, then ask: would a competitor of similar size do it the same way? Invoicing, leave requests and password resets are done almost the same everywhere. A ready-made product has seen thousands of such cases and will handle edge cases you have not thought of yet.
If the way you do it is part of why customers choose you, such as a special quoting rule or an unusual delivery model, a product will either not fit or will push you to change what makes you different. That points toward building, or at least toward a product you can configure deeply.
Question 2: What does it cost to keep it alive?
The first version is the cheap part. A built tool needs fixes, updates of the libraries it depends on, security patches, hosting and small changes every month. A bought product has a subscription that tends to rise, plus the time to configure it and sometimes paid extras.
Compare three years, not one. For each option write down the one-time cost, the yearly running cost and the hours your own people will spend. The difference between the options is often smaller than the difference between the first-year prices. Our article on the true cost of manual processes can help you count the hours you are spending today as the baseline.
Question 3: How fast will the process change?
If the process changes every few weeks, you need a tool that your team can change quickly. That can be your own code with a team close by, or a product with strong configuration that a business user can edit. If the process has been stable for years and will stay stable, either option works, and the cheaper upkeep wins.
Ask for real examples: how many times did the process change in the last twelve months, and how long did each change wait? If the answer is "often, and we waited", a slow vendor roadmap is a risk you should price in.
Question 4: Who will own it?
Name one person who will be responsible for the tool after launch: someone who decides what changes, answers questions and pays attention when it breaks. This question is the same for both options. A built tool with no owner decays, and a bought product with no owner turns into an unused subscription with workarounds around it.
If you cannot name an owner, do not decide yet. Solve that first, because it will affect the result more than any feature.
Question 5: How do we leave?
Every choice needs an exit. For a product, ask: can we export all our data in a usable format, and what happens to the price at renewal? For a built tool, ask: who else can read the code, and is it documented well enough that another team could take it over?
You do not plan to leave, but you should know what it would cost. A tool that is hard to leave gives its supplier, or its original author, a lot of power over you.
A worked example of the comparison
The numbers below are invented to show the method. They do not describe a real client or product.
Suppose a team needs an approval tool. Option A is a product at 300 per month. Option B is a custom build at 12,000 once, plus 150 per month for hosting and 10 hours per month of upkeep at an internal rate of 40 per hour.
- Option A over 36 months: 300 × 36 = 10,800, plus setup of 20 hours at 40 = 800, so 11,600.
- Option B over 36 months: 12,000 + (150 × 36 = 5,400) + (10 × 36 × 40 = 14,400), so 31,800.
On cost alone, the product wins by a wide margin. Now change one fact: the process has a rule the product cannot express, and working around it costs 30 hours per month of manual checking. That is 30 × 40 × 36 = 43,200 over three years added to Option A. The ranking flips. The method did its job: it showed which single assumption decides the result, and that is the one to verify before you sign anything.
Write it down on one page
Put the five answers, the three-year comparison, the owner and the decision on one page. Add a date, usually six to twelve months out, when you will check whether the assumptions held. A decision with a review date is easier to make, because it does not have to be perfect.
Common mistakes
- Comparing a finished product with an imagined perfect build. Compare what you can really get for the same budget and time.
- Counting only the first year. Upkeep is where most of the difference hides.
- Letting features lead. A long feature list matters less than the process fit and the owner.
- Forgetting the exit. Ask about data export before the contract, not after.
- Deciding for the whole company. Decide for this process. A different process may deserve a different answer.
What to do this week
Pick one tool you are considering. Gather the person who knows the process and the person who would own it, and answer the five questions together, in writing. Fill in the three-year comparison with your own numbers and mark which ones are measured and which are estimates. If one assumption decides the result, spend the rest of the week checking just that.
Sources
- Our related articles linked above.
- The worked example is invented to show the method and does not describe a real client, product or price.