{"id":5802,"date":"2026-07-21T13:02:24","date_gmt":"2026-07-21T13:02:24","guid":{"rendered":"https:\/\/dgp.group\/einblicke\/success-story-produktkonfigurator\/"},"modified":"2026-08-13T13:08:54","modified_gmt":"2026-08-13T13:08:54","slug":"success-story-produktkonfigurator","status":"publish","type":"page","link":"https:\/\/dgp.group\/en\/einblicke\/success-story-produktkonfigurator\/","title":{"rendered":"Success story: product configurator in Business Central"},"content":{"rendered":"
\n
\"Team<\/figure>\n\n
\n

Success Story<\/p>\n

A special solution that does not exist as a standard. Made usable in Business Central.<\/h1>\n

Some requirements fit no standard system. This was one of them: a product configurator with logic that no off-the-shelf tool covers. How it ended up inside Business Central anyway, built AI-assisted and senior-led, is the story here. Without miracle numbers.<\/p>\n

Discuss your use case<\/a><\/div><\/div>\n<\/div>\n\n<\/section>\n\n\n\n
\n\n
\n\n
\n

The case<\/p>\n

The case in brief<\/h2>\n<\/div>\n\n\n
\n\n
\n

Industry<\/p>\n

Industry and manufacturing<\/p>\n<\/div>\n\n\n

\n

Starting position<\/p>\n

Special solution outside the standard<\/p>\n<\/div>\n\n\n

\n

Approach<\/p>\n

A standalone app connected to Business Central, senior-led<\/p>\n<\/div>\n\n\n

\n

Result<\/p>\n

A working prototype, an extensible base<\/p>\n<\/div>\n\n<\/div>\n\n<\/div>\n\n<\/section>\n\n\n\n

\n\n
\n\n
\n

01<\/p>\n\n

\n

The starting position<\/p>\n

A requirement that fits no standard.<\/h2>\n

An industrial company configures its products by a logic that goes far beyond what standard software covers: variants, rules and dependencies that interlock. There is no off-the-shelf tool for it. In Business Central, too, this logic cannot be handled by the standard. That is not a weakness of the system, it is the honest diagnosis: the standard is built for what many need. This requirement was needed by only one.<\/p>\n

The existing solution had grown over years and was technically no longer fit for the future. Every change turned into archaeology: first understand what was built back then and why, then adjust carefully. That carries for a while. But it gets more expensive every year, and at some point the question we know from many projects is on the table: keep patching or rethink?<\/p>\n

The convenient path would have been to force the special logic into the ERP somehow. We know the result of such decisions: a bent standard that trembles with every update. That is exactly what we did not want.<\/p>\n<\/div>\n\n<\/div>\n\n<\/div>\n\n<\/section>\n\n\n\n

\n\n
\n\n
\n

02<\/p>\n\n

\n

The decision<\/p>\n

Do not bend the standard, but build cleanly alongside it.<\/h2>\n

Instead of bending Business Central, we rebuilt the configurator as a standalone application and connected it cleanly to the system. The division of labour is clear: the data foundation stays in Business Central and keeps its single, owned source of truth there. The special logic lives alongside it, in an application built exactly for it.<\/p>\n

This separation is more than architectural hygiene. It keeps Business Central update-ready: the two release waves a year keep running automatically, because no bent standard is in the way. And it keeps the bespoke solution agile, because it can evolve without touching the ERP.<\/p>\n

Senior-led means concretely: an experienced developer makes the functional and the architectural decisions, reviews every state and approves what gets merged. One person who carries responsibility. Not a team that wears itself out on the complexity and spreads the responsibility until no one holds it any more.<\/p>\n<\/div>\n\n<\/div>\n\n<\/div>\n\n<\/section>\n\n\n\n

\n\n
\n\n
\n

03<\/p>\n\n

\n

The delivery with AI<\/p>\n

Test-driven, with the human at the wheel.<\/h2>\n

Development ran test-driven, and the order is the point: first the developer writes the tests, himself, by hand. Only then does the AI develop against those tests. Why this order? Because an AI that writes its own acceptance criteria can talk its own success into being. Against someone else's tests it cannot. Either the logic passes, or it does not.<\/p>\n

What passes the tests is still not merged blindly. The developer reads, reviews and merges every state. The AI speeds up the routine work, the scaffolding, the repetition. The critical and error-prone parts stay in his hands.<\/p>\n

And so this does not turn into a glossy story: a substantial part of the work went into bug fixing. AI-assisted development does not run itself, it shifts the work from typing to reviewing. Anyone who tells you AI builds something like this on the side has not been on a project like this.<\/p>\n<\/div>\n\n<\/div>\n\n<\/div>\n\n<\/section>\n\n\n\n

\n\n
\n\n
\n

04<\/p>\n\n

\n

Where it stands today<\/p>\n

A working prototype and a base that holds.<\/h2>\n

The prototype runs, and it runs across the whole core process: pull items from Business Central, process them, create new ones, generate bills of materials and routings. Passed cleanly into Business Central through a code unit, not glued on.<\/p>\n

More important than the prototype itself is what it makes possible: requirements that failed at the limits of the old system can now be delivered. A legacy burden that punished every change has become a foundation that further requirements build on.<\/p>\n

And because honesty is the currency here: it is a prototype, not a finished product. Extensions and the interface to a further system are still to come. That is exactly how we put it to the client, too.<\/p>\n<\/div>\n\n<\/div>\n\n<\/div>\n\n<\/section>\n\n\n\n

\n\n
\n\n
\n

No miracle numbers<\/p>\n

Why there are no time and cost figures here.<\/h2>\n<\/div>\n\n

Stories like this usually end with a number: done in X days, costs cut to a tenth. We leave that out, for a simple reason: we cannot back it up credibly. A prototype is not a project completion, and honest interim states are worth more to us than round numbers. What we can back up is above: a bespoke solution that no standard offers, usable in Business Central, built with a method that combines AI pace and senior control. That is the story. It is enough.<\/p>\n<\/div>\n\n<\/section>\n\n\n\n

\n\n
\n

“<\/p>\n

AI accelerates the routine. Responsibility for the result stays with the experienced human.<\/p><\/blockquote>\n

Frank Maier, founder of DGP<\/p>\n<\/div>\n\n<\/section>\n\n\n\n

\n\n
\n\n
\n\n
\n

What transfers to your situation<\/p>\n

AI, senior-led. Not AI as a miracle cure.<\/h2>\n

Three things from this project hold everywhere. First: the data foundation belongs in the ERP, with an owned source of truth, otherwise even the best bespoke solution has nothing to work on. Second: AI development needs a human who owns the acceptance criteria. Third: special logic belongs next to the standard, not inside it. Whoever has these three things can afford requirements that used to count as unaffordable.<\/p>\n<\/div>\n\n\n

\n\n
\n

What we do not do<\/h3>\n