When an off-the-shelf product fights the way you work
Every off-the-shelf product carries an opinion about how the work is done. It has to — a product that assumed nothing would have no features, only settings.
That opinion is invisible during evaluation, because demos are run along the path the product was designed for. It becomes visible about four months in, when your team starts doing things that look slightly absurd to anyone watching.
Recognising the mismatch early is worth more than any feature comparison, and it is the input that most often changes the outcome of a build vs buy analysis.
What the mismatch looks like
It rarely announces itself. It shows up as habits:
- A spreadsheet that lives alongside the product because the product cannot hold a field somebody needs
- Records created in a status they are not really in, because the workflow will not allow the real one
- A naming convention encoding information the schema has nowhere to put — job titles with a suffix, projects prefixed with a code
- Someone re-entering the same information in two places because the product’s model says these are unrelated and in your business they are not
None of these gets reported as a problem. They get reported as how we do it.
Three kinds of disagreement
The entity disagreement. The product thinks the unit of work is a ticket; your business thinks it is a case that may contain several tickets and outlives them. Everything downstream — reporting, permissions, notifications — is built on the wrong noun.
This is the worst kind, because it cannot be configured away. The noun is in the schema.
The sequence disagreement. The product assumes approval happens before scheduling; you schedule first and approve later. Usually survivable, usually via a status that means something different from what it says, and it makes every report subtly untrue.
The cardinality disagreement. The product assumes one of something and you have several — one address per customer, one owner per account, one price per product. This is the most common and the most fixable, sometimes with a custom field, often with a workaround that quietly breaks reporting.
Why it is worth naming rather than tolerating
Because the workarounds have a cost that never gets attributed to the product. The re-keying is somebody’s afternoon. The spreadsheet has no permissions and no history. The naming convention is understood by four people and undocumented. The reports are wrong in a way nobody can see, because the status field does not mean what its label says.
When the cost eventually surfaces, it surfaces as “our data is a mess,” and the proposed fix is usually a new product with a different opinion.
What to do about it
If the disagreement is cardinality or sequence, it is usually cheaper to adapt your process than to replace the product. Genuinely consider that — the process may not be load-bearing, and preferences that feel fixed often are not once they have a price attached.
If it is the entity disagreement, and the entity is central to your business, no amount of configuration fixes it, and you are choosing between changing how you think about your own work or owning the model. That is the point where building the core and buying around it becomes the honest answer.
Either way, write the mismatch down. The most expensive version of this is the one nobody names for three years, because by then the workarounds are load bearing and the migration has to reproduce them.
How to catch it during evaluation
Do not demo the happy path. Take the three most awkward real cases you have handled in the last quarter — the ones with an exception in them — and ask the vendor to walk through those specifically.
The product that handles your awkward cases without a workaround is the one that shares your model. That is worth considerably more than a longer feature list.
The cheapest moment to notice
The mismatch is cheapest to act on before the workarounds become load-bearing. That window is roughly the first six months, while the number of records is small, the habits are new, and nobody has built reporting on top of the field that means something other than its label.
After that, every month adds data shaped by the compromise, and any move — to a different product or to something you own — has to reproduce the workaround faithfully or explain the discontinuity.
The limit
I cannot tell you from here whether your process is genuinely unusual or merely familiar. Companies consistently overestimate how distinctive their operations are, and a large share of “no product does this” turns out to be preference rather than requirement. The awkward-cases test above is the cheapest way I know to find out which, and it is a test rather than an answer.
Related reading: buying software you can live with covers the wider evaluation, buy and extend covers the middle path this usually leads to, and what building commits you to covers what you take on if you go the whole way.