Business Central covers a lot of ground out of the box. Most companies get through implementation without touching a line of AL code. But sooner or later — usually six months to a year after go-live — someone hits a workflow that standard BC simply doesn't support, and the question becomes whether to bend the business process to fit the software, or build something that fits the business.
This is the point where custom extension development becomes relevant. Here's how to think through it.
How to tell you actually need a custom extension
Not every gap needs custom code. Before scoping a development project, it's worth ruling out the cheaper options first:
- Configuration — many "we need a custom feature" requests turn out to be a setup or permission change nobody had made yet.
- An AppSource extension — if your need is common enough, someone has probably already built and published it. A pre-built extension is almost always cheaper and faster than custom development, and it comes with ongoing updates included.
- A workaround process — sometimes a slightly different way of using existing fields solves the problem without any development at all.
Custom development earns its cost when none of the above apply — when your workflow is specific enough to your business (a particular approval chain, an integration with a system nobody else uses, a costing or scheduling model standard BC wasn't built for) that no off-the-shelf answer exists.
What custom extension development actually involves
A properly built AL extension isn't just a script bolted onto Business Central — it's built to survive BC's twice-yearly update cycle without breaking. That distinction matters more than most buyers realize going in. The difference between a quick fix and a maintainable extension usually comes down to:
- Using extension points rather than direct object modification, so Microsoft's updates don't overwrite or conflict with your changes
- Following AppSource technical guidelines even for extensions you never intend to publish, because those guidelines exist to keep extensions upgrade-safe
- Proper testing against BC's sandbox environment before anything touches production
- Documentation, so the extension doesn't become a black box the moment the original developer moves on
Skipping any of these tends to show up later as a broken extension after a BC update, at which point the "cheap" development starts costing more in emergency fixes than a properly built version would have cost upfront.
What it typically costs
Cost depends heavily on scope, but a few rough categories help set expectations:
- Small, self-contained extensions (a custom field, a report tweak, a simple validation rule) — the lightest end of the spectrum, often a matter of days.
- Workflow extensions (custom approval processes, document customization, moderate business logic) — a few weeks of development, depending on complexity and how much testing the workflow requires.
- Integration extensions (connecting BC to a third-party system — a webshop, a specialized costing tool, an external API) — typically the most variable in cost, since a large part of the work depends on the quality and documentation of the system being integrated with, not just the BC side.
- Full custom modules (an entire function area not covered by standard BC or any AppSource extension) — effectively a small product build, priced accordingly.
Location matters too. Development cost varies significantly between markets — teams based outside the highest-cost regions can often deliver the same AL quality and AppSource compliance at meaningfully lower rates, without cutting corners on the extension-point and upgrade-safety practices above. The trap to avoid isn't a lower price — it's a lower price paired with shortcuts on maintainability, since that's the part of the cost that shows up later rather than in the initial quote.
A sensible process for scoping a custom extension
- Discovery — a clear, specific description of the workflow gap, not just "we need X to work differently." The more specific this is, the more accurate the estimate.
- Feasibility and options — confirming whether custom development is actually the right call versus an AppSource extension or configuration change.
- Scoped estimate — a fixed or bounded estimate based on the actual requirement, not a vague day-rate guess.
- Build and test — development against a sandbox, with testing against your actual data patterns, not just a demo dataset.
- Deployment and handover — including documentation, so the extension doesn't depend on one developer's memory to maintain.
FAQ
Can a custom extension break during Business Central's update cycles? It can, if it wasn't built using proper extension points and AppSource-aligned practices. A well-built extension is designed to survive BC's twice-yearly updates without manual intervention; a poorly built one often needs a fix after every major release.
Is it cheaper to buy an AppSource extension or build a custom one? Almost always cheaper to buy, if a suitable one exists — you're sharing the development and maintenance cost across every customer of that extension. Custom development makes sense specifically when nothing off-the-shelf fits.
How long does custom AL extension development take? Anywhere from a few days for a small, self-contained change to several months for a full custom module — the estimate should come after a scoping/discovery step, not before it.
Do you need to modify our current Business Central setup to add a custom extension? No — a properly built extension is additive. It shouldn't require modifying your existing base configuration, which is exactly why extension-based development (as opposed to direct object modification) matters.
DYNASYS builds custom AL extensions for Business Central following Microsoft's AppSource guidelines, so what we build stays maintainable through every update cycle. If you have a workflow gap standard BC or AppSource can't cover, get in touch — we'll tell you honestly whether custom development is actually the right call before we quote anything.