Most consultants get customisation wrong in both directions
One camp avoids custom code on principle and bends the business around the standard, which produces a system everyone works against and a shadow layer of spreadsheets doing the real work.
The other camp builds whatever is asked, which produces a system nobody can upgrade and a maintenance bill that outlives the person who approved it.
Both are the same failure: a rule applied instead of a decision taken. We know when to build a thousand objects and when to build zero, and the interesting projects need both answers in different places.
Clarity Before Code is not a preference for less code
It means code written on purpose and correctly sized. Sometimes that is nothing at all, because the standard already does it and the request was really a training problem. Sometimes it is a very large application, because the operating rules genuinely have no standard equivalent.
We have built one of the largest Business Central custom applications in existence, past a thousand AL objects, and it absorbs every monthly update with zero impact. That is not a contradiction of the principle. It is the principle: the code exists because the rule it carries is real, and it is built so the platform can move underneath it.
The measure is never how little you wrote. It is whether what you wrote is still true, and still upgrading cleanly, three years later.
Careless customisation, and how to recognise it before it ships
Cosmetic changes that exist because nobody wanted to have a conversation about the process. Fields added to hold data no one will ever act on. Logic that hides the absence of a decision, so the decision never has to be made.
Technically these look fine on the day they ship. They fail on the second axis: nobody can name the business rule behind them, so nobody can ever safely remove them, and they accumulate until an upgrade becomes a project.
We are not anti-customisation. We are against the careless kind, and we will push back on it during design rather than bill you to maintain it for a decade.
A rule you can still name holds years later, when something tests it. On our own Business Central, the rule forbidding the client report from guessing a line was set long before the month more than half the document came back with no domain. That is where you find out whether a customisation was thought through or merely delivered.
Building for a platform that updates on somebody else’s calendar
Business Central online ships two major waves a year plus monthly service updates, and it does not ask. Any code that depends on internals Microsoft is free to change has a shelf life, whether or not it works today.
That means events rather than modifications, no reliance on undocumented behaviour, extensions that declare their dependencies honestly, and a test suite that tells you an update broke something before your users find out.
This is what makes the difference between an application that grows and an application that becomes a hostage. The cost of getting it right is paid once, during design. The cost of getting it wrong is paid every month, forever.
A test suite is not a quality badge, it is a measuring instrument, and the reading is never what you expect. On one integration of ours, the first test to actually execute in CI showed that a single refused posting could shut the whole session down.
What working with us on a build looks like
We start by challenging the request, because the request is rarely the requirement. If the need is not clear, the solution is necessarily wrong, however well it is engineered.
Then we scope what is genuinely custom, what is standard, and what should not exist. You get that in writing, with the reasoning, so the decision is yours and not an implicit consequence of a technical choice.
We are good, but we are not telepathic. Be clear about the business rule and we will build it properly, once.
