Here is the quiet economics of enterprise software. Every vendor solves the same hard problems dozens of times, and every customer pays for every repetition. The repetition is where the cost, the inconsistency and the duplicated effort come from, and it is invisible because the repeats wear different departmental costumes.
Watch it happen. A trade compliance analyst traces an ownership chain, asking whether a sanctioned party controls this counterparty through stakes stacked three layers deep. An internal auditor maps intercompany exposure. An ethics officer checks a third party's beneficial owners. A supply chain manager asks who actually sits behind a struggling supplier.
Four job titles, four software categories, four budgets, four vendor relationships. One underlying problem. Trace who owns whom, layer by layer, and decide when indirect control matters. Each of those four tools solved it separately, to a different standard, and the customer paid four times for three redundant solutions.
The dozen problems wearing thirty costumes
Run the exercise across an enterprise and the pattern generalises. Superficially unrelated functions keep resolving to a short list of recurring problems. Is this supplier, this counterparty and this hotline subject the same real-world thing? Which procedures does this regulation change touch? Is this expense, this override, this sensor reading unusual? Which of these thousand alerts deserves an analyst? What will this number be next quarter, and why did it move?
Across the thirty-odd modules of a full enterprise suite, we count roughly a dozen problem classes doing almost all of the real work (e.g. entity resolution, ownership tracing, anomaly detection, classification, change-to-document conformance and alert triage). Almost all of them recur in more than one function. Conventional suites rebuild each one per module, because software is organised the way buyers are organised, by function, and no mechanism lets the audit module's anomaly detection benefit from what the finance module learnt.
The economics of building them once
Invert the organisation, build the problem classes once as engine capabilities and let each function configure them with its own vocabulary, and the economics change in three compounding ways.
- The second module costs less than the first. Its hard problems arrive already solved, needing configuration rather than construction, and the discount grows with every module added.
- Improvements propagate instead of repeating. Sharpen ownership tracing for the trade module and the audit, ethics and supplier modules inherit the sharpening the same day. Tune anomaly detection against the hardest consumer and every other consumer gets the improvement free.
- Quality converges upward. Each problem class is maintained to the standard of its most demanding consumer, not the budget of its weakest one. In a per-module world, quality converges on whatever each team could afford.
A module, on this architecture, is a vocabulary and a set of decisions, not a codebase. The engine has no domain vocabulary at all.
The test a buyer can run
The claim is checkable from outside. Ask a suite vendor what happened in their audit module when their screening module improved its entity resolution. If the honest answer is nothing, the suite is thirty products sharing a login page, and you are paying for every one of those separate ceilings.
Ask the same question of a problem-organised platform and the answer is a release note. The improvement landed everywhere the problem class is used, because there is only one of it.
This architecture is why Prophesee exists in the shape it does. A domain-agnostic engine holds the dozen problem classes, each module configures them through vocabulary rather than code, and every decision one team wires up makes the next one cheaper to wire. See the flywheel on your own functions. Start here.