Hiring a Business Central developer is a decision most organizations only make a few times — and the cost of getting it wrong tends to show up slowly, in unmaintainable extensions, failed upgrades, and integrations that quietly break under load. Having worked as a BC developer across clients in multiple European markets, I've seen what separates implementations that hold up over time from the ones that create ongoing technical debt. Here's what actually matters.
AL Fluency, Not Just NAV History
Business Central's extension model is fundamentally different from classic NAV development, and a developer whose experience is primarily in C/AL may not have made that conceptual shift. AL extensions require working within Microsoft's event architecture, managing dependencies between extensions, and writing code that survives BC's monthly update cadence. Ask specifically about AL extension work — not just "BC experience" — and ask what version they were working against.
AppSource Experience as a Quality Signal
Publishing an extension on Microsoft AppSource requires passing a technical validation process that covers security, upgrade safety, multi-tenancy, and compliance with the extension model. Developers who have been through that process have had their code reviewed against a real standard. It's one of the more reliable proxies for AL quality available, because it's externally verified rather than self-reported.
Full Lifecycle Experience
There's a meaningful difference between a developer who has written AL code and one who has owned an implementation end to end — from requirements and scoping through data migration, go-live, and post-launch support. Upgrades, in particular, reveal things about a developer's earlier work that weren't visible at go-live. Developers who have led full lifecycle projects, including upgrades of their own earlier implementations, have a different relationship with long-term consequences than those who hand off at deployment.
Cross-Industry Exposure
Business Central is used across manufacturing, distribution, professional services, retail, and nonprofit sectors — and the business logic varies significantly between them. A developer with experience across multiple industries has encountered a wider range of edge cases and is less likely to design solutions that break when the client's processes don't match the developer's mental model of "how companies work."
Integration Depth
Most BC implementations involve at least one external integration — eCommerce, a payment gateway, a logistics platform, a data warehouse. Evaluate whether the developer has experience with BC's native API layer, Azure service integrations, and file-based exchange patterns. Ask about error handling and logging specifically: integration reliability is mostly an operational engineering problem, not a data mapping problem, and developers who understand that write more resilient systems.
Localization and Multi-Country Experience
If your organization operates across multiple countries or plans to, localization requirements — VAT handling, country-specific reporting, regulatory compliance — add significant complexity to any BC implementation. Developers who have worked on multi-country rollouts, coordinating across different legal and fiscal environments, understand that complexity in a way that purely domestic experience doesn't provide.
Certifications as a Baseline, Not a Ceiling
Microsoft's BC certifications demonstrate baseline platform knowledge and professional investment, but they're a floor, not a ceiling. They're worth checking — uncertified developers haven't committed the time to validate their fundamentals — but certification alone shouldn't drive a hiring decision. Look for certification plus demonstrated project history.
If you're building out your BC capability and want to talk through what your project actually requires, I'm happy to have that conversation. You can also review my experience and past work to judge for yourself.