When a Custom CRM Is Cheaper Than Salesforce

A small operations team did not need a six-figure CRM rollout. A focused customer workspace removed spreadsheet handoffs, protected follow-up revenue, and cost less than Salesforce's subscription and implementation burden.

Client project · anonymized

The business had customer and deal information spread across spreadsheets, inboxes, and billing exports. Salesforce would have solved some visibility problems, but its per-user subscription, implementation work, and process overhead were disproportionate to the team's actual needs.

TL;DR

The conclusion is not that Salesforce is bad. It is that platform breadth is not the same as business value. For a small team with a narrow workflow, a focused system can be cheaper, quicker to adopt, and easier to change.

The problem: the CRM decision became a pricing exercise

The team was not asking for a sophisticated enterprise sales machine. They needed four things:

• one reliable customer record instead of several spreadsheet tabs;
• a clear owner and next action for every active opportunity;
• a history of conversations and changes that did not depend on one person’s inbox; and
• a way to send qualified information to billing without copy-paste.

Their existing process had grown around spreadsheets. A customer might appear under slightly different names in the pipeline, support log, and invoice export. Follow-up dates lived in individual calendars. At the end of the month, someone reconciled totals manually and asked the team which opportunities were still real.

The proposed Salesforce route was understandable: buy a proven CRM and configure it properly. But the proposal bundled together several different costs:

• recurring licences for every person who needed to view or update a record;
• implementation and consulting time before the team saw a useful workflow;
• migration and cleanup of the existing data;
• training, admin, and governance work to keep the system usable; and
• process changes designed for the platform rather than for the team’s actual bottleneck.

The question was therefore not “Can Salesforce do this?” It obviously can. The useful question was “Are we buying capabilities we will operate and benefit from in the next three years?”

The cost model: compare the next three years, not the demo

The figures below are an anonymized decision model, not a universal Salesforce price quote. Actual pricing varies by edition, contract, seats, implementation partner, and negotiated terms. The model includes the costs that are often omitted from a software-only comparison.

The custom system only wins when its scope stays disciplined. If the team asks for every feature of a large CRM, the implementation becomes a more expensive way to recreate a large CRM. The economic advantage comes from removing unused surface area, not from pretending that software maintenance is free.

What was actually built

The replacement was a small customer workspace with a clear boundary:

• Customer and contact records with one canonical identity and deduplication rules.
• Opportunity stages with owner, value, next action, and due date.
• Activity history for calls, emails, notes, and status changes.
• A billing handoff that sends validated deal data to the existing finance workflow.
• Role-based access so the team sees what it needs without exposing every administrative action.
• An export path so the business can take its records elsewhere at any time.

The system did not attempt to replace accounting, email, marketing automation, or every report the company might want someday. Those remained connected services. The CRM became the source of truth for customer relationships and active deals, not a new universe that had to own the whole business.

Architecture

The important architecture decision was the ownership boundary, not the framework choice:

Existing spreadsheets ──validated migration──▶ CRM database
                                                  │
                                                  ▼
                                          Customer workspace
                                           │             │
                                           ▼             ▼
                                     Billing handoff   Export / reporting

• A relational data model made customer, contact, opportunity, and activity relationships explicit instead of relying on matching names in cells.
• Validation ran before import and at every external boundary. Invalid or ambiguous records went to a review list rather than silently becoming duplicate customers.
• Every important change carried an actor and timestamp, giving the team a usable history when a customer or invoice was disputed.
• The billing handoff was idempotent: retrying an event could not create a second deal or invoice request.
• The UI exposed the team’s language — next action, owner, due date, and customer status — instead of making them translate a generic platform’s terminology.

The migration path that kept the business moving

The team could not stop selling for a CRM project. The migration therefore happened in five controlled steps.

1. Define the decisions the CRM must support

Before designing screens, we listed the decisions owners and managers needed to make each week: which opportunities were going stale, who owned the next action, what revenue was likely to close, and which customer details finance could trust. This prevented “feature parity” with a platform whose unused features created the original overhead.

2. Clean and map the source data

The spreadsheets were treated as evidence, not as a schema. Duplicate customers were grouped, missing owners were flagged, and fields that mixed several meanings were split before import. The team reviewed the exception list in business terms: “Is Acme GmbH the same customer as Acme Europe?” is a decision an owner can answer; “row 18,421 violates a foreign key” is not.

3. Run a parallel period

The new workspace first ran beside the old process for active opportunities. Totals, owners, and next-action dates were reconciled on a fixed schedule. The old spreadsheets remained available as a read-only fallback until the team trusted the new workflow.

4. Cut over the active work, archive the rest

Only current customers, open opportunities, and the history needed for daily decisions moved into the active interface. Older records were preserved in an export and searchable archive. That kept the daily workspace fast and avoided making every historical irregularity a blocker.

5. Measure adoption by work completed

Success was not the number of fields configured. It was whether the weekly reconciliation stopped, whether every active opportunity had an owner and next action, and whether billing received consistent data without a copy-paste queue.

Why the focused system won

The custom CRM was cheaper for this business because it solved a narrower problem completely:

• Less licence surface: no paid seats for features the team would never operate.
• Less process translation: the workspace reflected existing decisions and vocabulary.
• Lower change cost: a new field or handoff was a bounded business decision, not a platform administration project.
• Better data ownership: exports, schema, and deployment access stayed with the business.
• A credible exit: if the team later needed Salesforce, the clean data model and export path made that migration easier rather than harder.

That last point matters. A focused custom system is not a bet against every future platform. It is a way to stop paying enterprise-platform costs before the business has enterprise-platform needs.

Lessons learned

“Custom” is only economical with a hard boundary

The first scope was deliberately small. Customer identity, opportunities, activities, and billing handoff were in. Campaign management, complex forecasting, and a universal reporting layer were out. A written boundary protected the economics.

Adoption is a workflow problem

People did not need a longer training course. They needed the next action to be obvious and the record to be trustworthy. When the system removed reconciliation work, usage followed.

Total cost includes the cost of not deciding

The spreadsheet process was not free while the CRM decision was pending. Every week of duplicate data, missed follow-up, and manual reconciliation carried a cost. A fair comparison includes the revenue and management time protected by making the workflow reliable.

Is this the right path for your business?

A focused CRM is worth evaluating when:

• your team has fewer than a few dozen regular users;
• the bottleneck is customer visibility and follow-through, not a global enterprise process;
• most work happens in a handful of repeatable stages; and
• you want ownership of data and a clean path to another platform later.

Salesforce may be the right answer when its ecosystem, governance, forecasting depth, or global scale is already a real operating requirement. The decision should follow the business process, not the impressiveness of the product tour.

For the broader AppSheet-to-owned-system migration pattern, see Migrating an AppSheet CRM to a relational system. If you are comparing build versus buy for your own workflow, bring the numbers to a 20-minute fit call.