Home / Blog

Build vs buy software: a decision framework

Build or buy is usually argued with feelings: developers like building, finance likes buying, and whoever speaks last wins. Here's a framework that turns it into a decision you can explain on one page.

5 min read · 28 September 2026

Decide per process, not per company

The first mistake is treating build vs buy as one decision for the whole company. It isn't. Most companies should buy some things and build others. Accounting, email and document storage are almost always bought. The core of how you deliver work to clients might be worth building.

So run this framework once per process or area: sales, operations, scheduling, HR, client communication, reporting. Our custom software vs SaaS article covers the general trade-offs. This one gives you a method.

The six questions

Score each question from 1 to 5 for the process you're considering. Low scores point to buying, high scores to building.

  • Differentiation: is the way you do this part of why customers choose you? (1 = no, it's standard; 5 = yes, it's our edge)
  • Fit: how much do the best off-the-shelf tools force you to change how you work? (1 = not at all; 5 = a lot, and we'd lose something)
  • Connections: how many other processes does this one hand work to or receive from? (1 = it stands alone; 5 = it's the hub)
  • Scale: how many people need to use it, and how fast is that growing? (1 = a few, stable; 5 = many, growing)
  • Change: how often does this process change? (1 = rarely; 5 = regularly, as we grow or win new kinds of work)
  • Workarounds: how much time do people spend working around current tools? (1 = none; 5 = hours every week)

Reading the score

With six questions scored 1 to 5, totals range from 6 to 30.

Treat the score as a structured conversation, not a formula. If one question scores a clear 5 for a serious reason, such as a regulatory requirement no tool handles, it can outweigh several low scores.

  • 6 to 13: buy. Pick the best standard tool, configure it lightly and adapt your process to it.
  • 14 to 21: grey zone. Look hard at the five-year cost comparison below and at hybrid options. Often the answer is to buy for now and revisit in a year.
  • 22 to 30: build. The process is specific, central and costly to work around. Standard tools will keep charging you, in fees and in hours.

A worked example

Here's how the scoring might play out in a hypothetical company: a building maintenance firm with 60 staff, most of them in the field.

For accounting, the scores are low across the board: standard process, good tools available, few workarounds. Total around 8. Buy, and keep the current package.

For scheduling and job management, the picture is different. The way they plan recurring maintenance across client sites is part of why clients stay (differentiation 4). The field service tools they tried forced a different planning model (fit 4). Every other process depends on jobs: invoicing, payroll prep, client reports (connections 5). Forty field staff and growing (scale 4). Contracts change often (change 3). Planners spend hours a week reconciling spreadsheets with the tool (workarounds 5). Total 25. Build.

The resulting decision isn't 'build everything'. It's a custom operations core with accounting connected to it. That pattern is common, and it's usually the right one.

The five-year cost comparison

Compare total cost over five years, not the first-year price. Buying looks cheaper in year one almost every time.

For buying, add subscriptions for everyone who should use the tool, add-ons and higher tiers, integration tools and consultant hours, the time people spend on workarounds, and expected seat growth. For building, add the fixed build price, hosting, support after the included period and changes over time.

As a reference point, at Company Maxxing: Core is €18,000 for one company with up to five roles and three months of support; Maxxed is €48,000 with unlimited roles, the AI layer, up to four integrations and six months of support; Empire starts at €120k for groups. Extra integrations are €4,500 each, and Maxxing Care is €2,900 per month after the support period. There are no per-seat fees. Our SaaS sprawl cost article walks through the buy-side calculation step by step.

The options in between

Build vs buy isn't binary. There are several middle paths, each with its own trade-offs.

  • Buy and configure: a standard tool with custom fields and automations. Good when fit is mostly right.
  • Buy and connect: keep several standard tools and add integrations. Good for a while; watch for sprawl.
  • Low-code build: an internal team builds on a platform. Good for simple workflows; watch for lock-in and a single builder.
  • Custom core, bought edges: build the system at the centre of your process and connect specialised tools like accounting. This is where most mid-sized companies end up when they build.

Risks on each side

Both paths have risks. Neither is safe by default.

  • Buying: price increases, features you need locked behind higher tiers, vendor changes you can't control, data spread across tools, and a process shaped by someone else's product.
  • Building: choosing the wrong builder, scope that grows, a system nobody adopts, and dependence on the people who built it.
  • Buying, reduced by: annual reviews of fit and cost, owners for each tool, and export tests so you know you can leave.
  • Building, reduced by: fixed prices per phase, working software early, involving users from week one, and owning the code, data and documentation.

Who should be in the room

The decision shouldn't be made only by the owner, only by finance, or only by whoever is most enthusiastic about technology. Include the person who runs the process day to day and one or two people who use the current tools most. They know where the workarounds are, which is the part of the score most often underestimated from the top.

Common mistakes

Building because it's exciting, when a standard tool would do. Buying because it's the default, when the team is already spending hours every week working around it. Comparing first-year costs instead of five-year costs. Deciding without talking to the people who do the work. And treating the decision as permanent: a process that scored 12 two years ago might score 24 today.

Make the decision

Score your main processes this week. For the ones that land in the build zone, get a fixed quote and compare it with five years of the alternative. If you'd like a second opinion, apply and show us the process. We'll tell you honestly if buying is the better answer. If building is, you'll get a fixed price and a first working version on your own data within 24 hours of kickoff.

Questions

When should a small company build rather than buy software?

When the process is part of your edge, standard tools force costly workarounds, and it connects many other parts of the business. For standard processes like accounting, buy.

Is building always more expensive?

In year one, usually. Over five years, it depends on seats, add-ons, integration costs and workaround time. Compare total cost, not first-year price.

Can we build part and buy part?

Yes, and most companies should. A common pattern is a custom core system with specialised tools like accounting connected to it.

How often should we revisit the decision?

Once a year, or when the company changes significantly: new services, new locations or rapid hiring.

What if we build and the builder disappears?

Own the source code, data, documentation and hosting account. That way another team can take over.

Keep reading