Why is the license not the cost of the project?
It is the most frequent confusion and the one that produces budgets breaking halfway through. The license is what you pay the vendor to use the software. The implementation is what it costs to make that software reflect your operation.
A license can be looked up on a pricing page. An implementation cannot, because its cost depends on variables inside your company, not inside the product. That is why no serious vendor can give you a figure before knowing what has to be done, and why the prices that do circulate publicly are license prices.
Which variables move the cost of the implementation?
Six, in rough order of impact:
| Variable | What makes it more expensive |
|---|---|
| Integrations | Every system that has to connect (ERP, billing, e-commerce) is a project in itself. It carries the most weight. |
| Quality of the source data | Duplicates, inconsistent fields, incomplete records: cleaning before migrating usually costs more than migrating. |
| Number of sales processes | One pipeline is simple. Four business units with different criteria multiply the configuration. |
| Customization | Custom objects and properties, logic the platform does not ship with. |
| Migration | Bringing history over from another CRM, with its relationships and its traceability, is not a contact import. |
| Users and training | It affects the license directly and adoption indirectly: training forty people is not training five. |
What timelines are realistic?
Time is the best indirect indicator of cost, because almost all the spend on an implementation is people's work.
- Weeks — one pipeline, standard properties, no integrations, data in good shape, a small team.
- One to three months — several pipelines, automations, one integration, migration from a spreadsheet or a simple CRM.
- Three months or more — multiple integrations with internal systems, custom objects, migration with history, several business units.
If a vendor quotes you the third scenario on the first one's timeline, the question is not about price: it is what is being left out of scope.
Which costs get forgotten at budgeting time?
Four, and they are the ones that produce the feeling that a project “went over budget” when it was never inside it:
- Cleaning the data first. You discover it when you open the database, not when you quote.
- Your own team's time. The mapping, validation, and training sessions are hours your reps are not selling.
- Support afterwards. A living CRM changes: new processes, fields that turn out to be useless, automations to adjust.
- License growth. Per-seat models scale with the team, and a user structure planned badly at the start gets paid for every month.
Is a diagnosis worth doing before quoting?
When the project lands in the second or third timeline scenario, yes, and for an economic reason more than a methodological one: without prior mapping, the quote is built on assumptions, and the assumptions that fail turn into additional scope halfway through.
A discovery up front turns “how much does it cost?” into “this is what has to be done, and this is what it costs.” We treat it as a separate service so you can use that diagnosis even if you decide to implement with someone else.
How do you compare two quotes with very different numbers?
By comparing scope, not totals. Three questions almost always reveal where the difference comes from:
- Does it include data cleaning and migration, or assume the data arrives clean?
- How many integrations does it cover, and what happens if one more turns up?
- Does it include training and support afterwards, or end at handover?
A notably cheaper quote is almost never more efficient: it usually leaves out one of those three, and all three end up getting done anyway.
We separate those line items in our proposals and start with a HubSpot Discovery for that reason: with the scope defined, comparing stops being guesswork.