"Buy or build" is usually asked too early — before it is clear what exactly would be bought or built. The result is a comparison between a monthly licence and a development quote, two numbers that do not measure the same thing. An off-the-shelf system is measured by how much the business will have to change to fit it; a custom build is measured by how much the system will have to change when the business does.
This guide proposes a different order: first define one process — not "a system to run the business" but a specific process with a start, an end and users — then examine three routes on that same process, against the same six items. There is also a section on when not to build, because that is a perfectly legitimate answer.
Define the process and its constraints — before comparing
Comparing routes is only possible when there is something to compare against. Three things should be written on one page before you open anyone's product page:
- Core actions — five to ten actions the process must support, phrased as a user would: "a rep enters an order", "a manager approves a credit exception", "the warehouse marks the order as picked". Not features, not screens.
- The users — who touches the process, how many they are, and how their permissions differ. An external customer and an internal employee are two different worlds for every route.
- The data — which entities the process manages (customer, order, product, document), where they live today, and which system is the source of truth for each. If the ERP is the source of truth for inventory, no route exempts you from connecting to it.
Then the constraints: regulation (privacy, data retention), existing systems that must not be replaced, budget and the decision horizon. Constraints are what turn a list of three theoretical options into the one or two that are actually open.
Three routes on the same process — an example
A wholesale distributor takes orders from business customers by phone, email and WhatsApp. The process: a rep enters the order → the system checks stock and credit → a credit exception goes to a manager for approval → the order moves to the warehouse for picking → an invoice is created in the existing accounting system. Users: six reps, two managers, the warehouse team and — in future — the customers themselves, entering orders through a portal. Data: customers and inventory live in an existing ERP that is not being replaced.
| What we look at | Off-the-shelf order system | Adapted CRM/ERP platform | Custom build |
|---|---|---|---|
| Capability | Order entry, stock and basic approvals from day one. A familiar interface for reps. | Approval flow, customer fields and reports configured to the business. No-code automations for most cases. | The exact process — including credit exceptions by company rules and picking in warehouse order. A customer portal as part of the same system. |
| Limitation | Credit exceptions by company rules are probably unsupported. ERP connection only if an official connector exists. | Whatever cannot be configured needs code inside the platform — and that must be maintained through every release. | Nothing exists on day one. Every report, screen and role is built. Time to first use is the longest of the three. |
| Risk | The business changes its process to fit the product — then discovers the exceptions were what set it apart from competitors. | Customisations pile up until the platform no longer behaves like the product that was bought — yet it cannot be left either. | Scope that grows without limit during definition, and dependence on the team that knows the code if there is no documentation and orderly handover. |
| When it fits here | If the company is willing to handle credit exceptions outside the system and a customer portal is not planned. | If such a platform already exists in the organisation and the exceptions can be configured without code. | If the order process and the portal are part of the service the company sells to its customers. |
Notice what is missing from the table: prices. Not because they do not matter, but because at this stage there is not yet enough definition for any figure to be reliable. Cost comes in the next section — as categories on a timeline, not as sums.
What does it cost over time?
To compare cost across routes, pick one period — three years is a common reference, because within it releases, people and at least one business requirement will change — and fill in five lines for each route. Some lines will be empty or estimated; that too is information.
| Category | Off-the-shelf | Adapted platform | Custom build |
|---|---|---|---|
| Licensing | Per user or tier, monthly or yearly; rises with growth and with each added module | Platform licences + sometimes separate licences for customisation modules and test environments | No product licence; cloud infrastructure and third-party services (email, payments, maps) by usage |
| Implementation | Settings, initial data import, training. Usually short | A project in its own right: specifying customisations, configuration, testing, training — often via an implementation partner | Part of the build: specification, staged delivery, data migration, training and handover |
| Integrations | Ready connectors — if they exist — sometimes at extra cost; what is missing stays missing | Platform connectors + interface development for every system without one | Every connection is built and maintained by you; a documented API is a very different job from a system with no interface |
| Maintenance | The vendor's responsibility; you deal with changes the vendor decides on | The vendor maintains the platform; you maintain the customisations and test them on every release | Yours, or under a maintenance agreement: dependency updates, security, monitoring, backups |
| Change | Only what the vendor adds; your request joins a waiting list | Change within the platform's limits — fast; beyond them — expensive or impossible | Any change is possible; the cost depends on the quality of the code and documentation you received |
The common mistake is to compare the licensing line of an off-the-shelf system with the build line of a custom one and stop there. The line that usually decides is "change": how many times in three years your process will change, and what happens each time.
Ownership and control: data, export, dependence and transfer
Four questions worth asking before signing on any of the routes — and the answers differ sharply between them:
- Whose data is it, and in what format can it be exported? A CSV export of the customer table is not the same as exporting order history, attachments and the audit log. Ask to see a real export before buying.
- What happens when the vendor changes pricing, drops a feature or shuts down? For an off-the-shelf system this is a business risk that needs a fallback plan. For an adapted platform, the investment in customisations is lost on the way out. For a custom build the risk shifts to the maintaining team — which is why documentation and handover are part of the product.
- Who can change the system tomorrow? If the answer is "only the vendor" or "only the developer who built it" — that is dependence, regardless of the route chosen.
- How would the system be transferred to another team? For a custom build that means: a repository in your name, cloud accounts you own, operating documentation. For an off-the-shelf system it means: an export-and-import plan to another product, tested at least once.
What is handed over at the end of a development project — code, access, documentation and a list of what was built against the scope document — is described on our service page. It is also what you should demand from any development vendor, not just us. Custom software development — how scope is defined and what is delivered
When not to build?
Custom development is the most expensive and slowest of the three decisions, so it needs a positive reason — not just discomfort with an existing product. These are the conditions under which an existing product is probably the right answer:
- The process is standard in your industry and contains nothing your customers specifically pay you for. Invoicing, payroll, internal task management, email — almost always an existing product.
- You are willing to change the process. If you can work the product's way without hurting customers, that is cheaper than building your own way.
- The users are a small internal team that can be trained and supported — not customers or partners whose experience is part of your product.
- There is no certainty yet that the process will stay as it is. While the business is still finding its way, a cheap off-the-shelf product is a cheap experiment. A custom build locks in decisions that have not been made yet.
- Nobody will own the system after handover. A custom system needs an owner inside the organisation and a maintenance budget. Without both it ages faster than an off-the-shelf product.
What a system built around a process looks like — a real example
Michrazit is an example of a process no off-the-shelf product would cover: a private-construction tender in which suppliers submit bids in a uniform spec, homeowners compare line by line, and whatever locks in the tender flows straight into the contract. The process itself — supplier vetting, dynamic rating, matching by construction stage — is the product, which is why it was built. The case study describes what was built and how. The Michrazit case study — a tender platform for private construction
When the process runs in a browser for customers, employees or partners — a portal, an admin system, a B2B system — the discussion about users, permissions and integrations continues on our web-systems page. Web systems and portals — users, permissions, processes and integrations
What we do at this stage
Before pricing any development we map the routes for your system together: the process, users and data on one page; the three routes on the same six items; and which part of it actually needs to be built. Sometimes the outcome is a recommendation not to build — or to build only a part. If development is the way forward, the scope document written here is the basis for the proposal.