DEVELOPMENT THAT UNDERSTANDS THE PLATFORM.
BUILD. EXTEND. INTEGRATE.
Technical development for Microsoft Dynamics NAV and Business Central.
From legacy C/AL through modern AL extensions, integrations, upgrades and new functionality.
CAPABILITYTECHNICAL DEPTH.
Development starts with understanding how NAV and Business Central actually work. The objective is not simply to make code run, but to produce solutions that remain understandable, supportable and upgradeable.
Legacy C/AL remains critical in many NAV environments. The work starts by understanding existing objects, modifications, dependencies and business logic before changing or replacing them.
Modern Business Central development uses AL and extensions to separate custom functionality from the standard application and improve upgradeability.
APIs, web services, data mapping and migration routines need clear ownership, validation and reconciliation so information moves reliably between systems.
Performance and upgrade development require tracing the execution and processing logic, identifying the affected area and addressing the real root cause rather than treating symptoms.
AL DEVELOPMENTMODERN BUSINESS CENTRAL.
Use appropriate fields, keys, relations and data structures while respecting the Business Central data model and the long-term effect of the extension.
Build user-facing functionality through pages, page extensions and actions without unnecessarily duplicating standard application behaviour.
Codeunits provide controlled locations for processing, interfaces, events and reusable business logic with clear responsibilities.
Choose reports, datasets and queries according to the requirement, keeping data retrieval, layout and performance considerations clear.
Interfaces create explicit contracts between application components and can reduce unnecessary coupling when multiple implementations are required.
Publishers and subscribers can extend standard behaviour cleanly when the event model provides the correct extension point and dependency boundary.
CUSTOMISATIONEXTEND WITHOUT BREAKING THE PLATFORM.
Custom functionality should solve the business requirement without creating unnecessary technical debt.
Understand the standard application first. Custom code should exist because the requirement genuinely needs it, not because standard functionality was overlooked.
Use controlled extension architecture so custom behaviour is separated from the base application and remains easier to deploy, test and upgrade.
Use events and subscribers where they provide a clean extension point instead of modifying or duplicating standard processing.
Maintainability is part of the solution: clear structure, naming, responsibilities and dependencies reduce the cost and risk of every future change.
INTEGRATIONCONNECT THE SYSTEMS.
Business Central rarely exists in isolation. Reliable integration requires clear ownership, validation and failure handling.
Prefer supported Business Central APIs where they fit the requirement; use custom APIs when the business contract needs functionality the standard endpoints do not provide.
OData and web services remain relevant in existing solutions, but the integration method should match the Business Central version, workload and long-term architecture.
Define the contract explicitly: field mapping, transformations, validation rules, ownership and what happens when incoming data is incomplete or invalid.
Reliable integrations need predictable error handling, traceability, retry or recovery behaviour and reconciliation so failures do not silently corrupt business processes.
QUALITYCODE THAT CAN BE TRUSTED.
Keep object structure and responsibilities explicit so processing logic is understandable and dependencies remain controlled.
Database access, filtering, loops, transactions and locking behaviour should be considered as part of development, not after performance becomes a production problem.
Processes and integrations should fail in controlled, understandable ways that preserve data integrity and provide enough information to diagnose the problem.
Test the behaviour that matters: business rules, integrations, edge cases, upgrades and the areas most likely to create operational risk.
Review should focus on correctness, maintainability, platform compatibility and whether the solution solves the requirement without unnecessary complexity.
Source control, builds, deployment and release processes should make delivery repeatable and reduce avoidable production risk.
MAINTAINABILITYBUILD FOR WHAT COMES NEXT.
A solution is not finished when it works. It is finished when the next change can be made without fear. Good development reduces the cost of future development.
Separate responsibilities and keep dependencies deliberate so one change does not create unpredictable effects elsewhere in the application.
Source control and documented technical decisions provide history, accountability and context for future development.
Upgradeability should influence extension points, dependencies and customisation choices from the beginning rather than becoming a later migration problem.
Testable code makes future change safer and helps distinguish application defects from data, configuration and integration problems.
Development should remain conscious of data volumes, SQL behaviour, filtering, locking and processing patterns as the environment grows.
Technical debt cannot always be avoided, but it should be visible, deliberate and controlled rather than accumulating through shortcuts nobody documents.