B2B Portal Development: Your processes aren’t standard—and neither should your portal be

Every B2B company is familiar with this situation: A customer calls to ask about the current delivery status of an order. Someone from the back office checks the ERP system, verifies the order number and status, and calls back. By the time the customer receives the information, at least 15 minutes have passed.

These 15 minutes represent a system gap. The customer could have accessed their data and checked the status of their order long ago. However, portals that do exactly that can rarely be implemented using standard software. Prices are not fixed in the B2B environment, and some purchases require approval.

In this article, we’ll explore when a custom portal makes sense, what’s important during development, and why portal projects often fail.

The real difference lies in the rights and pricing logic, which is why logging in is more than just a formality. That’s where customer-specific data comes into play. In a B2C store, all customers see the same price; in a B2B portal, the price is based on framework agreements, volume discounts, and limited-time promotions, and thus varies from customer to customer.

There are also other factors that add even more complexity. In companies, not every person placing an order has approval authority, and not every approver has the right to place an order. Corporations also often have multiple shipping addresses. In some cases, it must be possible to assign an account, and certain items may not be visible to certain customers at all.

These requirements form the foundation of the application and are therefore very difficult to add later on. This is where off-the-shelf software quickly reaches its limits.

The most appropriate solution for B2B companies varies greatly from one company to another. In some cases, off-the-shelf software may be the right choice. This is true, for example, when a company’s processes are closely aligned with industry standards, or when the company does not yet know exactly what its customers expect. Off-the-shelf software can then serve as a learning tool initially. In addition, off-the-shelf software is ready to use right away, which can benefit many companies.

However, if the list of required customizations becomes longer than the list of used features, companies should consider having custom software developed. Otherwise, there is a risk that processes will be adapted to the software rather than the other way around. Furthermore, every new release from the off-the-shelf software vendor becomes a risk, as it can cause the company’s own customizations to stop working.

Companies should consider the following criteria:

Important: This decision does not have to be permanent. Companies often choose to use off-the-shelf software as a market test and then switch to a custom solution.

Security is also an issue that must be addressed as early as the requirements phase. A B2B portal processes prices, terms, contracts, and, in some cases, personal data—precisely the kind of information that should not fall into the hands of competitors or be exposed in a data breach. If security is not tested until the acceptance phase, errors in the architecture can no longer be corrected but can only be patched up as a stopgap measure.

The established alternative approach is called “Security by Design.” Security requirements are defined during the requirements analysis phase and carried forward throughout the entire development process. This approach is based on several principles:

• Zero Trust: No access is considered trustworthy, not even from within the organization.
• Least Privilege: Each role is granted only the permissions it actually needs to perform its tasks.
• Defense in Depth: Multiple, layered levels of protection ensure that the failure of one layer does not immediately expose the entire system to attackers.
• Separation of Duties: Critical operations are distributed across multiple roles.
• Secure Defaults: The default setting grants no permissions; permissions must first be explicitly granted.

This is particularly relevant for portals because the permissions structure serves as both a security issue and business logic. Who is authorized to place orders, who approves them, and who sees which prices—these are all the same question, regardless of the perspective from which it is asked. Careful modeling therefore addresses both aspects at once.

In RFP documents, technology is often treated like a menu: classic or headless, platform or in-house development, this ecosystem or that one. In practice, these are layers that can be freely combined with one another.

This is best illustrated by the term “headless,” which is most often misunderstood. “Headless” describes how content and features are delivered—namely, via interfaces rather than tightly coupled page templates. The term does not, however, specify what the backend is built with. A headless portal running on a .NET backend works just as well as a traditionally rendered portal with a modern JavaScript front end or a hybrid architecture in which editorial pages run traditionally and self-service sections run headless. The real question, therefore, is which channels need to be supported.

Three decisions, on the other hand, do carry real weight, and they are independent of one another:

• The integration layer: Does the portal access data from ERP, CRM, and other line-of-business systems directly, via middleware, or through its own service layer? This determines whether a source system can be replaced later without modifying the portal. This decision has the greatest long-term implications, yet it is often made in passing.
• The balance between off-the-shelf solutions and in-house development: Content management, permissions, multilingual support, search, and catalog functions are already solved problems. A platform serves as a foundation, taking care of these aspects and leaving room for the actual business logic. Portals that consist almost entirely of transactional functions and hardly any editorial functions, on the other hand, often do not need this additional layer.
• Future Operations: An infrastructure that your own team cannot maintain is the wrong choice, regardless of its technical elegance. Those who host their own systems also make different decisions than a company that deliberately chooses to outsource this responsibility.

The choice of language and framework stems from these considerations. Where an established system landscape already exists, it sets the framework anyway, and a portal project is rarely the right reason to deviate from it.

The reasons for failure are rarely technical in nature. Four patterns, in particular, recur time and again:

• The initial scope is too broad: Specifications take months to finalize before anyone has even used the portal, and by the time it goes live, the technical details no longer match reality.
• Integration is underestimated: The front end is ready, but the data from the ERP system isn’t coming through cleanly, quickly enough, or completely.
• There’s no internal rollout: A portal that nobody explains and for which nobody internally feels responsible is often ignored by sales and internal staff.
• There is no subject-matter decision-maker on the client side: Without someone authorized to make content-related decisions, decisions get bogged down in endless coordination loops.

This can be addressed by deliberately keeping the initial scope narrow, integrating from the very first sprint rather than at the end, establishing clear technical responsibilities on both sides, and having a team that stays together long enough to truly understand the business.

The idea that design is secondary in B2B because it’s all about functionality is a costly misconception. Business users bring with them the exact same expectations they’re used to in their personal lives, because there’s no such thing as adapting to a different set of norms just for the workplace.

As a result, a cumbersome portal is simply bypassed. Phone and email remain the go-to methods, and in the end, the company ends up bearing the costs of both the portal and the manual process at the same time.

Key factors include streamlined workflows for daily tasks, fast loading times even with large catalogs, a user interface that works equally well on desktops and smartphones, and a role structure that reflects the customer’s actual organizational setup rather than an idealized organizational chart. Once these issues are resolved, the tool—which was previously merely tolerated—becomes the preferred channel, and only then does the investment pay off.

It would be irresponsible to give a flat figure, as the range is so wide. A specialized customer portal with an order overview, document access, and a seamless ERP integration operates on a completely different scale than a platform that supports sales, service, and partner business all at once.

The cost drivers are almost always the same, and their order is more revealing than any number: first, the level of integration; second, the scope of functionality; and third, security and compliance requirements. The budget, therefore, depends less on the number of features and more on how many systems need to be integrated and the quality of the data involved.

That’s why an approach that resists the temptation to go for a “big bang” has proven effective: start with a clearly defined initial implementation that fully maps a single, real-world process, rather than ten processes that all only work halfway. This results in a robust business case that serves as a solid foundation for planning all subsequent steps.

The same applies to duration. It depends less on team size than on how tightly defined the initial scope is and how quickly the client makes technical decisions. Projects are almost always delayed by coordination loops and waiting for access to interfaces—rarely by the development itself.

The scope of work and timeline can only be accurately assessed once three elements are on the table: the processes the portal is intended to support, the systems that need to be integrated, and the actual state of their interfaces. A brief preliminary analysis usually provides clarity quickly.

A good B2B portal isn’t a project with an end date—it’s a product that grows with the business. New features, additional systems, new user groups, and changed processes are added over time.

Anyone planning the development this way from the start should keep three things in mind: an initial rollout that’s small enough for a quick go-live but large enough to deliver real value; an architecture that enables expansion rather than hindering it; and an operational framework that supports ongoing development. Then, even in five years, the portal will still be an asset and won’t become the next project in need of a overhaul.

We don’t commit to a specific technology upfront. The appropriate foundation, delivery format, and integration layer are determined by the existing system landscape, the business requirements, and the team that will later operate the portal. We implement classic, headless, and hybrid architectures equally, as well as platform-based and fully custom-developed portals.

One thing remains constant in every project: Integration is part of the plan from the very beginning. We develop according to the “Security by Design” principle, with clear role- and access-based concepts, encryption, and traceable logging, accompanied by static code analysis. We’ve been gaining IT security experience since 2001 and have been developing software for over 25 years. And because B2B portals run for many years, we plan for their operation and ongoing development right from the start.

Are you wondering whether a custom B2B portal is worth the investment? Then let’s talk about your processes—not just feature lists. Get in touch with us, and together we’ll figure out where the greatest potential for impact lies.