Count the exceptions in your process before comparing features, then ask who owns the next upgrade. Those two questions decide module versus custom build.
Key takeaways
- An off-the-shelf module excels on a process with few exceptions, and starts coming apart as the exception list grows.
- The expensive exception is not the rare one. It is the one that requires a human decision every time it occurs.
- Version changes are a documented fact rather than a surprise: Priority states that from version 25.1 API transactions move to a shared pool across all users, and that the change happens automatically on upgrade.
- Shopify publishes a new API version every three months, supports each stable version for a minimum of 12 months, and guarantees at least nine months of overlap between consecutive versions.
- Anything unversioned changes without notice. Shopify explicitly marks some of its surfaces as unversioned.
The choice between an off-the-shelf module and custom development is settled by two questions: how many exceptions your process has, and who is accountable for fixing things when a new version changes behaviour. Features do not distinguish the two. Exception count and upgrade ownership do.
The count that comes before any vendor conversation
Before comparing modules, measure the process. The count takes two hours and changes the whole conversation:
- Pick one process, for example order to cash.
- Write the happy path in seven to nine steps, with no conditions.
- Walk it step by step and record every "but" the staff raise.
- Mark for each "but" whether it is settled by a fixed rule or by a human decision.
- Count only the exceptions that require a human decision. That is the number that matters.
- Record for each exception how many times it occurred last month, from data rather than from memory.
A process with zero to two such exceptions is a clear case for an off-the-shelf module. A process with six or more already behaves like a decision engine, which is an entirely different category of work. In between, at three to five, the upgrade question becomes the tie-breaker.
What actually counts as an exception?
An exception is any case where two employees might act differently on the same input. That is the working definition, and it produces a sharper list than "edge case":
- A price term agreed in conversation rather than set in a price list.
- A document split or merged at someone's discretion.
- A customer treated differently because of history rather than classification.
- An item handled differently because it arrived damaged or short.
- An approval required above a certain amount, and sometimes below it.
- A return credited only in part, depending on the condition of the item.
An exception that has been written into a rule is no longer an exception; it has become a condition. A large share of unnecessary development projects begin because nobody converted exceptions into rules before asking for a quote. See when not to build custom software.
Who owns the upgrade path?
| What changes | With an off-the-shelf module | With custom development |
|---|---|---|
| A new version of the system | The vendor ships it, you decide when to take it | You verify the customisation still works |
| Behaviour that changed in a version | The vendor adapts the module, subject to support | Accountability is yours, discovery included |
| A change in licensing model or quotas | Applies to you and moves cost | Applies to you and may also force a code change if the quota touches the interface |
| An interface that stops being supported | The vendor is accountable for updating | You are accountable, on the platform's timetable |
| Testing after an upgrade | Usually with the vendor | Must be with you, and ideally automated |
| The knowledge of why it was configured this way | With the vendor and the implementer | With you, if you documented it |
The last row is the one most often dismissed. An off-the-shelf module takes technical work off your hands, but it also moves the knowledge of why the process is defined as it is out of the building. Custom development does exactly the opposite.
What vendors actually publish about version change
These are documented examples, not estimates. They show that the upgrade path is data you can plan against:
- Priority tags capabilities in its documentation with the version they were released in, and marks capabilities in development as Beta.
- Priority documents that from version 25.1 all API users share a single transaction pool instead of an equal split per user, and that the change happens automatically on upgrade.
- Priority documents that from version 19.1 REST API errors are returned as JSON rather than XML.
- Priority documents that from version 21.0 a timezone can be set per company through the TZSERVER system constant, and warns this might produce a different offset than expected.
- Shopify documents a quarterly release cycle with date-based version names, a minimum of 12 months of support per stable version, and at least nine months of overlap.
- WooCommerce documents that from version 8.2, storing orders in dedicated tables is the default for new installations.
The first four rows are precisely the kind of change that turns a customisation which worked for two years into something requiring retesting. None of them is a surprise, because all of them are published.
Where the extension surface sits, and why that matters
Before deciding where logic should live, it is worth knowing which connection points the vendor publishes. Priority's developer portal presents, as of September 2026, the following sections: REST API, Web SDK, Priority SDK, Webhooks, ODBC, an MCP Server and OIDC Authentication. For authentication it documents three routes: Basic, personal access tokens and OAuth2.
The practical implication:
- Logic sitting on a versioned, documented interface can be tested automatically, which means it can be upgraded.
- Logic sitting on undocumented behaviour works until the first upgrade, and then breaks quietly.
- The more documented connection surfaces there are, the more likely a customisation can stay outside the core. That is the difference between a customisation you maintain and one you rewrite.
- Shopify explicitly marks some of its surfaces as unversioned and notes they might change at any time. Depending on one of those is a decision, not an accident.
See also Priority webhooks and triggers on where event-driven logic is best attached.
Cost shape, without numbers
- What scales with the number of exceptions. This is the dominant factor, and its effect is not linear: exceptions multiply when they intersect with each other.
- What scales with transactions. Interface quotas are usually metered on writes rather than on users, so sales growth moves cost without adding an employee.
- What scales with customisation. Not the time to write it, but the time to retest it at every upgrade.
- What scales with the age of the customisation. A five-year-old customisation nobody documented costs more to change than a new one.
- What stays flat. Documenting decisions: why it was defined this way, and what happens if it changes.
Related: build versus buy, custom software versus off-the-shelf.
Sources
Frequently asked questions
How many exceptions justify custom development?
There is no absolute threshold, but there is a useful working rule: count only the exceptions requiring a human decision. Up to two, an off-the-shelf module is almost always better. At six or more, you are describing a decision engine. Between three and five, the upgrade question decides it.
Can an off-the-shelf module be combined with custom development?
Yes, and it is the most common shape in practice. The module handles the happy path, and custom development handles the exceptions in a separate layer. The only condition is that the boundary be defined: which value is born where, and who writes it last.
What do you test after a system upgrade?
The exceptions, not the happy path. The happy path was tested by the vendor. The exceptions are the only things leaning on specific behaviours, so they are what break. A test list covering your exceptions is the single most useful artefact in the project.
How do I tell whether a customisation leans on undocumented behaviour?
Ask whoever wrote it to point at the documentation page describing the behaviour it depends on. If no such page exists, the customisation rests on observation rather than a commitment. That is not automatically wrong, but it has to be recorded as a known risk.
Keep reading
Related service
Custom Business Software
The internal system that replaces the spreadsheet you outgrew.
About the author
Yehonatan Saadia
Freelance automation, web & MVP developer
I'm Yehonatan Saadia, a senior developer who builds business automation, custom websites, and MVPs for small and mid-sized companies across the US, Europe, and Israel. These guides come from real client work, not theory.
Work with meHave a project like this?
Tell me what you're trying to automate or build. I reply within 24 business hours with a few targeted questions, then we walk through it on a free 30-minute call, with no commitment. You come away with a scope, a timeline and a fixed price - or a straight answer that it isn't worth building.