We turn down custom development work regularly. A company arrives wanting a bespoke system, and forty minutes into the first meeting it becomes clear that a 40 JOD-a-month product would do the job better than anything we could build for 60,000.

Build vs buy is the most consequential technical decision a growing company makes, and it is almost never a technical question.

The question that settles most cases

Is this process the reason customers choose you?

If yes, build it. If no, buy it.

A logistics company whose routing method is genuinely better than its competitors' should own that software. The same company's payroll is not a competitive advantage — it is an obligation, and an obligation should be bought.

Most requests we decline fail this test. The company wants to build accounting, HR or a CRM: processes that are identical across thousands of firms and where the market has already spent millions solving the problem.

Three more questions worth asking

How unusual are you, honestly?

Every company believes its processes are unique. Most are not; they are simply undocumented, so the differences feel larger than they are. Before commissioning anything, write the process down and compare it to what three products already do. Frequently the gap is small enough to configure around.

What happens if this software stops being maintained?

Buying means depending on a vendor who may raise prices, change direction or close. Building means depending on your own ability to keep a developer available for years. Both are risks. The question is which one you are better placed to carry.

How fast does the process change?

If your workflow changes every quarter, custom software becomes a permanent expense — every change is a development ticket. A configurable product absorbs that churn more cheaply.

What custom actually costs

The build price is the smallest part. Over five years, for a mid-sized internal system in Jordan, expect roughly:

  • Initial build: 25,000–90,000 JOD depending on scope.
  • Maintenance: 15–20% of build cost annually, for dependency updates, browser changes and security patches — before any new feature.
  • Change requests: whatever you spend adapting it as the business shifts.
  • Knowledge risk: the cost, one day, of onboarding someone new to a system only one person understands.

A 40,000 JOD build is realistically a 75,000–90,000 JOD five-year commitment. Compare that to the product subscription honestly, including its price rises.

The middle path most companies miss

Build vs buy is presented as binary and rarely is. The pattern that works most often in Jordan:

Buy the commodity, build the difference, integrate the two.

Run your finance on an established ERP. Build only the module that encodes what makes you distinctive — the routing engine, the pricing logic, the inspection workflow. Connect them with an API.

You get a maintained system for the boring 80% and full control over the 20% that matters. The integration work is real but far smaller than building everything.

Signs you are about to build the wrong thing

  • The requirements document describes features, not outcomes.
  • Nobody can name a product you evaluated and rejected, with a reason.
  • The justification is "we want it to work exactly our way" and nobody has asked whether our way is any good.
  • The budget covers the build but not two years of maintenance.
  • The person who wants it most has never had to maintain software.

How to decide this week

List every system you are considering building. For each, answer the first question honestly: do customers choose us because of this? Anything answering no goes on the buy list.

What remains is usually one system, not five. That one is where custom development earns its cost — and building one thing properly beats building five things adequately.