Generic software manages fields. Specialized industries run on context.

What generic software usually gets wrong

Generic software is built around a lowest-common-denominator model: a record has a name, a type, a status, a date, and a notes field. That model is deliberately shallow — shallowness is what lets the same product serve a dental office and a distributor. Configuration can rename the fields and rearrange the screens, but it cannot add what the model never contained.

The failure is rarely dramatic. The software installs fine, the demo goes well, the basic workflow works. The trouble starts with the first question the industry actually cares about — which build series is this asset, what did the survey find, who brokered the last sale, is this record trusted — and the answer is a shrug, because the information had nowhere to live except the notes field.

Why industry language and relationships matter

Every specialized industry runs on a vocabulary that carries real operational meaning. In marine, a hull identification number is not a serial-number string; it encodes manufacturer, series, and production date, and it anchors a vessel’s entire history. In aviation, a tail number connects an airframe to registrations, inspections, and ownership chains. These are not fields. They are entry points into webs of relationships.

Specialized industries typically depend on industry-specific entities, complex relationships between organizations, people, assets, and records, specialized terminology, historical context, documents and evidence, product and asset hierarchies, approval and review states, provenance, and operating rules about who may see and change what. When software does not understand that web, every relationship the industry runs on has to be held in someone’s head — and the system becomes a place where context goes to be flattened.

How workarounds become shadow systems

When the official system cannot hold the real work, the real work moves somewhere unofficial. It starts small and reasonably:

• A spreadsheet tracking what the system cannot represent
• A separate database someone built for one team
• Approvals that happen over email because the system has no review states
• Manually maintained reference documents
• The same facts entered twice in two systems
• Side-channel messages that carry the context the record lost
• Unofficial internal tools nobody sanctioned but everybody uses
• Veteran employees who have memorized how the system really works

Individually, each workaround is rational. Collectively, they are a shadow system: an unofficial second platform holding the organization’s most important context, with no backup, no access control, no review, and no future. The official software still runs — but the business now depends on the shadow. And shadow systems are how fragmentation reproduces itself, one reasonable workaround at a time.

Why context matters more than feature count

Software evaluations usually compare feature checklists, which is exactly the comparison generic platforms are built to win. But features operate on the model beneath them; when the model lacks the industry’s entities and relationships, every feature works on impoverished data. A report builder cannot report on relationships the system never captured. An automation engine cannot route an approval the system cannot represent.

Context inverts the evaluation. A platform that understands the industry’s entities, relationships, and rules makes even simple features valuable — search that understands what a model series is beats an advanced query builder that does not. The right question is not “how many features?” It is “does this system understand what our information means?”

What industry-specific intelligence should understand

A system built for a specialized industry should understand the industry’s core entities and how they actually relate: organizations, people, products and assets, models and categories, documents, evidence, history, and the workflows that move between them. It should know where each fact came from and whether it has been reviewed — provenance is what separates a trusted record from an entry. And it should enforce the industry’s operating rules directly: what is public, what is private, what requires approval, and who holds authority over each record. These are the properties we treat as core capabilities in everything we build.

To be clear, this is not an argument that all generic software is bad. Generic platforms are the right tool for genuinely common functions — accounting, communication, documents. They break down when the industry’s context becomes the central requirement: when the value of the system depends on understanding what the information means, not just storing it. Our industry platforms exist precisely for that second case.

How to recognize when generic software has reached its limit

The signals are consistent across industries. The notes field has become the most important field in the system. The spreadsheet count next to the official software keeps growing. New employees take months to become productive because the system alone cannot teach them how the business works. Approvals and history live in email. And the people who understand “how the system really works” have become single points of failure.

When those signals appear, adding features or configuration rarely helps, because the gap is in the model, not the interface. What helps is a system designed around the industry’s actual context — its entities, language, evidence, and rules. That usually begins the same way any fragmentation problem does: understanding what information already exists and how it should connect.