Custom Business Central Development — AL Extensions Built to AppSource Standard
When the workflow is genuinely yours and the configuration toolkit can't reach it, you need a custom AL extension. We build them to the same standards Microsoft applies to AppSource-published apps — even when you're the only customer who'll ever run it. That's deliberate: it gives you a clean upgrade path through every BC version, public-quality docs, and no vendor lock-in.
What we build
- BC extensions in AL. The Microsoft-supported customisation language. We write idiomatic AL, not the kind of bespoke C/AL-era patterns that don't survive a BC version upgrade.
- Connectors to external systems. WMS, POS, CRM, payroll, niche industry tools. Usually Power Automate or AL-based REST integrations.
- Custom reports and Power BI datasets. When the standard report set doesn't cover what your finance or ops team needs.
- Migration tooling. One-off AL extensions to move data cleanly from legacy systems into BC.
How we engage
Fixed-scope engagements quoted per AL extension or per integration. Discovery workshop → design doc you sign off → build → test in your sandbox → deploy. Source code is yours; documentation lives publicly at docs.ampliosolutions.co.uk unless you specifically ask for it not to.
What you avoid by working this way
- Code that breaks at the next BC upgrade because it bypassed AL events.
- Documentation that's locked behind a partner portal and lost when you change supplier.
- Per-instance customisations the original developer can't remember in 18 months.
- The "we'll need to charge to make that small change" loop that comes from black-box code.
If your problem is shared
If the same workflow problem hits multiple clients, we'll usually offer to publish the extension on AppSource rather than build it bespoke — same code, lower cost, ongoing maintenance handled by us.
Frequently asked questions
What counts as "custom" vs "an app on AppSource"?
If the workflow is unique to your business, it’s custom development. If the same workflow problem hits multiple BC customers, we usually publish it on AppSource — same code, lower cost, ongoing maintenance handled by us. We tell you which side of the line your problem falls on during scoping.
How long does a custom AL extension take to build?
Most extensions land in 4–10 weeks depending on object count and integration depth. We work to AppSource code standards even on bespoke builds, so the extension upgrades cleanly across BC versions.
Do you charge time and materials, or fixed scope?
Fixed scope, fixed go-live date. Change requests are priced separately and signed before they start.
Will the extension survive BC version upgrades?
Yes — we build to AppSource standards and run automated upgrade tests against each BC release. If Microsoft deprecates an API we’ve used, we patch and re-release before your tenant gets the upgrade.
Do we own the code?
You own the licence to use the extension on your tenants in perpetuity, including post-engagement. We retain rights to reuse the codebase as the basis for future builds for other clients. Source escrow is available on request.
Can we trial the extension before committing?
Yes — UAT runs on your real sandbox tenant against your real data for two weeks before go-live. If it doesn’t pass UAT, we don’t take final payment.