- Contact us: office@woods.consulting
- Contact us: office@woods.consulting
- Customer Support
CRM decision guide
Build or buy your CRM?
Build it yourself and you get a system shaped exactly around how you work. Buy one and you inherit a decade of someone else’s engineering. Which way works out cheaper comes down to your own numbers, so there is a calculator below to run them. We implement Microsoft Dynamics 365 for a living, and we’ll still tell you when building is the better call.
Total cost of ownership
Build vs. buy, over the life of the system
Most build-vs-buy arguments put a build quote next to a licence price and stop there. That leaves out maintenance, the years after go-live, and the months your team spends waiting. Every number below is yours to change.
Your CRM
If you build
If you buy
Over 5 years, buying costs less.
Building does not break even inside the horizon.
| Cost | Build | Buy |
|---|---|---|
| Getting to go-live | — | — |
| Running it, per year | — | — |
| Licences, per year | — | — |
| Months until people can use it | — | — |
| Total over 5 years | — | — |
Every figure above is yours to change, and the defaults are illustrative starting points rather than quoted prices. Licence prices depend on the product and the agreement; current Microsoft list pricing is published on the Dynamics 365 Sales pricing page. The model leaves out the commercial upside of a system that wins you work, because that number is yours, not ours. Treat it as an estimate to think with rather than a quote.
The part that surprises people
What a build quote leaves out
Custom CRM projects rarely fail at the first release. They fail in year three, when the people who wrote it have moved on and the backlog is nothing but maintenance. Here is what sits outside the quote.
01
The software never stops
Browsers change, dependencies get security advisories, tax rules move, an integration partner rewrites its API. Somebody has to be on call for that in year four, whether or not you’re adding features.
02
The boring 80 percent
Permissions, audit trails, duplicate detection, bulk import, an offline mobile experience, GDPR deletion, exports for the auditor. None of it wins you a deal, all of it has to exist, and it’s most of the work.
03
Key-person risk
Two developers hold the model in their heads. When one leaves, the recruitment fee is the cheap part. The expensive part is the six months where nobody wants to touch the pricing logic.
04
You are now a software company
Roadmap, releases, environments, support rota, documentation. That’s a permanent job, and it competes for attention with the business you actually run.
05
The features you did not budget for
AI assistance, forecasting, sales sequences, a decent mobile app. On a bought platform these arrive in a release note. On a built one they arrive as a project each.
06
Waiting is a cost
Nine months of building is nine months of the pipeline staying in spreadsheets. It never lands in the budget, and it’s often the biggest number on the page.
The honest answer
When building really is the right call
We implement Dynamics 365, so take this section with the appropriate pinch of salt. We have also talked clients out of buying, more than once. Building wins when at least two of these are true.
Build
- The process is the product. If how you quote, match or schedule is the reason customers choose you, encoding it in someone else’s product can flatten your advantage.
- Nothing on the market fits. Not “fits awkwardly”. It does not model how you work, and you have run the trials to prove it.
- You already run engineering. A team, a release process and an on-call rota exist today and will still exist in five years.
- Scale makes licences hurt. At several hundred seats, per-user pricing becomes the dominant line and the maths shifts.
- The system is the business. Software you sell or operate as your core offering belongs to you, not to a vendor.
Buy
- Your process is normal. Leads, opportunities, quotes, work orders, projects, invoices. Solved problems, solved well.
- You need it this quarter. Weeks to a working system instead of quarters to a first release.
- The team is small or mixed. No standing engineering function to inherit the thing after launch.
- Compliance matters. Certifications, data residency and audit trails you would otherwise build and then prove.
- You want the roadmap. AI, mobile and analytics keep arriving without a project each time.
What we usually recommend
Most companies should do both, in the right order
Build versus buy is rarely an either/or. The better question is which parts of your process are ordinary and which are yours alone. Buy the first, build the second on top of it.
Buy the foundation
Contacts, accounts, pipeline, activities, security, mobile, reporting, compliance. Dynamics 365 and Dataverse ship this on day one and keep it patched. Recreating it is expensive and wins you nothing.
Build the difference
Your pricing logic, your scheduling rules, the calculation the industry does not have. Built as Power Platform apps, plugins and flows on the same data, so it belongs to you without being a separate system.
Keep one source of truth
Everything sits on Dataverse: one security model, one audit trail, one place the data lives. Your website, your portal and your reporting read from it rather than copying it.
We have built exactly this: an external scheduling engine when the standard one could not carry the load, and WBS Connect for Dataverse to publish Dataverse records on a public website without a portal licence. Bought platform, built difference.
Inside the Microsoft stack
Build and buy are the two ends of one dial
If you are already on Microsoft 365, there is more than one position to choose from. Dynamics 365, the Power Platform and Azure give you four of them on a single shared data layer, so you can sit anywhere along the dial and move later without starting again.
01
Buy
Dynamics 365 apps
Sales, Customer Service, Field Service, Project Operations. Ready-made applications with a decade of edge cases already handled.
02
Configure
Tables, forms, rules
Custom tables and columns, business rules, process flows and role-based security – all without code. Most “we need something custom” requirements land here.
03
Extend
Power Platform
Power Apps, Power Automate and Copilot Studio building bespoke behaviour on the same data, with the platform still handling identity, security and hosting.
04
Build
Pro-code on Azure
Plugins, custom APIs and Azure Functions for the logic that is yours alone: a pricing engine, a scheduling algorithm, sitting on the same records.
The reason the dial works is the data layer underneath it. Microsoft’s own documentation puts it plainly: data from Dynamics 365 applications “is also stored within Dataverse, allowing you to quickly build apps that use your Dynamics 365 data and extend your apps with Power Apps.” One set of records and one security model — business units, role-based, row-based and column-based — whether a screen was bought, configured or written from scratch. What is Microsoft Dataverse?
A note on AI-assisted development. Copilot and AI coding tools have changed the first half of this equation, and it is worth saying so plainly: a working prototype is far cheaper and faster to produce than it was two years ago. What they have not changed is the cost of permissions, audit trails, data migration, integration, release management or being on call in year four, and those were always the expensive parts. A prototype is not a system, and the gap between the two is where custom CRM projects have always come unstuck.
The part nobody budgets for
Whatever you build, someone has to run it
This is the part that gets skipped in most build-versus-buy debates. Choosing to build does not free you from process, it commits you to one. Microsoft publishes a lot of guidance on this, because low-code makes things easy to create and no easier to operate.
Environment strategy
Separate development, test and production, with a plan for who can create what and where. Microsoft calls a tenant environment strategy “essential to make it manageable and secure as the number of environments grows”.
Application lifecycle management
Microsoft’s definition is broad on purpose: ALM “is the lifecycle management of applications, which includes governance development and maintenance”. Solutions are the mechanism, and source control “should be your source of truth”.
Deployment you can repeat
Pipelines, Azure DevOps or GitHub Actions, so a change moves from a developer’s environment to production the same way every time, and can be rolled back when it should not have.
Security and data protection
Role-based, row-level and column-level access designed against your org chart, plus data loss prevention policies that decide which connectors may touch business data.
An architecture that survives contact
Microsoft’s Well-Architected framework sets out five pillars — reliability, security, operational excellence, performance efficiency and experience optimization — with a review checklist against each.
Someone who owns it on Monday
Monitoring, a support route, a named owner and a documented handover. This is the difference between a system your team trusts and one they quietly work around within a year.
Which is where we come in
Whichever end of the dial you land on, the work looks similar: design the process before configuring anything, set up environments and ALM so changes are safe, model security properly, and stay on hand once it’s live. That is what Woods Business Solutions does, as a Microsoft partner that implements Dynamics 365 and the Power Platform and builds on it where the standard product runs out. We will tell you which parts of your requirement are ordinary, which are worth custom work, and roughly what each of them costs.
Side by side
The trade-offs, without the sales pitch
| Build it yourself | Buy a platform | Buy and extend | |
|---|---|---|---|
| Time to a usable system | Quarters | Weeks | Weeks, then continuous |
| Fit to your process | Exact | Good, with configuration | Exact where it matters |
| Cost shape | Large upfront, permanent upkeep | Moderate upfront, per-user | Moderate upfront, per-user plus project work |
| Who fixes it at 2am | You | The vendor | The vendor, plus your partner |
| New capability arrives | As a project | In a release | In a release, plus what you add |
| Compliance and certification | Your problem to build and prove | Inherited | Inherited |
| If the team leaves | Serious risk | Low risk | Low risk |
| Ceiling on differentiation | None | Real | None where you invest |
Scroll the table sideways to compare all three options.
Frequently asked questions
The questions we hear most often before a build-or-buy decision gets made.
Is it always cheaper to buy a CRM?
No. Buying wins clearly for small and mid-sized teams with ordinary sales, service or project processes, because the build cost is dominated by work that has nothing to do with your business. The maths shifts at scale: once per-user licences are the largest line, a custom system can break even, which is why the calculator lets you push the user count up and see it happen.
What does a Dynamics 365 implementation actually cost?
It depends on scope: number of users, how many processes, data migration, integrations. We price implementations as fixed-scope projects after a scoping workshop, so you get a written figure rather than an hourly estimate, plus Microsoft licences per user per month.
We already started building. Is that money wasted?
Usually not. The domain modelling, the process decisions and the integrations you have designed carry over, and often the honest move is a hybrid: keep the part that is yours alone, move the commodity part onto a platform. We have taken over half-finished builds and done exactly that.
Does buying lock us in?
Partly, and it’s worth being clear-eyed about that. What reduces the risk with Dynamics 365 is that the data sits in Dataverse with a documented API and standard export, so your records stay reachable, and extensions you build on the Power Platform are yours. Lock-in is real; being unable to get your data out should not be.
Can we build on top of Dynamics 365 rather than beside it?
Yes, and that is usually the recommendation. Custom tables, plugins, Power Apps and Azure services extend the platform on the same data and security model, so you get bespoke behaviour without running a second system.
How accurate is this calculator?
It is a model, so it is only as good as the numbers you put into it. It captures the costs people forget, like upkeep, the years after go-live and waiting time, and it leaves out the commercial value of a system that helps you win work, because we cannot know that number.
Bring us the number you do not believe. Book a free 30-minute call and we’ll tell you whether Dynamics 365 fits, where you’d still need custom work, and roughly what each path costs. If building is the better answer for you, we’ll say so.
Prefer to read first? See Dynamics 365 Sales consulting, Field Service and Project Operations, or the ecobility case study.
I'm here to help!
I would be pleased to answer any queries you have.
Zachary Woods
- +1 (941) 350 6707
- sales@woods.consulting
Find out how we can help you decide – and then deliver – with
Microsoft Dynamics 365 and the Power Platform.