Custom CRM vs Zoho vs HubSpot vs Salesforce: Which Should You Choose?

You are choosing between three established platforms that you subscribe to and shape, and one system that is designed and built for your business alone. Zoho CRM, HubSpot and Salesforce each give you a working CRM early and ask you to fit your process into their structure through configuration. A custom CRM starts from your process and asks you to fund, run and maintain everything the platforms would otherwise provide.

That framing matters more than any feature list. The four options differ less in what a salesperson sees on screen and more in who decides how the system works, who changes it and who carries the risk when it stops fitting.

Zoho CRM

Zoho CRM is a configurable sales CRM from a vendor that also makes a wide family of other business applications, which is a large part of its appeal to companies that want several tools from one supplier. On the CRM itself, Zoho describes a customisation layer that includes custom fields and custom modules, page layouts that show or hide fields conditionally, custom buttons, a design studio called Canvas for reshaping how records look, client scripts for automating actions in the interface, a sandbox for testing changes before they go live, and portals that give customers, partners or vendors controlled access. How much of that is available to you depends on the edition you buy.

HubSpot

HubSpot is a CRM platform with separate hubs for marketing, sales, customer service, content, data management and revenue work such as quoting and payments, all sitting on one shared customer database. It offers free tools alongside paid Starter, Professional and Enterprise editions, and the capability you get changes with both the hub and the edition. Custom objects, which let you model records that are not contacts, companies or deals, need an Enterprise subscription. HubSpot also runs a marketplace of connected apps and an AI assistant, Breeze, that works across records.

Salesforce

Salesforce is a CRM and application platform built for depth. Its sales, service, marketing, commerce and industry products share a unified customer view, and the platform supports both low-code configuration and pro-code development, with tooling for deploying changes at scale. Around it sit a data layer for unifying enterprise data, an AI agent product called Agentforce, a learning platform called Trailhead and a large community of customers, partners and specialists. As with the others, what you can do in practice depends on edition and on what you license.

A custom CRM

A custom CRM is software designed and built for one business, either by an internal team or by a development partner. You decide the data model, the stages, the screens each role opens on, the automation rules and the integrations. Nothing arrives pre-built, and nothing has to be bent to fit. The trade is responsibility: hosting, security, fixes, documentation and every future change are yours to arrange and pay for, even when a partner does the work.

Configuring a platform means changing its settings; customising it means writing code or scripts inside its boundaries; building means writing the whole application. Buyers often frame the decision as “platform or custom”, when the more useful question is which of these three commitments your requirements actually demand.

Configuration covers fields, pipeline stages, page layouts, assignment rules, validation, permissions, email templates and standard reports. An administrator can usually do it without a developer, it tends to survive vendor upgrades well, and it is easy to undo. Many sales teams can run for a long time on configuration alone.

Customisation starts when settings run out. Scripts, custom objects, bespoke interface components and code-based integrations extend the platform while keeping its login, security model and core records. It needs someone who knows that platform’s development model, and each customisation becomes something to retest when the vendor ships changes. Heavy customisation is where a platform implementation quietly becomes custom software with a subscription attached.

Building removes the platform altogether. There is no edition ceiling and no vendor structure to work around, but there is also no ready-made login screen, permission model, audit trail, report builder or mobile layout. Each has to be designed, built and maintained.

A useful rule follows. If most of your requirements are configuration, choose the platform that configures most naturally for you. If a small number of requirements need customisation, a platform is still usually the sensible base. If the core of the system — the records, the workflow and the way each role works — would need customisation throughout, that is the point at which a build deserves a serious look.

The chapters that follow walk the same six decisions in order: process fit, configuration, integrations, administration, ownership and control, and long-term fit. Each one narrows the field before the next.

Process fit comes first because a CRM that matches how your team sells gets used, and one that does not gets worked around. The question is not whether a platform can represent your process, since almost any system can with enough effort, but whether your process resembles the patterns the platform was designed for.

Map the process as it runs, not as the slide describes it

Sit with the people who handle enquiries and write down what actually happens: where leads arrive, who picks them up, what is gathered before a price is given, who approves discounts, what happens when a quote is revised and who takes over once a deal is won. Include the exceptions, because the exceptions are usually where the spreadsheets live. A map drawn from interviews rarely matches the one in the sales deck, and it is the only version worth evaluating against.

The patterns platforms handle comfortably

A linear pipeline in which a lead is qualified, becomes an opportunity, receives a proposal, is negotiated and is then won or lost is the pattern every major CRM is built around. So are contacts attached to companies, activities logged against records, tasks with due dates and owner-based visibility. If your map is mostly this shape, with different field names and a few extra stages, a platform will fit with configuration and the conversation should move on to which one.

Signs your process is genuinely unusual

• The central record is not a person, company or deal but something else: a property unit, a policy, a legal matter, a vehicle, a project or a production batch.
• One transaction involves several parties with different roles, each needing their own view and permissions.
• Approvals branch according to value, product, region or risk, and the branches change often.
• The sales record keeps working after the deal closes, feeding delivery, billing or renewals in ways the sales team depends on.
• Stages carry fundamentally different work, not merely different labels.

An unusual process does not automatically mean a custom build. Platforms can model non-standard records, subject to edition, and some businesses are well served that way. What an unusual process does mean is that configuration will be tested harder, so the next decision deserves more care.

When the map does point towards a fitted system, a CRM built around your own pipeline starts from exactly that document: every enquiry given an owner, a stage and a next step, with each stage defining what it requires before a record moves on.

Configuration usually reaches further than buyers expect, so the job is to find the specific point where your requirements stop being settings and start being code. That point differs by vendor and by edition, and it is best found with your own scenarios rather than a sales demonstration.

What configuration usually handles well

On all three platforms, depending on edition, an administrator can add fields, build pipelines, design layouts, set assignment and notification rules, control who sees which records and create standard reports. Zoho documents custom modules, conditional layouts, custom buttons, the Canvas design studio and a sandbox for testing. HubSpot configures around its shared database and adds custom objects at the Enterprise level. Salesforce offers low-code tools for much administrative change and a pro-code path when those run out.

Where configuration starts to strain

Strain tends to appear in a few recognisable places:

• Relationships between records. Many-to-many links, records that belong to several parents and hierarchies several levels deep can become awkward in a standard model.
• Logic that depends on other records. Rules that check related data, calculate across many records or wait for several conditions often move from settings into scripts.
• Interfaces that differ by role. Layouts can hide fields, but a screen that works entirely differently for a rep, a manager and a partner may need custom components.
• Edition boundaries. A capability that exists on the platform may not exist on the edition you planned to buy, which changes the cost of fit rather than its possibility.

Test the edges before you commit

Write down your hardest scenarios, the ones that currently live in a spreadsheet, and ask each vendor or partner to show them working in a trial environment with your data. Listen for the moment someone says “we would script that” or “that needs the higher edition”. Neither is a disqualifier. Both are facts about cost, skills and maintenance that belong in your comparison.

The systems a CRM must connect to often decide the choice more firmly than its features, because a CRM cut off from billing, support or operations becomes one more place where the truth is out of date. List every connection before comparing options, and for each one note which way data flows and which system is the master.

Connections fall into two groups. Capture brings enquiries in: website forms, email, phone calls, messaging channels, ad lead forms, marketplaces and imports. Exchange keeps the CRM consistent with the rest of the business: accounting and invoicing, ecommerce orders, support tickets, delivery or fulfilment status, internal tools and reporting.

Platforms are strongest where a ready-made connector exists. HubSpot’s app marketplace, Salesforce’s partner community and Zoho’s family of related applications each shorten the path to common tools. The questions to ask are how deep a connector goes, whether it syncs both ways, which fields it maps, what happens when records conflict, and whether it needs a particular edition or a paid app on top.

Where no connector exists, the routes converge: someone writes integration code, whether on the platform or around a custom build. For a custom CRM every connection is built, and what is possible depends on the other system’s API, database access or exports. That is a scoping fact to confirm, not a feature to assume.

Messaging deserves particular care in India, where a great many enquiries start on WhatsApp. How a lead moves from a chat into an owned CRM record, and how follow-ups return to that chat, is a design question in its own right; this guide to WhatsApp lead follow-up walks through the shape of that system.

Finally, count the integrations you will own. Every sync is something that can break silently when either side changes, and someone has to be responsible for noticing.

Every CRM needs a named owner who changes fields, manages users, keeps data clean and declines poorly reasoned requests, and the option you choose decides what skills that person needs. A CRM without an owner decays: duplicate fields multiply, automations overlap, reports disagree and the sales team slides back to spreadsheets.

The administration model differs by option:

• Zoho CRM is typically run by an internal administrator, often with an implementation partner for the initial setup and for scripting or integration work that goes beyond settings.
• HubSpot is commonly owned by a marketing operations or sales operations person, because its hubs put marketing, sales and service data in one place and someone has to govern how teams share it.
• Salesforce implementation and administration generally call for specialist skills, so businesses tend to have a dedicated administrator, a specialist partner, or both.
• A custom CRM needs a product owner inside the business who decides what changes, and a development team, internal or external, who makes each change. Routine adjustments that a platform administrator handles in settings may be development tasks unless an admin screen for them was built in.

That last point is often missed. When you commission a custom CRM, decide up front which things your own team should be able to change without a developer — stages, fields, assignment rules, templates and user roles — and make those configurable in the build. Everything left out becomes a change request.

Whichever option you choose, write down a light governance routine: who can request a change, who approves it, how it is tested and how users are told. The routine costs little and prevents most of the decay that makes businesses believe they chose the wrong CRM, when in fact they stopped administering the one they had.

On a platform, your data sits in the vendor’s environment under the vendor’s terms, and you control it through exports, APIs and your contract. On a custom CRM, you decide where the data lives and how it is structured, and you take on the responsibility for protecting it. Neither is automatically safer; they place control and responsibility in different hands.

The questions that establish control on a platform

• Can you export everything, including activity history, notes, attachments, stage history and audit records, rather than just contacts and deals?
• In what format and how often, and does bulk export depend on edition?
• Where is the data hosted, and does that meet any residency or sector requirements you have? Confirm this with the vendor in writing rather than assuming it.
• What happens to your data, and for how long, if you stop subscribing?

The questions that establish control on a custom build

• Who owns the source code, and is that written into the contract?
• Are the hosting, domain, database and third-party accounts registered to your business rather than to the developer?
• Is the documentation good enough for another team to take over?
• Who is responsible for backups, access control, security updates and incident response, and what has actually been agreed?

The data model is a form of control too

Platforms come with standard objects that shape how a business thinks about its customers. That is often helpful, because it imposes a sound structure. It becomes a constraint when your real records do not fit the shape and every report has to reassemble them. A custom build lets the data model mirror the business exactly, which makes reporting cleaner and any later migration more predictable, provided the model is designed carefully in the first place.

Lock-in exists on both sides. Platform lock-in comes from workflows, customisations and integrations that only work there. Custom lock-in comes from undocumented code that only one developer understands. Plan your exit, whichever route you take, before you sign.

Long-term fit is about whether an option can absorb change you cannot yet predict: a new product line, a new region, a second sales team, an acquisition or a customer portal. Judge each option by how it handles change, not by how neatly it matches today’s process.

Platforms absorb common kinds of growth well because the vendor has already met them with other customers. Multi-currency selling, partner and customer portals, additional pipelines and new teams are the sort of change a mature platform expects, although the relevant capability may sit in a higher edition or a separate product. Moving up an edition is a normal part of platform life, and it belongs in your forecast from the start.

The vendor’s roadmap is part of long-term fit as well. Your platform will change whether you ask it to or not: new interfaces, new AI features, retired functions and repackaged editions. HubSpot’s Breeze assistant and Salesforce’s Agentforce are examples of capabilities arriving on the platforms rather than being built by their customers. That is an advantage when the vendor’s direction matches yours and a cost when it does not.

A custom CRM’s roadmap is yours, which is both its strength and its obligation. It changes only when you decide and fund the change, so it never shifts under your team, but it never improves by itself either. Businesses that build successfully treat the CRM as a product with a standing budget, not as a project that ends at launch.

AI is a useful test case. On a platform you largely take the vendor’s version of AI assistance. On a custom build you can add assistance exactly where it helps, such as summarising a long account history or drafting a follow-up for a person to send, but you must scope, build and maintain it. Before assuming either route, it helps to understand what AI agents can realistically do for a business and which tasks still need a person.

A practical test: describe the business as you expect it to look a few years from now, then ask each shortlisted option to show how it would get there and what reaching and running that state would involve.

Building a custom CRM is justified when the gaps between your business and the platforms are structural and lasting — in the workflow, the data model, the integration pattern or your ownership requirements — and when you have the capacity to run software as a product. It is rarely justified by a wish to avoid subscription fees or by frustration with a platform that was poorly implemented.

Signals that point towards building

• The core records and relationships do not resemble contacts, companies and deals, and modelling them on a platform would need customisation throughout.
• Different roles, including external ones such as partners or channel agents, need fundamentally different working screens over the same data.
• The CRM must sit deep inside an operational system you already run, exchanging data in ways no connector supports.
• Ownership of the code, the hosting location or the data structure is a firm business or client requirement.
• Your process is a genuine competitive difference that you do not want to flatten into a standard pattern.

Reasons that usually do not hold up

• “Per-user fees are too high.” A build replaces subscription cost with build, hosting, support and change cost. It may or may not work out better, and it has to be calculated rather than assumed.
• “Our last CRM failed.” Most failed implementations fail on data, ownership and adoption, and those problems follow you into a custom build.
• “We want everything exactly our way.” Exactness has to be specified, built, tested and maintained, and some processes improve when they adopt a standard pattern.
• “We will build it once and be done.” A CRM is never finished. If there is no appetite to own ongoing change, a platform is the better fit.

If the signals point towards building, the next question is budget, and what drives it is scope rather than seat count: pipeline complexity, modules, roles, integrations, automation, migration and reporting. This breakdown of what a custom CRM costs to build in India explains how those drivers combine.

Current starting points for each service are listed on Branditify’s pricing page, and a CRM build itself is priced from the scope that is agreed.

Each option fits a different situation, carries a different risk and needs a different person to run it; none of them is the right answer for every business. The comparison summarises the six decisions above in three terms — when each option fits, what to watch for and who runs it — and it is deliberately not a ranking.

A custom CRM fits when your workflows, data or ownership needs are ones that no platform fits well. The thing to watch is that build and maintenance stay your responsibility for as long as the system runs. It is run by your own team or by a development partner, with a product owner inside the business either way.

Zoho CRM fits when a broad suite of business applications from one vendor suits the company. The thing to watch is how far configuration stretches for your specific process, because fit depends on it. It is typically run by an administrator, often working with an implementation partner.

HubSpot fits when marketing, sales and service need to share one view of the customer. The thing to watch is that costs and features vary by hub and by edition, so a capability you need may sit in a higher tier or a different hub. It is usually run by a marketing or sales operations owner.

Salesforce fits when complex processes need deep configuration and a large ecosystem of partners and tools. The thing to watch is that implementation and administration need specialist skills, which should be planned and budgeted from the start. It is usually run by a dedicated administrator or a partner.

Two cautions apply when reading any comparison like this. First, the platform descriptions set out typical fit, not hard limits; a well-run Zoho implementation can serve a demanding process, and a smaller team can run Salesforce with the right partner support. Second, the “who runs it” column is the one most often ignored and the one that most often decides whether the CRM succeeds. If the person it describes does not exist in your organisation, and you cannot hire or contract them, that option is weaker for you regardless of its features.

An established platform is usually the quicker route to a working CRM, because the core records, pipeline views, permissions and reports already exist. A custom CRM takes longer to reach first use, since each of those has to be designed and built, but it can arrive at a fitted state without a long tail of workarounds.

Speed to a login is not speed to adoption. On every option the slow work tends to be the same: agreeing stage definitions, cleaning and migrating data, building integrations, training people and changing habits. A platform that goes live quickly but is still being ignored months later has not launched in any useful sense.

A few practices shorten the real time to value, whichever route you take:

• Launch the pipeline first. Get enquiries captured, owned and moving through stages before adding quotes, portals or complex automation.
• Migrate only what the team will use. Archive the rest in a form that can still be searched.
• Automate after observing. Rules written before the team has used the system usually automate the wrong thing.
• Phase a custom build. A first release covering capture, ownership, stages and follow-ups can be in daily use while quotes, handover and reporting follow.

Implementation capacity matters as much as the option itself. A platform still needs someone to configure it properly, and a build needs a partner with genuine delivery capacity and a business owner with time for decisions. The fastest option on paper becomes the slowest if nobody inside the company can give it attention.

An ecosystem is everything around the software that you can draw on: connected apps, implementation partners, learning material, community help and people you can hire who already know the system. Established platforms each have one; a custom CRM has your development partner and the wider pool of engineers who know its technology.

The three platforms build their ecosystems differently. HubSpot runs a marketplace of apps that connect to its shared database. Salesforce pairs its platform with Trailhead for learning and a large community of customers, partners and product specialists. Zoho’s ecosystem leans on its own wide family of business applications, alongside partners who implement and extend it. What each offers for your particular stack is worth checking directly, including whether a connector you need is maintained by the vendor, a partner or a third party.

A large ecosystem helps in three practical ways: it shortens integration work for common tools, it makes administrators easier to hire and replace, and it supplies answers when something goes wrong. It does not guarantee that the partner you pick is competent, and it can encourage implementations that bolt on apps instead of fixing the process.

A custom CRM’s ecosystem is narrower but not empty. If it is built on a widely used technology stack, with clean code and real documentation, many developers can pick it up. If it is built on something obscure or left undocumented, the ecosystem shrinks to a single team.

In every case the partner matters more than the size of the ecosystem. The judgement that applies to choosing a digital agency without getting burned applies equally to a CRM partner: look at how they scope, what they refuse to promise, who does the work and what you own at the end.

All four options can report on pipeline by stage, ageing, owner activity, lead source and stuck opportunities; the differences appear when reports need data from outside the CRM, calculations across unusual records, or definitions that do not match the platform’s. Decide which questions your reports must answer before comparing report builders.

On platforms, reporting is strongest for data the platform holds in its standard shape. Report builders let administrators create views and dashboards without code, with depth that generally varies by edition. HubSpot’s shared database means marketing, sales and service activity can be reported together where those hubs are in use. Salesforce offers a data layer designed to unify information from several systems, depending on what you license. Reporting that spans other Zoho applications depends on which ones you use and how they are connected.

On a custom CRM, reports are built to your exact definitions: what counts as a qualified lead, when a deal is ageing, how a forecast is calculated. The cost is that each new report or change of definition is development work, unless a flexible report builder was part of the scope.

A sensible boundary helps either way. A CRM should answer the questions a sales team asks about its own pipeline: what is open and where, what is stuck, what came from which source and what is likely to close. Wider questions that combine sales with finance, operations or delivery are usually better handled by dashboards that report across systems, fed by the CRM rather than squeezed into it.

Whatever you choose, agree metric definitions in writing before configuration begins. Most reporting arguments in a new CRM are disagreements about definitions presented as software problems.

Every CRM will be asked to do something new, and every change has to be maintained afterwards; the options differ in who does that work and what limits it. Extensibility and maintenance should be judged together, because the easiest system to extend is not always the easiest to keep stable.

Extending the CRM when the business asks for more

Platforms extend through configuration first, then apps, then platform-specific development. Salesforce’s low-code and pro-code paths make it highly extensible for teams with the skills. HubSpot extends through its hubs, marketplace apps and, on the relevant editions, custom objects. Zoho extends through custom modules, client scripts and its related applications. Each route stays inside the vendor’s rules, which provides safety and a ceiling at the same time.

A custom CRM extends without a vendor ceiling. A new record type, an unusual approval chain or a partner-facing view is a matter of design and development. The practical limit is the quality of the original architecture: a system built with clear data structures and well-separated services absorbs extension, while a rushed one resists it.

Who maintains what

On a platform, the vendor maintains the core application, the underlying service and its upgrades. You still maintain your configuration, customisations, integrations, data quality and user access, and you absorb any vendor changes that affect them.

On a custom CRM, you maintain everything: hosting, security updates, dependencies, backups, monitoring, bug fixes, documentation and compatibility with every system it connects to. This is ongoing work rather than an end-of-project task, and it continues whether or not new features are being added.

Anyone considering a build should look closely at how a partner approaches custom software built for a specific operating model, including what happens after launch: who is on call, how changes are requested and what the maintenance arrangement covers.

The honest maintenance question is simple. When the person who set up the CRM has moved on, who will understand it well enough to change it safely? If there is no good answer for an option, that option carries more risk than it appears to.

Migration is possible in any direction — spreadsheet to platform, platform to platform, platform to custom or custom to platform — but it is never lossless by default. What survives depends on the quality of the data, the export format, duplicates, field mapping and how much activity history the source system can actually export.

Records usually move well. Contacts, companies, deals and custom fields can be mapped and imported. History is harder: calls, emails, notes, stage changes and attachments may export in limited forms or not at all, and may land as flattened notes rather than structured activity. Automations, workflows, permissions and reports do not migrate; they are rebuilt, which is also the right moment to ask whether they were ever correct.

A dependable migration follows a sequence:

1. Inventory. List every object, field, integration and automation in the current system, and mark what is actually used.
2. Sample export. Export a real sample, including history, and check what the source system provides before promising anything.
3. Map. Decide which old field becomes which new one, and what happens to fields with no destination.
4. Clean. Merge duplicates, standardise values and archive dead records before import, not after.
5. Trial. Run a full test migration and have the sales team check records they know well.
6. Cut over. Freeze changes in the old system, run the final migration and switch integrations in a planned window.
7. Keep an archive. Retain a searchable copy of the old data for as long as your obligations require.

Migrating to a custom CRM has one advantage: the data model can be designed to receive your history, including records that never fitted the old platform. Migrating from a custom CRM to a platform has the opposite challenge, because unusual records must be squeezed into the platform’s structure. Either way, the migration plan should exist before the new system is chosen, since it can change the answer.

Many businesses are best served by neither extreme: they keep an established platform as the system of record and build custom services around it where the platform is weak. A hybrid can keep most of a platform’s speed and ecosystem while meeting the requirements that would otherwise force a full build.

Common hybrid patterns include:

• A custom front end for a specific role, such as a field team, channel partners or franchisees, reading and writing platform records through its API.
• An integration service between the CRM and operational systems, handling mapping, retries and conflicts that a simple connector cannot.
• A specialised quoting or configuration tool for complex products, sending finished quotes back to the opportunity.
• An automation or AI layer that watches CRM events, drafts follow-ups, summarises records or routes enquiries, with a person approving what goes out.
• A custom customer portal where the platform’s own portal does not match how clients need to interact.

Hybrids carry costs of their own. Every custom service depends on the platform’s API remaining stable and available on your edition, and it creates two things to maintain instead of one. Ownership also splits: the platform administrator and the development partner must agree who is responsible when data looks wrong.

Automation is the most frequent entry point. Chasing an unanswered quote, flagging a deal with no next step or routing a new enquiry can often be handled by rules or agents working alongside the CRM, which is the kind of work that AI agents and automation services should scope carefully, with nothing running until it has been agreed.

A well-designed hybrid is a sign that requirements have been understood precisely: standard where standard works, custom only where it earns its place.

A fair evaluation tests every option against the same written scenarios, using your own data and your own people, and compares whole operating models rather than demonstrations. Without that discipline, the option with the most polished presenter tends to win.

1. Write the requirements as scenarios. “A WhatsApp enquiry arrives on a Sunday, is assigned on Monday, is quoted twice and is won; show every step.” Scenarios expose fit, while feature checklists hide it.
2. Separate must-haves from preferences. Limit must-haves to what would genuinely stop the team working without them.
3. Include your hardest cases. Give every option the exceptions from your process map, not only the happy path.
4. Use real data. Load a sample of your actual records into trials or prototypes, including the messy ones.
5. Involve the people who will use it. A rep, a manager and whoever will administer the system should each work through their own part.
6. Compare the operating model. For each option, set out who will configure, build, administer and maintain it, which editions or add-ons the scenarios required, and what ongoing cost follows.
7. Cost the whole life, not the first year. Include subscriptions or build cost, implementation, integrations, migration, training, administration and change over several years.
8. Check references for the implementer, not only the software. Ask how the partner handled scope changes and handover.

A custom option needs a scoped estimate rather than a guess before it can be compared fairly, and understanding how custom software projects are priced helps you judge whether an estimate reflects real scope.

Record the reasons for the final decision in a short document. When the business changes, that record tells the next team whether the original reasons still hold, which is a far better basis for switching than frustration.

The right questions move the conversation from features to the operating model: what this will take to run well, who will do it and what happens when it stops fitting. Ask them in writing and compare the answers side by side.

For platform vendors and implementation partners

• Which edition, hubs or add-ons do our scenarios need, and which of our requirements would need scripting or code?
• What exactly can we export, including history and attachments, and how?
• Which of our integrations have maintained connectors, who maintains them, and what does each one sync in each direction?
• Which planned platform changes could affect our configuration?
• Who will do the implementation work, and what does support look like after go-live?

For a custom CRM development partner

• How will you confirm our integrations are possible before we commit to scope?
• Who owns the code, the hosting accounts and the documentation at the end?
• Which parts will our own team be able to configure without a developer?
• How will you establish what our existing data can bring across, and from what sample?
• What does maintenance cover, how are changes requested and how is urgent work handled?
• Which features, including any automation or AI assistance, are inside the scope, and which are explicitly outside it?

For your own team

• Who will own the CRM day to day, and do they have the time and authority?
• Which parts of our process are genuinely distinctive, and which are habits we would happily standardise?
• Can we name the person who would run each option we are considering?
• What would make us regret this choice later, and how would we notice early?

If the answers point clearly to one option, the decision has largely made itself. If they point in different directions, the disagreement is usually about process fit or administration, and those are the two decisions worth revisiting before anything is signed.