Build a custom CRM vs. buy Salesforce Enterprise—what's the real long-term cost delta?

What the cost delta actually measures, and why the usual framing gets it backwards

Almost every build-versus-buy debate opens with the wrong arithmetic. Someone puts Salesforce Enterprise list price — $165 per user per month — on one side of a whiteboard, puts three engineer salaries on the other, multiplies both by seat count and years, and declares a winner. That comparison is not merely imprecise. It is structurally invalid, because it compares a fully operational, supported, road-mapped product against a payroll line item. The honest comparison is between two operating companies: one you rent, and one you agree to become.

When you buy Salesforce Enterprise, you are not buying software in the way you buy a laptop. You are buying the amortized output of a very large R&D organization, an uptime SLA with contractual teeth, a stack of third-party attestations (SOC 2, ISO 27001, FedRAMP for the government-cloud configurations), a partner ecosystem of hundreds of thousands of certified consultants, three major releases a year that arrive whether you asked for them or not, and roughly two decades of edge cases already discovered and solved by somebody else's angry customer. When you build, you commit to reproducing a meaningful fraction of that — and then to sustaining it indefinitely, with no one to escalate to at 2 a.m.

The concept that resolves the entire debate is amortization of fixed costs across a customer base. Software has an unusual cost structure: the marginal cost of serving one more customer is near zero, but the fixed cost of building and maintaining the thing is enormous and permanent. A platform vendor spends heavily on R&D every year; every customer receives the benefit of the full spend and pays only a fraction of it. That is why a license fee is not markup. It is your fractional contribution to a shared, continuously funded engineering effort that no single buyer could afford alone.

Build a custom CRM and you become a software vendor with exactly one customer: yourself. You bear one hundred percent of the fixed cost — the build, the maintenance, the security posture, the roadmap — and you amortize it across a customer base of one. There is no spreading, no sharing, no leverage. You have voluntarily taken the most expensive possible seat in software economics, the single-customer vendor, and you are competing on capability against organizations amortizing the identical fight across six orders of magnitude more customers.

This has a precise corollary that defines the only legitimate exit from buying. Building becomes rational when the software produces value unique to you — a moat, so the absence of amortization is irrelevant because no vendor could sell you the differentiated capability anyway — or when your own internal user base has grown large enough that in-house amortization competes with the license you would otherwise pay. Outside those two conditions, buying wins on cost, because amortization is not a preference. It is arithmetic.

So the correct first question is never "what's the delta." It is: is CRM functionality a source of durable competitive advantage for us, or is it commodity infrastructure? Cost follows strategy; it does not lead it. For well over ninety percent of companies, CRM is commodity infrastructure, the exercise collapses to procurement, and the RevOps team should be negotiating rather than architecting. The organizations that burn money are the ones that treat a commodity as a moat — and they usually discover the mistake somewhere around month twenty-six of a build that was supposed to take twelve.

It is worth fixing some vocabulary, because these arguments routinely founder on imprecise language. TCO means every cost, visible and buried, across the full horizon — people, infrastructure, opportunity cost, risk-adjusted contingency. Fully-loaded headcount means salary multiplied by 1.4 to 1.6 to capture benefits, equity, payroll tax, management overhead, equipment, and facilities; a "$180K engineer" costs $250K to $290K. System of record means the single authoritative store for an entity that all other systems defer to. Buy-and-extend means renting the commodity platform of record and building only the thin, proprietary surface on top via API. Software entropy is the continuous decay of software as dependencies break, threats evolve, and expectations rise — the force that makes maintenance permanent rather than occasional. And crossover seat count is the user count at which license spend exceeds the cost of a dedicated internal product team. Get those definitions agreed before anyone opens a spreadsheet, and half the argument evaporates.

How to actually run the evaluation, start to finish

The evaluation is a sequence of discrete tests, not a continuous slider where big companies build and small ones buy. Run them in order and stop at the first one that fires.

Step one: test the moat, in one sentence. Write down what makes your customer-relationship logic something a competitor structurally cannot replicate. Not "we have unusual sales processes" — everyone believes that, and almost everyone is wrong. A real moat sounds like: our matching engine *is* the relationship model, or our counterparty risk system encodes proprietary logic no vendor sells. If you cannot state it in one sentence to a skeptical board member who is looking for holes, you do not have one. This test alone eliminates most build cases.

Step two: verify the wall, don't assume it. Air-gapped classified workloads, data-residency law no vendor region satisfies, sub-millisecond latency no multi-tenant cloud can meet, sovereignty mandates barring foreign-owned providers — these are real, and they are rare. Before building a fortress, confirm the wall exists. Government-cloud configurations, regional infrastructure like Hyperforce, and FedRAMP authorizations dissolve a large share of the walls people assume are blocking. Have someone in compliance produce the specific citation, not a recollection.

Step three: run the seat arithmetic honestly. Below roughly 10,000 to 15,000 seats, scale alone never justifies a build. Above it, the amortization argument genuinely starts to invert because your internal user base is now large enough to spread R&D across. Model the crossover explicitly rather than asserting it.

Step four: if none of the first three fired, buy — and then instrument. Go live on the platform, run it for two or three quarters, and measure precisely where it constrains the business. Most assumed constraints evaporate on contact with a properly configured system. The few that survive are your real candidates for custom work, and now you have operating data instead of speculation.

Step five: extend selectively. For each surviving constraint, build one thin custom service on the platform. A pricing engine. A propensity model. An industry-specific quoting flow. Each is small, bounded, individually justified, and independently killable — not a bet-the-company build.

What makes this sequence valuable is that it converts a single high-stakes, irreversible decision into a chain of small reversible ones. The all-at-once framing — "let's decide this quarter whether we build our own CRM" — destroys that optionality for no reason. Most companies that are convinced they need to build discover somewhere around step four or five that the bought platform plus three thin extensions covers everything they were worried about.

One more discipline belongs in the sequence: build the board model over a ten-year horizon, not three. A three-year window flatters the build because it captures the cheap v1 and hides the operating decade entirely. Use fully-loaded headcount. Include an explicit opportunity-cost line. Apply a fifty to one hundred percent contingency reserve to the build figure only — the buy figure is contractually bounded and needs far less. And run sensitivity analysis at 250, 500, 1,000, and 5,000 seats, because the crossover seat count is the genuinely interesting output, more interesting than any single point estimate.

What each path actually costs, with real ranges

Take a reference company: 500 CRM seats, mid-market, standard B2B motion, growing to roughly 650 seats by year ten.

The buy side starts with a license that nobody actually pays at list. Enterprise lists at $165 per user per month billed annually — about $1,980 per user per year — and enterprise discounts of fifteen to forty percent are routine above a hundred seats. Three-year prepay and credible competitive pressure from Microsoft Dynamics 365 or HubSpot push deeper. A realistic blended rate after negotiation lands around $110 to $135 per user per month for the base license.

But a bare Enterprise license is rarely sufficient. Sales Engagement, CPQ, higher sandbox tiers, additional API capacity, Data Cloud, Einstein and Agentforce credits, Service Cloud — each carries its own per-user or consumption fee. A realistically equipped seat lands at $200 to $320 per user per month all-in. Storage and AI-credit consumption are metered and grow quietly as your install ages and accumulates records. For 500 seats, a defensible blended figure is $2,400 to $3,800 per user per year, or roughly $1.2M to $1.9M annually in pure subscription.

Implementation follows a durable heuristic: for every $1 of first-year license, budget $1 to $3 of implementation. That covers solution design, configuration, migration off the legacy system, custom objects and flows, integration wiring, testing, and training. A clean single-motion company lands near 1:1. A multi-entity, multi-currency, channel-plus-direct business with heavy CPQ lands at 1:3 or worse. Dirty legacy data is the single largest overrun driver — deduplication and normalization routinely eat twenty to thirty percent of an implementation budget. Systems integrators charge $150 to $300 per hour; an internal admin team is cheaper per hour, slower, and carries its own opportunity cost. For the reference company at roughly $1.5M year-one license, implementation runs $1.5M to $3.5M one-time, spread over six to fourteen months.

Then it costs money to run. Salesforce admins at one per thirty to a hundred users means three to five FTE, roughly $450K to $900K annually. Declarative developers building flows, light Apex, and Lightning Web Components add one to three FTE at $200K to $600K. Premier Success runs about a thirty percent uplift on license if you take it. Managed-services retainers for periodic enhancement work run $150K to $400K. Add-on creep — new seats, new clouds, AI credits — adds $100K to $300K a year if ungoverned. Training and enablement, $80K to $200K.

Here is the part people miss: the admin layer does not disappear in the build scenario. Whether you buy or build, someone owns the system, configures it, trains users, and manages change. That cost is roughly neutral between the two paths, which means it arguably should be excluded from the *delta* even though it must appear in any absolute TCO shown to a board. Net of shared admin, the buy path lands at $14M to $22M over ten years — and critically, that number is forecastable, because subscription is contractual and visible, the implementation ratio is drawn from thousands of comparable rollouts, and the operating layer scales along documented ratios.

The build side starts with an estimate that is reliably wrong by a factor of three to eight. Not because engineers are dishonest — the causes are structural. The planning fallacy builds estimates from the imagined happy path and excludes integration friction, rework, and edge cases. Scope is invisible at estimation time: a CRM *looks* like accounts, contacts, opportunities, and a pipeline view; it is actually territory management, forecasting hierarchies, role-based sharing rules, audit trails, deduplication, mobile, offline sync, a reporting engine, bulk data tooling, sandbox environments, and a public API surface. The v1 fallacy prices the first shippable version and files the rest under "iteration," when a CRM's cost is dominated by the decade after v1. And opportunity cost never makes it onto the spreadsheet at all.

A genuinely usable v1 — not a toy, but something a 500-person revenue org can run on — breaks down roughly as: discovery and architecture, two to four months at $300K to $600K; core engine (accounts, contacts, opportunities, activities, pipeline), six to twelve months at $1.5M to $3.5M; reporting and dashboards, three to six months at $600K to $1.4M; integrations across email, calendar, marketing, billing, and data, four to eight months at $800K to $2.0M; admin tooling, roles, sharing, and audit, three to six months at $500K to $1.2M; mobile or offline PWA, three to six months at $400K to $1.0M; QA, pen testing, SOC 2 prep, and load testing, ongoing at $400K to $900K. Total: eighteen to thirty months and $4.5M to $10.6M — during which your GTM team is still running on the legacy system.

Then comes the line that decides most honest analyses: the permanent platform team. Two to three backend engineers at roughly $220K fully loaded, one frontend at $200K, half to one DevOps/SRE at $230K, half to one product manager at $230K, half to one QA at $170K. That is 4.5 to 7 FTE and $1.05M to $1.49M per year, forever — $10.5M to $15M over the decade before infrastructure, before the v1 build, before anything goes wrong. Hosting for a 500-user transactional system (compute, managed databases, search, object storage, CDN, monitoring, logging) adds $150K to $500K annually and grows with data volume. Around year five to seven, the v1 architecture shows its age and someone proposes a version 2 re-platform: another $3M to $8M, with its own overrun profile. Security, compliance, and recurring audit work, $1M to $3M. Contingency for the documented 3–8x reality, $7M to $10M.

Build total: $28M to $52M over ten years — roughly two to two and a half times the buy path, arriving twice as slowly, and unbounded on the high end because you control none of the forces that make software expensive.

And that omits the largest number in the analysis for a software company: opportunity cost. Those 4.5 to 7 platform engineers are not generic overhead. They are senior product engineers who would otherwise ship revenue-generating features in a company where engineering capacity is the binding constraint on the roadmap. Their true economic cost is the salary line *plus* the foregone product value, which can double or triple the effective figure. This is precisely why building is most dangerous for the companies most tempted — software companies, reasoning "we have great engineers, they could just build this." They almost certainly could. The question was never capability. It is whether internal CRM plumbing is the highest-value use of the scarcest resource in the building, and for a software business it essentially never is.

For a manufacturer, distributor, or services firm the opportunity-cost argument weakens — engineering is not the revenue engine. But those organizations are also least likely to have the product-engineering bench, SRE discipline, and security maturity to operate a custom CRM well. Lower opportunity cost, higher execution risk. There is no profile where the build comes free.

Where teams get this wrong, on both sides of the decision

The sunk-cost spiral is the most expensive failure mode in the entire category, because it converts a bad decision into a catastrophic one. The build runs over budget and behind schedule, leadership reasons "we've spent $6M, we can't stop now," and pours in another $6M. The only defense is a decision rule set *before* the first line of code: a kill-switch milestone — if v1 is not in production at month thirty, we migrate to a bought platform — pre-committed in writing, with a named executive owner who is expected to pull it.

The understaffed-team trap kills builds slowly rather than dramatically. The company ships v1, then under cost pressure shrinks the platform team from six to two. The CRM does not collapse; it rots. Bugs accumulate, the roadmap stalls, patches lag, and eighteen months later the sales org is routing around the system with private spreadsheets. The rule is unambiguous: if you build, the platform team is a permanent, protected fixed cost. If you cannot commit to funding it through a downturn, you cannot afford to build in the first place.

Estimate anchoring poisons the entire process. The first number — always low — becomes the reference point against which reality is judged, so predictable overruns feel like team failure rather than the historical norm. Counter it by presenting estimates as ranges with explicit variance disclosure, and by having the model reviewed by someone who has *operated* a custom CRM for years, not just built one. Those are different people and they give very different reviews.

Reversibility blindness is the quiet one. Weight decisions by the cost of being wrong. A Salesforce implementation that underperforms is remedied by a migration project — painful, costed in months, bounded, and well-trodden, with a large pool of consultants who do exactly that for a living. A custom CRM that fails means rebuilding GTM tooling from scratch while the revenue org limps along on broken software; the realistic cost is two to four years of suppressed sales velocity, which for a growth-stage company can exceed the entire build budget. Document the migration path *before* building, or you have not written a business case.

Buy-side failures are real too, and naming them is what makes the analysis credible rather than promotional. Over-customization: hundreds of custom fields, deeply nested flows, sprawling Apex triggers, until the bought platform is as brittle as a custom build while losing the upgrade-safety that justified buying. Fix: configuration governance, a deliberate bias toward standard objects and declarative tooling, and a review gate on net-new code. Under-adoption: the platform is bought, configured, and ignored, becoming an expensive reporting fiction while reps run on memory and spreadsheets. Fix: treat adoption as change management, not IT rollout — executive sponsorship, manager accountability, and workflow design that makes the CRM the path of least resistance. Big-bang go-live: the whole org cuts over on one date with thin testing, and launch becomes crisis. Fix: phase by team or geography, each phase feeding the next. The orphaned admin: one overstretched person owns everything and walks out the door with the institutional knowledge. Fix: a documented, multi-person admin function — the same key-person discipline the build side needs, applied to the buy side.

The point is not symmetry for its own sake. It is that buy-side failure modes are process and governance failures — well understood, cheap to fix, rescuable with better management. Build-side failure modes are structural and expensive. A badly run Salesforce implementation gets turned around. A badly run custom CRM build can sink a company. The asymmetry persists even in how the two paths fail.

There is also an accounting trap worth flagging to any CFO. Buying is clean operating expense: smooth on the income statement, easy to forecast, contractually known cash outflow. A build is a mix — development cost may be partially capitalized as internal-use software and amortized, while maintenance is expensed. That can make the build look artificially attractive in years one and two even when its true ten-year cash cost is two to three times higher. Show the board the cash view, discounted, not just the P&L view. For venture- or PE-backed companies there is a further sting: investors increasingly scrutinize software-development capitalization in quality-of-earnings work, so a large internal-CRM capitalization line can actively *reduce* perceived earnings quality at diligence. The buy path carries no such penalty.

And the build-side tail risks deserve probability-weighted dollars, not hand-waving. A custom CRM holds the entire customer and pipeline dataset; a small platform team is structurally more likely to lag on security practice than a vendor with a dedicated security organization and a bug-bounty program, and a serious breach runs into the millions before you count reputational damage. Key-person departure concentrates undocumented knowledge in a few heads, and velocity collapses when the lead architect leaves. Compliance misses can block entire market entries when you expand into a new geography or start selling into a regulated vertical and discover the attestation you need is eighteen months away. The subscription fee has, among other things, purchased insurance against most of these.

Choosing well: the narrow cases for building, and the answer for everyone else

Honesty requires steelmanning the build, because there are genuinely three cases — plus a hybrid — where it is correct.

When CRM logic is a true competitive moat. Not "we have a CRM" but "our relationship model is something competitors structurally cannot replicate." A marketplace whose matching engine *is* the relationship model. A quant trading firm whose counterparty system encodes proprietary risk logic. A vertical SaaS company whose CRM and core product are inseparable. Here TCO stops being the frame; the spend is R&D investment in the moat, and it should be governed like product investment, with a roadmap and success metrics rather than a budget line.

When a hard regulatory, residency, or latency wall exists and has been verified. Classified defense work requiring air-gapped operation. A jurisdiction whose residency law no vendor region satisfies. Latency requirements no multi-tenant cloud can meet. Sovereignty mandates barring foreign-owned providers. Real, rare, and frequently assumed where it does not apply — check government-cloud and regional-infrastructure options before conceding the point.

When extreme scale inverts the arithmetic. At 20,000 seats, even a deeply discounted $100 per user per month is $24M annually — $240M across a decade. Against that, a dedicated internal product team of twenty to thirty engineers at roughly $6M to $9M per year is genuinely cheaper, and the amortization argument flips because your internal user base is now large enough to spread R&D across. The crossover is profile-dependent but typically lives north of 10,000 to 15,000 seats. Many enterprises at that scale still buy — for ecosystem, compliance, and risk reasons — but at least the spreadsheet argument is intellectually honest rather than a vanity project.

And the hybrid that is the right answer far more often than pure build: buy-and-extend. Keep the vendor platform as system of record for accounts, contacts, opportunities, and compliance trails. Build only the thin, genuinely proprietary layer — a pricing engine, a custom propensity model, an industry-specific quoting flow — as services integrating via API. Apex, Lightning Web Components, Heroku, and external services exist precisely for this. You capture moat value on the differentiated fifteen percent while the vendor carries the commodity eighty-five.

Run the archetypes and the pattern holds. A 120-person Series B SaaS company with fifty CRM seats: buying lands at $150K to $400K per year all-in, and a build would consume most of the engineering org — the opportunity cost alone threatens survival. Buy, unambiguously. The 500-seat mid-market reference: buy as system of record, and if exactly one process is genuinely proprietary — a usage-based pricing engine, say — build that single service on the platform. An 18,000-seat global enterprise: genuinely contested, model it seriously, and expect ecosystem and risk considerations to still push many toward buying. A defense contractor with a verified air-gap mandate: build or self-host, because cost stopped being the deciding variable. An 800-person lending fintech whose edge is a proprietary underwriting model: the textbook buy-and-extend case — the CRM core is commodity, the underwriting service is the moat, and rebuilding the commodity core would be pure waste.

Two adjacent notes for RevOps leaders, because this decision never arrives alone. First, running a credible build analysis is itself a procurement lever. Vendor account teams discount materially harder against a costed internal-build alternative or a live Dynamics 365 or HubSpot evaluation. The analysis frequently pays for itself in license savings of ten to twenty-five percent even when its conclusion is "buy." Time the deal to the vendor's quarter or fiscal-year end when discount authority is most flexible. Negotiate the renewal *before* signing the initial contract — price-protection caps, uplift ceilings, ramp schedules — because leverage shifts decisively to the vendor once you are embedded. And separate the platform decision from the add-on decision rather than bundling CPQ, Data Cloud, and AI credits into one signature, which preserves both budget control and future leverage.

Second, the same framework applies to every neighboring layer of the stack, and it is worth applying deliberately rather than re-litigating each time. Marketing automation, CPQ, data enrichment, forecasting tooling, revenue intelligence — each carries a build-versus-buy question with identical structure. The commodity 80 percent gets rented; the differentiated slice gets built. Teams that adopt one consistent rule across the stack end up with a coherent architecture. Teams that decide case-by-case end up with three homegrown tools nobody maintains and a vendor sprawl nobody governs.

On AI, which now appears in every version of this conversation: coding assistants genuinely accelerate a build, but the acceleration is incomplete and symmetric. It speeds the *coding* of v1. It does not eliminate the permanent platform team, the operating burden, the security obligation, the compliance work, or the opportunity cost — and those are the dominant costs. Meanwhile the vendor ships AI capability into the platform continuously, funded by the same amortization engine, so a builder must now also self-fund an AI roadmap to stay competitive. Net effect: both curves drop modestly, the gap persists. Treat any pitch claiming AI has flipped this decision with real skepticism.

The bottom line for the large middle of the distribution: buying is decisively cheaper across a real ten-year horizon, typically by a factor of two to two and a half, while also reaching value faster, forecasting more reliably, carrying less key-person risk, and remaining reversible if wrong. The most expensive CRM decision was never paying the license. It is discovering, two to four years and tens of millions in, that you painstakingly reconstructed a commodity and called it a moat.

Related questions

How long before a custom CRM build reaches parity with a bought platform?

Realistically eighteen to thirty months for a v1 a 500-person revenue org can actually run on — and v1 is not parity. Feature parity with a mature platform is not a target serious teams set; they scope deliberately narrower and accept the gaps.

Does the answer change if we already have strong engineers sitting idle?

No. Idle capacity is temporary; the platform team is permanent. And engineers assigned to internal CRM plumbing are engineers not shipping product, which is usually the largest unmodeled cost in the entire analysis for a software company.

What discount should we expect off Enterprise list price?

Fifteen to forty percent is routine above a hundred seats, deeper with three-year prepay and a live competitive evaluation. Time the signature to the vendor's fiscal-year end and lock renewal uplift caps into the original contract while your leverage is at its peak.

Can we start with a bought platform and migrate to custom later?

Yes, and that is the recommended sequence. Buy, run it for two or three quarters, measure which constraints are real, then build thin extensions against the survivors. Staging converts one irreversible decision into a chain of reversible ones.

Where does buy-and-extend break down?

When the "thin extension" quietly grows into a parallel system of record. Watch for custom services accumulating their own account and contact tables — at that point you are building a CRM without having decided to, and without the budget or team to sustain it.

FAQ

What is the typical upfront cost difference between building and buying?

A genuinely usable custom CRM v1 for a 500-seat organization runs roughly $4.5M to $10.6M over eighteen to thirty months. Salesforce Enterprise has no upfront software cost beyond the annual subscription commitment, but implementation services typically cost $1 to $3 for every $1 of first-year license — for the same reference company, $1.5M to $3.5M one-time over six to fourteen months.

How do ongoing costs compare over five to ten years?

The buy side runs $1.2M to $1.9M annually in subscription plus a shared admin layer that exists in both scenarios. The build side carries a permanent platform team of 4.5 to 7 FTE at $1.05M to $1.49M per year that never goes away, plus $150K to $500K in hosting, plus a likely re-platform around year five to seven. That permanent team line is what decides most honest analyses.

Is the Salesforce license fee just markup we could avoid?

No. The fee is your fractional contribution to shared R&D, security operations, uptime engineering, compliance attestations, and three releases a year — costs amortized across a very large customer base. Build, and you self-fund every one of those with a customer base of one. That is the structural reason the build curve is unbounded.

At what seat count does building actually become cheaper?

Typically north of 10,000 to 15,000 seats, though it is highly profile-dependent. At 20,000 seats even a deeply discounted license runs $24M annually, against $6M to $9M for a twenty-to-thirty-engineer internal product team. Below roughly 5,000 seats, scale alone never justifies a build. Model the crossover explicitly rather than asserting it.

What is buy-and-extend, and when is it the right answer?

Buy the commodity platform of record and build only the thin proprietary layer — a pricing engine, a scoring model, an industry-specific workflow — integrated via API. It is the correct answer for most companies that feel a pull toward building, because it captures moat value on the differentiated slice while the vendor carries the commodity majority.

How do we keep a build from spiraling if we commit to one?

Set a kill-switch milestone in writing before development starts, with a named executive expected to pull it. Fund the platform team as a permanent protected cost that survives downturns. Present estimates as ranges with explicit variance disclosure. Document the migration path to a bought platform before writing the first line of code.

Sources

• https://www.salesforce.com/editions-pricing/sales-cloud/ — official Salesforce Sales Cloud edition pricing, including Enterprise list price
• https://www.gartner.com/en/information-technology — Gartner research on CRM market analysis, implementation cost, and total cost of ownership
• https://www.forrester.com/research/ — Forrester Total Economic Impact methodology and studies on commercial versus custom software
• https://hbr.org/topic/subject/technology-and-analytics — Harvard Business Review coverage of technology investment strategy and hidden costs of custom development
• https://www.pmi.org/learning/library — Project Management Institute library on software cost estimation, risk management, and lifecycle budgeting
• https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights — McKinsey Digital research on large technology program cost overruns and delivery risk
• https://www.fasb.org/ — Financial Accounting Standards Board guidance relevant to internal-use software capitalization
• https://trust.salesforce.com/en/compliance/ — Salesforce compliance and certification documentation (SOC 2, ISO 27001, FedRAMP)
• https://learn.microsoft.com/en-us/dynamics365/ — Microsoft Dynamics 365 documentation, for buy-lane vendor comparison

Related on PULSE

• How do you build a RevOps data dictionary for Salesforce custom fields without a data engineer?
• RevOps tooling consolidation — when does a bigger stack stop paying off?
• Build vs buy: when should we custom-build vs adopt vendor platforms for sales ops infrastructure?
• How do we measure whether our Salesforce config is over-engineered or under-utilized?
• Executive sponsor is blocking procurement because they want a custom feature we can't build in their timeline. How do we move them without feature bloat?
• How should a 2027 deal desk design custom pricing approval flows?