Customization & AL
Extensions built around your process rather than against it, written as proper AL so Microsoft's updates stay routine instead of becoming a project.
Contact Us
When customization is the right answer
Not every gap needs code. A surprising share of the requirements we are handed turn out to be configuration, a Power Automate flow, or a report that already exists under a different name. We check those first, because every line of AL you own is a line you maintain and re-test twice a year. Where code genuinely is the answer, it is usually because your process is the thing that makes you competitive: a pricing rule nobody else uses, an approval chain specific to your industry, a document flow your customers expect. That is worth building. Generic functionality that Microsoft will ship in eighteen months is not.
How we build
Everything is an AL extension. Extensions sit alongside the base application rather than modifying it, which is what makes the October and April releases uneventful. We use events and interfaces instead of copying base objects, so upgrades do not turn into merge conflicts. Work is version-controlled in Git, built through a pipeline, and deployed to a sandbox before it reaches production. You get the source code. That is not a concession, it is the point: you should never be in a position where changing vendor means rewriting your system.
Built to be handed over
Custom code that only its author understands is a liability disguised as an asset. We write to the conventions Microsoft publishes, name things the way the base application names them, and document the why rather than the what. Where a customization is substantial we add automated tests for it, so the next person to touch it finds out immediately if they broke something. Companies that skip this discover their regressions in production, usually during month-end.
What you get
Process analysis first
We check whether configuration or a flow solves it before quoting development, and tell you when it does.
Proper AL extensions
Events and interfaces, never modified base objects, so Microsoft's twice-yearly releases stay uneventful.
You own the source
Code lives in your Git repository. Changing partner should never mean rewriting your system.
Automated tests where it matters
Substantial customizations ship with tests, so a future change surfaces breakage immediately rather than at month-end.
Sandbox before production
Built through a pipeline and deployed to a sandbox first. Nothing reaches your live company untested.
Documented for the next person
Written to Microsoft's conventions and documented for why, not what, so any AL developer can pick it up.
Technologies
Frequently asked questions
Will our customizations break when Microsoft updates Business Central?
Properly written extensions rarely break, because they attach to published events rather than modifying base code. We also test against Microsoft's preview builds ahead of each major release, so if something does need attention we know before you do.
Who owns the code you write for us?
You do. It lives in your repository and you can hand it to any AL developer. We think a partner should keep your business because the work is good, not because leaving is expensive.
Could our customization become an AppSource app?
Sometimes, and it is worth asking. If what you need is genuinely useful to other companies, publishing it changes the economics. We build and publish AppSource apps ourselves and can tell you whether yours is a candidate.
Tell us what Business Central will not do, and we will tell you what it takes
Contact UsGet Free Estimation
Have a question or want to discuss a project? We'd love to hear from you. Get in touch and we'll respond as soon as possible.
Contact Information
Fill out the form and our team will get back to you within 24 hours.
Location
Serbia