Build vs buy in the Dynamics 365 ecosystem

For every gap between out-of-the-box Dynamics 365 and what the business needs, the decision is the same: build (customise via AL, X++, Power Platform, or plug-ins) or buy (install an AppSource ISV solution). The decision compounds — across hundreds of small choices, the cumulative direction shapes the implementation's complexity, cost, and longevity.

The default direction in modern Dynamics 365 implementations

Microsoft's Success by Design methodology explicitly emphasises fit to standard as the first option, and customisation only when standard truly doesn't fit. Many veteran consultants apply a more general principle: prefer configuration over customisation, prefer bought over built, prefer Power Platform extensions over core code changes. The reason isn't ideology — it's that customisation cost compounds across upgrades and team turnover, while configuration and bought solutions usually don't.

The build case.

Build (customise / extend) when:

• The requirement is genuinely unique — no commercial solution exists that addresses the specific business need.
• The requirement is strategic — the differentiation is the business value; sharing functionality with competitors via a common ISV defeats the purpose.
• Cost-benefit clearly favours custom — the AppSource alternative is more expensive over the lifetime than building and maintaining custom code.
• Standard plus light customisation suffices — small AL extension adding a few fields and a custom report is cheaper than a heavyweight ISV.
• You have the skills and capacity — pro-developer team in place; ALM discipline; willingness to maintain.

The buy case.

Buy (install an ISV solution) when:

• The requirement is common — many companies need it, an ISV has commodified it (country localisations, AP automation, EDI, banking integrations).
• The complexity exceeds in-house capacity — building it would consume significant team time that isn't available.
• The vendor maintains it — release-wave compatibility, regulatory updates, ongoing support are someone else's job.
• Total cost of ownership favours buying — per-user license fees over the system's life are less than the build cost plus ongoing maintenance.
• Time-to-value matters — bought solutions deploy in weeks; built solutions take months.

The decision framework.

For each gap:

1. Is there a commercial ISV solution? Search AppSource. List candidates.
2. What's the gap between the ISV's coverage and your needs? Often 80–95%. The remaining gap may be fillable with light customisation on top of the ISV.
3. What's the build cost? Realistic estimate: design, development, testing, ALM setup, ongoing maintenance for the system's life.
4. What's the buy cost? Per-user-per-month licences across affected users, multi-year horizon. Plus implementation cost (the ISV may charge for setup).
5. What's the risk of building? Will it break at the next release wave? Are there compliance or regulatory dimensions only the vendor can keep current?
6. What's the risk of buying? Vendor lock-in? Vendor going out of business? Vendor not keeping pace with platform changes?

The honest answer to these often points clearly one way.

The hybrid pattern

Most mature implementations are both — many ISV solutions in the stack + custom extensions for the genuinely unique work. The mix:

• ISV for country localisations, EDI, AP automation, e-commerce connectors, banking, document capture, complex pricing engines.
• Custom AL / X++ / Power Platform for the company-specific business logic, integrations to internal systems, bespoke UI tweaks.

Common patterns.

• Country expansion — when entering a new country, buy the country localisation. Don't build it.
• AP automation — buy. The category is mature; building it from scratch produces inferior outcomes.
• EDI — buy. Same reason.
• Industry vertical solution — buy if a credible one exists; the depth ISVs have can't be replicated quickly.
• Strategic customer-facing differentiation — build. This is your business.
• Internal workflow tweaks — build with Power Platform; small, contained, low-risk.

Anti-patterns.

• Building what you should buy because in-house feels cheaper. Doesn't account for maintenance cost over years.
• Buying what you should build because outsourcing feels safer. ISV solutions that don't fit produce frustration; you customise the ISV's customisation, and now you have two maintenance problems.
• Buying multiple overlapping ISVs. One ISV for document capture, another for OCR, a third for approval workflow. Overlaps confuse users and complicate maintenance.
• Custom code that should have been Power Platform. Old AL/X++ patterns for things Power Automate flows could do trivially.

Operational reality

The build-vs-buy decision is iterative — revisit it as the platform evolves. What had to be built five years ago may now be available as an ISV. What was bought from a vendor that's now dying may need to come back in-house. Stay engaged with the ecosystem. Whatever gets decided, write down why — architecture decision records capture exactly this kind of choice so the next person to revisit it isn't reverse-engineering the original reasoning.