| What you are deciding on | Off-the-shelf product | Custom build |
|---|---|---|
| Time to value | Weeks, sometimes days. Nothing custom competes with a product that already does the job. | Weeks to a first flow in production, and longer for anything broad. |
| Fit | Good for the eighty per cent the vendor designed for. The remaining twenty is where the arguing happens. | Exact, by definition — including the parts of your process that are genuinely unusual. |
| Cost shape | Per seat or per usage, forever, rising with headcount and with the vendor's pricing changes. | Higher up front, then infrastructure and maintenance. Flat as you grow. |
| Integration | Whatever the vendor's API allows. Often the real limit, and rarely visible during the demo. | Whatever your systems allow. This is usually the reason people build in the first place. |
| Who maintains it | The vendor. Genuinely valuable — security patches, compliance updates and new features arrive without you. | You, or whoever you retain to do it. Real recurring work, and the line most people leave out of the comparison. |
| Process change | You adapt to the product, which is sometimes an improvement and sometimes a fight. | The system adapts to you, including the habits that were worth keeping and the ones that were not. |
| Data | In the vendor's system, exportable to the degree they choose to support. | In yours, in a shape your other systems can read. |
| Risk | Vendor risk: price rises, roadmap changes, acquisition, shutdown. | Delivery risk: it has to be built, and it has to work. |
The maintenance row is the one that decides more of these than people expect. A vendor keeping a product current across thousands of customers is doing something a single build cannot replicate, and it is a genuine argument for buying.
The work lives in the seams. No product covers your CRM, your ERP and the three spreadsheets in between, and the integration is the actual job.
The process is your differentiator. If how you quote, triage or underwrite is why customers choose you, standardising it onto a product removes the thing that was working.
Per-seat pricing has stopped being sensible at your headcount, and the arithmetic is now clearly in favour of owning it.
Compliance, residency or audit requirements exceed what the vendors in your category are willing to commit to.
A product already does it. Accounting, payroll, helpdesk ticketing, e-signature — these are solved, and building them again is an expensive way to end up behind.
The process is standard and you have no strong reason for it to be otherwise. Adapting to a good product is often the cheapest process improvement available.
You are not sure the process is worth automating yet. A subscription you can cancel next month is a better experiment than a build.
The volume is small. Below a certain scale, almost nothing custom pays for itself, however good the demo looks.
In practice the question is rarely all-or-nothing. The pattern that works is to buy the systems of record — CRM, ERP, accounting, helpdesk — and build the layer that moves work between them and makes the decisions the products cannot. That layer is small, specific to you, and almost never available off the shelf.
Most of what we deliver looks like this. The client keeps every product they already pay for, and we build the part that extracts the data, applies the rules, updates the right systems and escalates what does not fit. Nothing is replaced, and the integration surface stays deliberately narrow.
The failure mode to avoid is building a worse version of something purchasable. If, during the audit, we find a product that covers your process properly, we will tell you and the engagement gets smaller. That has happened, and it is a better outcome than eighteen months spent re-creating a helpdesk.
We use cookies for analytics — to see which pages bring enquiries. Nothing else, and nothing before you agree. Cookie Policy