Why a user-centric B2B application is far more than just its frontend

What AI-assisted development really changes — and which layers remain untouched

Since AI-assisted development and "vibe coding" began accelerating software engineering, a natural assumption has emerged in decision-making circles: if a model can generate the UI of a sales intelligence tool over a weekend, then such an application must essentially be a frontend project — quick to build, easy to manage. This assessment holds true for the visible part. However, it underestimates what a user-centric B2B application actually consists of.

The shift brought by these new tools is real: UI development — for years a major cost driver in such projects — has become significantly faster and cheaper. What used to take weeks of frontend work can now be generated in a fraction of the time. This measurably lowers the entry barrier for data-driven sales tools.

Yet the UI is not the application itself, but merely its window. Building it quickly is quite different from knowing which recommendation a sales team will actually use in their day-to-day work — rather than ignoring it after three weeks. AI has reduced the visible effort; but it has left untouched the effort that determines adoption and utility. Anyone building a sophisticated design-in assistance tool works on a stack of competency layers, of which frontend code is the thinnest and most easily reproducible. Below it lies the effort that distinguishes a mere interface from a usable application.

The recommendation logic: from generic to context-relevant, prioritised, and action-oriented

At the core of such a tool is a recommendation logic that turns data into sales-relevant suggestions — cross-sell, up-sell, alternative products, BOM additions in the context of a specific customer opportunity. This sounds like a solved problem, but it is not, as soon as you take the objective seriously: the difference lies between a generic and a context-specific recommendation.

Generic means: a suggestion that sounds plausible in many situations and therefore fails to carry weight in any of them. A sales representative needs the opposite — a suggestion that is highly relevant in the context of this specific customer opportunity: tailored to the target application, customer and industry segment, project stage, the registered product environment, and the history of comparable opportunities. Only this level of context turns a technically feasible recommendation into one that the sales rep can confidently present to the customer.

However, context relevance alone is not enough when you end up with twenty valid suggestions side-by-side. A viable logic analyses the entire available database — transaction history, master data, opportunity context, reference designs, expert knowledge — and derives from it not just what fits, but in what order of priority. This prioritisation is the real lever: it surfaces the recommendations that contribute most to design-in and BOM coverage at any given moment, making those opportunities visible that fall outside the primary sales focus and are regularly missed during manual reviews.

The final step determines whether a good recommendation translates into action: it must be action-oriented. A correct, well-prioritised suggestion that leads nowhere fizzles out in day-to-day operations. Only when a recommendation is immediately actionable — with product details at hand, as a task within the project context, or exportable to share with the end customer — does it become part of the sales workflow rather than just another piece of information that the user must first translate into actions themselves.

This is precisely where the first underestimated effort lies: a recommendation logic that delivers context relevance, prioritisation, and actionability across all data points is the result of many iterations with real users — a highly refined alignment between data analysis and actual sales team behaviour, not the bi-product of a good algorithm.

Data Intelligence: the unglamorous work that determines everything

Beneath the recommendation logic lies the layer that is most regularly underestimated in in-house developments: the preparation of the data itself. Recommendation quality is only ever as good as the underlying database — and real-world sales data is rarely clean.

It comes from heterogeneous sources, in different formats, with inconsistent naming conventions, gaps, and contradictions. Before this can yield a usable recommendation, these sources must be cleaned, enriched, and mapped to a consistent product and application taxonomy, conflicts must be resolved, and sparse histories must be supplemented — a methodology refined over multiple project generations that accounts for the lion's share of the effort long before the first recommendation appears on a screen. This layer is overlooked because it is invisible: you see the frontend and the recommendation, not the weeks of taxonomy mapping and consistency checking without which both would be worthless.

The frontend: built faster, but not trivially decided

Precisely because user interfaces used to be so costly to develop, AI-driven acceleration here is a genuine benefit — and that is exactly why it is worth looking at what it takes off your hands and what it does not. It accelerates the building of the frontend; it does not make the decisions that constitute a good frontend.

After all, the value of a frontend was never just in the pixels or the build time. It lies in the hundreds of business- and user-driven decisions encoded within it: which use cases are made visible and which are deliberately omitted? How does the content remain relevant and clutter-free, rather than overwhelming the user with options? How do internal sales, field sales, and application engineers collaborate within the same tool? These questions never primarily cost development time in the past — they cost insight. And that part has not become cheaper through AI.

An AI can generate a frontend faster than ever today. It cannot tell you which frontend will drive a sales team to act. The interface is the embodiment of product decisions derived from real user contact — the build time for this has decreased, but the cognitive effort behind it has not.

Adoption: the most common failure has nothing to do with software

Ultimately, success or failure is decided by the layer that has the least to do with technology. The most common failure of internal tools is not that they cannot be built — but that they are built and then not used.

The context for this is structural, not motivational. When a significant portion of working hours in B2B sales is spent on administrative tasks — various studies place the share of non-selling activities at around two-thirds — a new tool is initially just additional complexity in an already overloaded daily routine. It will only gain traction if it visibly gives back more time than it costs, and if its introduction is actively supported.

Adoption is therefore a distinct capability: user onboarding, training, ongoing support, regular feedback loops, and continuous refinement of what the tool displays. This work cannot be cast into code. It comes from the experience of having successfully deployed such a tool in a real organisation before — and having observed where others failed.

AI helps below the frontend too — but only with understanding

AI delivers a significant contribution beyond the frontend as well: in data cleansing, taxonomy mapping, backend components, and the recommendation logic itself. The difference lies not in whether it helps, but in how you leverage this help.

At the UI level, a generated output can be assessed visually — you can see if an element is in the right place. In the layers below, this is not possible. Whether a taxonomy mapping is technically correct, a conflict resolution makes business sense, or a recommendation holds water in an opportunity context — or just looks plausible — cannot be determined at a glance. It requires a deep understanding of data structures and their interdependencies; without this, reliable implementation is impossible, and simply copying AI-generated results produces errors that are difficult to detect.

This also answers the obvious question of whether AI will completely take over data intelligence in the future. Part of it will be automatable — schema matching, duplicate detection, and mapping suggestions will improve. But "correctness" here is not a technical metric, but a domain-specific standard that lies outside the data: in the actual behaviour of applications, customers, and sales. A model generates a plausible-looking answer; whether it is correct can only be evaluated by someone who knows the target business state. Even an existing predictive model is only a foundation — it raises the ceiling of what is possible, but does not replace the layers above it.

This should not lead to hesitation, but the opposite: the goal is to proactively leverage the capabilities of AI and LLMs in data intelligence — wherever it makes business and technical sense. The leverage is substantial, ranging from accelerating tedious data preparation to enriching sparse datasets. What is critical is that the application is guided by someone who thoroughly understands the data structures and their relationships. In this way, AI shifts the work from generation to evaluation — making domain expertise not obsolete, but the actual value lever.

What counts in the end

The enterprise-grade foundation that supports all of this comes on top: a scalable, multi-tenant backend with data isolation and role-based access control, hosting in compliance with corporate IT policies, security, compliance, backups — and the ability to launch without initial integrations while still cleanly connecting to the ERP and CRM landscape via APIs later on. This, too, is effort that never shows up in a frontend demo.

When you add up these layers, it becomes clear how little a user-centric B2B application has to do with its frontend alone. The code is reproducible, and the interface can be built faster today than ever before. What has not accelerated is the accumulated judgment regarding what needs to be built: which recommendations users accept, how to make sales data recommendation-ready, which use cases actually matter, and how to get a team to adopt the tool. This is the real consequence of AI acceleration: it lowers a major, real-world development cost — and clears the view to the layers it cannot handle. An application that succeeds with sales teams from version one is not created at the surface, but in what grows together underneath over years.

Beyond this single tool

What becomes apparent here using the example of a design-in assistance tool is not an isolated case in the electronics industry, but the fundamental pattern of business applications in the AI era. The cheaper software generation becomes, the more clearly the bottleneck shifts to what software has never been alone: understanding the business it intervenes in, the processes it is meant to transform, and the system landscape in which it must persist. Truly solving a business challenge requires the interplay of these three types of knowledge — and none of them drop out as a bi-product of good code.

Furthermore, user requirements are not a static target that you hit once. They shift with the market, the portfolio, and the people operating the tool. A viable solution is therefore less a finished product than an ongoing engagement with changing requirements — a process that does not end when the first version is shipped. AI accelerates building. It does not accelerate the continuous work of understanding — and that is precisely where it is decided whether a business application remains relevant beyond its first release.