- The right answer depends on how differentiated your research process actually is, your internal technical capacity, and three-year TCO — not year-one cost.
- AppExchange tools carry three underestimated risks: data residency exposure, sync reliability degradation, and switching costs higher than they appear.
- A custom Salesforce module is a maintain-forever commitment. Budget ongoing developer time from day one.
- A fully custom CRM is a product, not a project. Most organisations underestimate the perpetual engineering ownership required.
- AI-native research tools have emerged as a credible fifth option. Run a 30-day pilot before concluding custom is necessary.
The request comes in from sales leadership: they need a proper account research module. Something that surfaces the right information about a prospect before a rep picks up the phone — company context, recent news, technology stack, relevant contacts, intent signals. The data exists. The question is how to make it usable inside the workflow your team already operates in.
You have four options, each with a different risk and cost profile. Most teams pick one without properly evaluating the others, because the evaluation requires considering costs that don't show up in the initial budget conversation: ongoing maintenance, platform dependency, data residency exposure, and the compounding cost of technical debt. This article works through all four — and a fifth option that is changing the calculus — so you can make the right decision for your situation rather than the default one.
The Three Variables That Should Drive Your Decision
Before evaluating options, you need honest answers to three questions. They determine which option is appropriate and which ones will cost more than they save.
How differentiated is your research process? If your reps need standard firmographic data, news alerts, and contact information — the same things every B2B sales team needs — you do not have a differentiated research process. You have a commodity requirement, and you should solve it with a commodity tool. If your research process involves proprietary scoring models, unusual data sources, industry-specific signals, or output formats that no commercial tool produces, you have something genuinely differentiated that may justify building.
What is your internal technical capacity? Building anything — a custom Salesforce module or a fully custom CRM — requires ongoing engineering capacity, not just initial build capacity. Salesforce platform updates happen three times a year and regularly break custom Apex code. A custom CRM requires security updates, mobile support, schema migrations, and a continuous feature roadmap. If you do not have a team that can absorb this work indefinitely, you are making a decision to create a support burden that will eventually be passed to someone who did not make the original choice.
What is your three-year total cost of ownership? Most build-vs-buy decisions are made on year-one cost. The right decision is made on year-three cost, which includes initial build, ongoing maintenance, platform licences, integration support, and the productivity cost of workarounds when things break. The option that is cheapest to start is rarely the cheapest to own.
Option 1 — Configure Native Salesforce
What this means in practiceUsing Salesforce's existing objects, fields, page layouts, and Lightning components to create a research-focused view of an account — pulling in data from existing sources via standard integration patterns, displaying it in a structured layout your reps can use before a call.
When it is the right answerWhen your research requirement is primarily about presentation and organisation rather than data enrichment. If the data you need already exists in your CRM or in tools you already pay for — LinkedIn Sales Navigator, your MAP, your website analytics — and the problem is that it is not surfaced well in the rep's workflow, native configuration can solve this without additional cost or complexity. It is often significantly underexplored before teams jump to AppExchange.
Where it falls shortNative configuration cannot enrich your records with external data it does not already have access to. If your research requirement involves pulling in news, technographic data, intent signals, or contact information from third-party sources, native configuration alone is insufficient. You will hit the limits of what is achievable without custom code or a third-party integration.
Total cost of ownershipLow. If you have Salesforce admins, this is primarily their time. No additional licence cost, no integration maintenance, no vendor dependency. The risk is that it requires admin capacity to maintain as your process evolves, and the output is constrained by what Salesforce can display natively.
Option 2 — AppExchange Integration
What this means in practiceInstalling a third-party managed package from the Salesforce AppExchange that provides account and contact research capability inside your Salesforce org — tools like ZoomInfo, Cognism, Clearbit, or more specialised research overlays.
When it is the right answerWhen your research requirement is standard — firmographic enrichment, contact data, news, and intent signals — and you want it delivered inside Salesforce without a custom build. AppExchange tools in this category are mature, have large user bases, and typically have reliable Salesforce integration because their entire value proposition depends on it working.
The risks most teams underestimateThree specific risks are consistently underweighted in AppExchange evaluations.
First, data residency and compliance exposure. When an AppExchange tool enriches your CRM records with third-party data, that data flows from the vendor's systems into your Salesforce org and potentially back out again for matching and update purposes. Depending on your contractual obligations to your customers and the data protection regulations applicable to your market — GDPR, UK GDPR, sector-specific requirements — this data flow may create compliance obligations you have not modelled. The vendor's DPA covers their processing. It does not cover what you do with the data once it lands in your org.
Second, sync reliability degrades over time. The integration that worked reliably at deployment develops problems as both platforms update independently. Field mappings break. Sync jobs start failing silently. Records that should be enriched are not, and your team stops trusting the data without necessarily knowing why. This degradation is predictable and rarely disclosed in sales conversations. Build a data quality monitoring process from day one rather than discovering the problem when a rep shows up to a meeting with stale information.
Third, the switching cost is higher than it appears. After 18 months of enrichment, your CRM records contain data from the vendor's proprietary database. When you want to change vendors, that data does not transfer — their data licence does not follow the records. You are starting from scratch with a new vendor and a CRM full of stale fields from the previous one.
Total cost of ownershipMedium to high. AppExchange research tools are typically priced per user per year and are not cheap — budget £50–150 per user per month for a credible enrichment tool depending on data depth and geography. Add integration maintenance, the internal cost of monitoring data quality, and the eventual switching cost. Over three years this is often the most expensive option despite appearing mid-range at purchase.
Option 3 — Custom Module Inside Salesforce
What this means in practiceWriting custom Apex code, Lightning Web Components, and integration logic to build a bespoke research module that lives within your Salesforce org — pulling from APIs you select, displaying data in layouts you design, with scoring or prioritisation logic specific to your process.
When it is the right answerWhen your research process is genuinely differentiated — specific data sources your competitors are not using, proprietary scoring models, industry-specific signals — and you want to deliver it inside the Salesforce environment your team already operates in. The key requirement is a development team with Salesforce expertise that can maintain the code across platform releases.
The platform dependency riskSalesforce releases three major updates per year — Spring, Summer, and Winter. Each release deprecates APIs, changes platform behaviour, and occasionally breaks custom code that relied on previously stable interfaces. A custom Salesforce module is not a build-once asset. It is a build-and-maintain commitment that requires a developer to review every release, test the module against it, and update code as needed. Teams that build without accounting for this ongoing cost often end up with a module that works well for 12 months and then degrades as the platform evolves around it.
Total cost of ownershipHigh upfront, medium ongoing if you have the internal capacity. Initial build for a meaningful research module is typically 6–12 weeks of Salesforce developer time depending on complexity. Ongoing maintenance is 2–4 days per quarter minimum to stay current with platform releases. If you do not have internal Salesforce developers, agency costs for this maintenance are significant.
Option 4 — Fully Custom CRM with Custom Modules
What this means in practiceBuilding or commissioning an entirely custom CRM application — your own data model, your own UI, your own workflow engine — with an account research module as one component of a broader custom system.
When it is genuinely the right answerThis option is right in a narrow set of circumstances that are less common than the enthusiasm for custom builds usually implies. Specifically: your sales process has sufficiently proprietary logic that no commercial CRM can accommodate it without prohibitive configuration cost; you have an engineering team that can own the platform indefinitely; and you have validated that the commercial alternatives are structurally unable to meet your requirements — not just that they are inconvenient or require configuration effort.
The validation step is the one most frequently skipped. Teams often reach the conclusion that a custom CRM is necessary without seriously stress-testing what a well-configured commercial platform could deliver. The question to ask before commissioning a custom build is not "could we build something better?" — you almost certainly could — but "is the delta between what we could build and what a commercial platform delivers worth the perpetual engineering commitment required to maintain a CRM?"
What is consistently underestimatedA custom CRM is not a project. It is a product. It requires a roadmap, a product owner, ongoing development capacity for new features, security updates, mobile support, performance optimisation, and the eventual cost of rebuilding components that become technically outdated. Organisations that build a custom CRM and then fail to staff it appropriately end up with a system that is worse than the commercial alternative within three to four years — at which point the switching cost back to a commercial platform includes migrating data out of a bespoke schema that no standard tool understands.
Total cost of ownershipVery high. Initial build for a meaningful custom CRM with a research module is a six-figure engineering investment. Ongoing cost to maintain and evolve it is a dedicated engineering function, not a part-time commitment. This option is correct for a small number of organisations. It is chosen by a much larger number.
Option 5 — AI-Native Research Tools
A fifth option has emerged in the last two years that is changing the calculus significantly, particularly for teams that have been drawn toward custom builds because no existing tool produced the right output.
AI-native research tools — a category that now includes both standalone products and modules within newer CRM platforms — use large language models to synthesise account intelligence from multiple sources in real time rather than enriching records from a static database. The output is qualitatively different from traditional enrichment: instead of populating a field with a company's headcount, the system can generate a pre-call brief that synthesises recent news, known contacts, relevant product triggers, and suggested angles — formatted for how your team actually uses the information.
The implications for the build-vs-buy decision are significant. Several capabilities that previously required a custom build — because no AppExchange tool produced the right format or used the right data sources — can now be delivered by AI-native tools without the engineering commitment. The key evaluation question is whether the tool's output can be consumed inside your existing CRM workflow, or whether it requires yet another context switch that your team will eventually stop making.
This option is evolving quickly. Point-in-time evaluations go stale fast. The right approach is a structured 30-day pilot with your actual reps using it on real accounts before any commitment, evaluated against the specific output your team needs rather than a generic demo scenario.
The Decision Framework
| Option | Right when... | 3-year TCO | Key risk |
|---|---|---|---|
| Native config | Data already exists; presentation is the problem | Low | Limited to existing data sources |
| AppExchange tool | Standard enrichment need; want fast deployment | Medium–high | Data residency, sync degradation, switching cost |
| Custom Salesforce module | Differentiated process; internal SF dev capacity | High | Platform update maintenance burden |
| Fully custom CRM | Proprietary process logic; dedicated engineering team | Very high | Becomes a product requiring indefinite ownership |
| AI-native tool | Need synthesised intelligence, not field enrichment | Medium (evolving) | Category is early; output quality varies significantly |
1. Can you write down precisely what information a rep needs before a call, where it currently comes from, and what format is most useful? If not, you are not ready to evaluate solutions — you are ready to specify the requirement.
2. Is your research process differentiated from what a standard B2B sales team needs? If an honest answer is no, the default should be a commercial tool, not a custom build.
3. Do you have internal capacity to maintain whatever you build or configure indefinitely — not just to launch it? If the answer is no, options 3 and 4 carry risks that are not in the initial budget conversation.
4. Have you run a 30-day pilot of the leading AppExchange tools and an AI-native alternative with real reps on real accounts before concluding that a custom build is necessary? Most organisations have not. The pilot is cheaper than the first month of a custom build.
5. If you are evaluating AppExchange tools: have you reviewed the vendor's DPA against your customer data obligations and modelled the data flows that will occur during enrichment? If not, do this before signing.
The Recommendation Most Organisations Should Start With
For the majority of sales teams — including those with genuinely sophisticated research requirements — the right starting point is a parallel evaluation of the best AppExchange tool in your category and the best AI-native tool, run simultaneously as a 30-day pilot with a defined set of accounts and a clear success criterion.
The output of that pilot tells you whether a commercial solution is sufficient. If it is, you save the engineering investment and take on a manageable vendor dependency. If it is not — if neither commercial option produces the research output your team actually needs in the format they will actually use — you have the evidence required to justify a custom build, and you know specifically what the commercial options failed to deliver. That specification is the foundation of a custom build that will actually work rather than one built from assumptions about what the team needs.
The custom CRM question deserves the same discipline. The right question is not whether you could build something better than what exists commercially — you could. It is whether your process is differentiated enough, and your engineering capacity is sufficient, to justify owning a CRM as a product indefinitely. For most organisations, the honest answer is no. For a meaningful minority, it is genuinely yes. The difference between them is usually clearer after a rigorous commercial evaluation than before it.