Many companies say they need a CRM when what they actually need is a system for running their business process.

That difference matters. A CRM is a category of software. A business process is a living operating model with its own exceptions, approvals, handoffs, and rules. Those two things overlap, but they are not the same.

I have worked with many commercial CRM systems. They can be useful, especially when the business mainly needs standardized pipeline management, contact history, and basic reporting. But over time I moved toward custom systems for many workflows, and in practice I often prefer building those systems on AppSheet.

The reason is straightforward: a custom system is often more reliable for real operations because it can reflect the actual process instead of forcing the process to bend around someone else’s CRM structure.

The short answer

Choose a standard CRM when:

• the business process is still relatively conventional;
• the main need is lead, deal, and contact management;
• the team wants predictable setup and familiar patterns;
• sales process standardization matters more than process specificity.

Choose a custom system when:

• the workflow is not just sales pipeline management;
• approvals, delivery, finance, support, or operations are deeply involved;
• the business process has too many exceptions for a generic CRM to stay clean;
• the company needs the system to match the process instead of training the process around the software.

Where standard CRM still makes sense

Commercial CRM products solve a real problem: they give businesses a ready-made framework for managing contacts, opportunities, stages, and activity history.

That is useful when:

• the business is still organizing sales discipline;
• reporting expectations are conventional;
• the process is close to a standard lead-to-deal workflow;
• the company values fast rollout more than process-specific tailoring.

In those situations, CRM can be the right answer because the process does not yet justify custom software. The business benefits from a familiar model, not from architectural originality.

The point where CRM starts becoming friction

The problem appears when the workflow is no longer just CRM.

This is common in real businesses. A record does not simply move from lead to won. It may also require:

• qualification rules unique to the company;
• multi-step approvals;
• delivery or production status;
• finance checks;
• document collection;
• service scheduling;
• operational follow-up after the commercial stage is already complete.

At that point, the system is not just managing a pipeline. It is managing a process.

That is where many commercial CRMs start feeling awkward. Teams add custom fields, workaround automations, manual steps, side spreadsheets, and disconnected tools until the original CRM becomes an expensive layer sitting on top of process chaos instead of resolving it.

Why I often prefer a custom system

I prefer custom systems because they let you encode the exact business logic the company actually uses.

That matters more than generic CRM elegance.

A custom system can reflect:

• the real statuses used by the team;
• the exact approval chain;
• role-specific views;
• operational checkpoints beyond the sales stage;
• documents, tasks, and dependencies attached to the process;
• the metrics that matter to the business, not just the metrics a CRM expects.

This is why I have moved toward custom CRM-like systems in many cases. Once the process becomes business-specific, the software should follow the process, not the other way around.

Why AppSheet is a strong fit for this

For many internal business systems, AppSheet is the most practical middle path.

It is not a generic “CRM product.” That is precisely why it is useful.

Google positions AppSheet as a no-code platform for creating business apps and automations from existing data.¹ That makes it a strong fit for internal systems where the process is already known, the data model is business-specific, and the goal is operational control rather than product-style UX.

In practice, AppSheet works well for custom CRM-like systems because it can support:

• tailored process states;
• form-driven record creation and updates;
• role-based operational views;
• approvals and actions;
• mobile-friendly workflows for teams outside a desktop-only office setup.

If the process needs a system that looks like “CRM plus operations plus approvals plus workflow tracking,” AppSheet is often a better fit than trying to force all of that into a conventional CRM mold.

The hybrid pattern is usually even better

The strongest design is often not “custom CRM only.” It is a layered business system.

That usually looks like:

• AppSheet as the business-facing process interface;
• n8n as the integration and orchestration layer;
• external tools only where they are genuinely better than building more inside one platform.

This matters because a business process rarely stops at one app.

You may need the system to:

• sync with email or messaging;
• create documents;
• push data into analytics;
• notify managers;
• enrich records from APIs;
• trigger downstream steps in finance, operations, or support.

n8n is a strong fit for that surrounding automation layer because it handles orchestration far better than pretending every backend workflow should live inside the front-end app.²

That is why AppSheet vs Custom Build vs Hybrid: How to Choose for Internal Business Tools and When Self-Hosted n8n Is the Better Choice are natural companion reads.

When custom is the wrong choice

A custom system is not automatically better.

It is the wrong choice when:

• the company does not yet understand its own process well enough;
• the team mainly needs standard pipeline discipline;
• nobody can own the logic and evolution of the custom workflow;
• the business wants a ready-made tool, not a system tailored around its operating model.

If the process is still generic, a standard CRM may be more efficient. Custom systems pay off when specificity is real, not when it is imagined.

A practical decision rule

Ask one question:

Is the software mainly supposed to track customers, or is it supposed to run the business process around those customers?

If the first is true, standard CRM may be enough.

If the second is true, you are no longer making a pure CRM decision. You are designing an internal operating system for part of the business. That is where custom structure becomes more valuable than CRM familiarity.

Summary

Commercial CRM systems are useful when the business mainly needs standardized sales management.

Custom systems become better when the real job is broader: approvals, operations, delivery, documents, follow-up, and business-specific logic that does not fit neatly into CRM defaults.

That is why I often prefer custom CRM-like systems built around the actual process, especially with AppSheet as the operational layer and n8n around it for automation. For many businesses, that produces a system that is not only more flexible, but more practical to run.

Sources