Custom CRM is a phrase that spans an order of magnitude of cost, and the demo hides all of it. Two systems can show the same pipeline board and contact page while one cost triple the other, because the price of a CRM is not its screens. It is the shape of the data underneath, the mess being migrated into it, and the number of systems it has to agree with. Those drivers are knowable before anyone writes code, which means the price is steerable before anyone pays it.
Driver One: The Shape of the Data
A contact list with notes is a weekend of work. A model where a customer has properties, properties have equipment, equipment has service history, and a job connects a crew to all of the above is a real schema, and the schema is where CRM cost actually lives. Every entity, every relationship, and every rule, no two open invoices per job, a quote must reference a surveyed property, multiplies the states the system must handle correctly. The scoping question that predicts the price is not how many screens. It is how many kinds of thing, connected how.
Driver Two: The Mess Coming In
Migration is priced by dirt, not by volume. Fifty thousand clean rows import in an afternoon; eight thousand rows spread across a rented CRM, three spreadsheets, and an inbox, with the same customer spelled four ways, is a cleaning project with an import at the end. The duplicate-record liability analysis covers why the cleanup cannot be skipped: importing the mess faithfully reproduces it in a more expensive container. Budget honesty here means auditing the current data before quoting, and any builder who does not ask to see it is quoting fiction.
Driver Three: The Systems It Must Agree With
Every integration is a standing promise between two systems, and promises are priced by direction. Reading from an accounting package is cheap; two-way sync with conflict rules is a distributed-systems problem wearing a checkbox's clothes. The discipline that controls this driver: every integration starts one-way, and earns two-way status only with a named, recurring task that justifies it. Most never do.
The Quieter Drivers
- Interfaces and roles: an owner view, an office view, and a field view are three applications sharing a database, not one app three times.
- Automation depth: notifications are cheap; sequences with branching, timing, and exception handling are a subsystem.
- Reporting: numbers on a dashboard are easy. Numbers someone will bet payroll on need definitions, audits, and history.
- Authentication and audit trails: boring, mandatory, and priced in from the start rather than bolted on after.
Steering the Price Down Without Regret
The levers that cut cost without cutting the point: model only the entities the business runs on today, and let the schema grow when reality demands it. Start every integration one-way. Ship the office view first and let the field view be a phase, not a launch requirement. Migrate the customers and open work, and archive the deep history as searchable files instead of modeled records. What should never be cut is the schema thinking itself, because every later phase stands on it, and the versus articles in this cluster exist precisely because rented platforms are what schema-shaped problems look like when nobody owned the schema.