Choosing software
Configuring and building are different decisions
Most requirements that feel unique are configuration. Some genuinely are not. Telling them apart early saves the budget and the relationship.
Nearly every business we speak to believes some part of how they operate is unusual. Most of the time the belief is sincere and the conclusion is wrong, not because the business is ordinary, but because the unusual part is a setting rather than a structure.
The distinction that matters
Configuration changes behaviour the system already anticipates: your stages, your document templates, your approval thresholds, your tax treatment, your naming. It is fast, it survives upgrades, and it is reversible.
Building changes what the system is: a new object with its own rules, a workflow that has no analogue, an integration nobody has written. It is slower, it has to be maintained, and it is yours forever.
How to tell which you are looking at
Describe the requirement without naming any software. If the description is about values, which stages, which rates, which documents, who approves, it is configuration. If it is about relationships that do not exist in the model, a thing that belongs to two parents, a rule that depends on a state nothing tracks, it is building.
Why people get this wrong in both directions
Vendors under-call it, because saying it is just configuration wins the deal and the discovery happens later. Buyers over-call it, because their process feels distinctive from the inside and a demonstration never quite shows their case.
Both errors cost the same thing: a plan built on the wrong assumption about effort.
What we do about it
We map the requirement against how the business actually operates before quoting anything, and we will tell you when the honest answer is that our products do not fit. Six of our twenty-five solution areas map to no product at all. Those route to a conversation, not a checkout, because pretending otherwise would only delay the same conclusion.