Companies that spent years selling wholesale through emails, phone calls and spreadsheets eventually hit a wall. Orders get lost in inboxes, sales reps retype line items by hand, and individual price lists live in the heads of a few people. That is where the question of a custom B2B system comes up – a platform tailored to how you actually sell, rather than the other way round. As the Web Systems team, a software house from Łódź operating since 2006, we design and implement such solutions from the technical, integration and maintenance side. Below we show how to think about a platform like this from the perspective of a contractor who knows its whole life cycle, not just a good-looking demo.
Spis treści
Why a company needs a custom B2B system instead of an off-the-shelf solution
The difference between boxed e-commerce and a custom B2B system comes down to the direction of the fit. An off-the-shelf platform imposes its own processes and you bend your sales to match them. A custom application does the opposite: it mirrors the way you really work. Negotiated prices, discount thresholds, credit limits, unusual order approval paths. In B2B the rules can be specific enough that ready-made templates quickly start to chafe.
There are a few clear signals that a company has outgrown its makeshift setup. These are the most common ones:
- Sales reps manually retype orders from emails and PDFs into the warehouse system.
- Individual customer price lists are kept in multiple, often contradictory, versions of spreadsheets.
- The customer cannot see their purchase history or current stock levels, so they call for every piece of information.
- Errors in prices and availability only surface once the invoice has been issued.
There also comes a moment when customizing a ready-made platform stops paying off. More plugins, workarounds and overlays on a standard engine cost more than designing an application from scratch, and on top of that they make updates harder. Our practice points to a simple rule: if the business logic requires constantly “tricking” the tool, the foundation is simply wrong. The decision to build your own system is usually driven not by fashion but by real pain. A growing number of mistakes, time lost on handling orders, no scalability. That is when custom software development becomes an investment in order rather than an expensive whim.
Three user groups, three different needs: customers, partners and sales reps
A good B2B platform serves three worlds at once, and each of them expects something different. The customer wants to place orders quickly, without scrolling past features that do not concern them. What matters to them are individual price lists, a view of their granted credit limit, a readable history and repeatable carts that let them reorder the same items with a single click. This is a user who values predictability and the smallest possible number of steps to place an order.
A partner looks at the system in a completely different way. They care about commissions, the discount structure, access to stock levels in near real time and a settlement panel showing what has been sold and how much they earned on it. And the sales rep? They work in the field and need a mobile tool: they place orders on behalf of the customer, check target progress and often operate with poor signal. Three intentions, three logics of work.
The most common design mistake is cramming everyone into one universal interface. The result is predictable: a screen overloaded with options, of which each role uses maybe a third. The customer gets lost in fields meant for the sales rep, and the partner cannot find settlements underneath a layer of purchasing features. That is why we separate views by role and permissions from the start. The core stays shared – the catalog, prices and orders – while the presentation and available actions differ depending on who is logged in. Tip: design the paths separately for each role at the wireframe stage, before the first line of code is written. That is cheaper than untangling the interface after the rollout, once users have got used to the mess.
Architecture and technical decisions that determine how long the system lasts
A platform’s durability is decided at the architecture level, not in the color of the buttons. The starting point is separating the layers: the user interface, the business logic and the data. Each has clearly drawn boundaries and responsibilities. The most important thing is a single source of truth for prices, stock levels and orders, because this is exactly where the costliest errors are born. When the same price lives in three places, sooner or later the values start to differ.
Separation of responsibilities is the foundation of an application that is easy to maintain and extend. Discount calculation logic should not be mixed with the code that draws the screen, and database access cannot be scattered all over the project. Thanks to that, the team develops individual modules independently, tests them separately and replaces them without the risk that touching one element brings down the whole. The cleaner the boundaries, the less every subsequent change costs.
Some decisions have to be made at the start, because later they are painful. They include:
- The multi-tenancy model, if you plan to serve several organizations or brands in one system.
- The structure of roles and permissions, meaning who sees what and who can do what, described as a coherent model rather than a collection of exceptions.
- The way price lists and orders are versioned, so that you can reconstruct what the offer looked like on a given day.
Architectural shortcuts are tempting in terms of deadlines and budget, but their consequence is technical debt that grows along with the platform. Every feature forced onto poor foundations makes the whole thing more brittle. After a year or two, the system that was meant to speed the company up starts to slow it down, because every change threatens new failures. That is why we prefer to invest time in a solid skeleton instead of fixing the effects of haste later on.
Integrations with ERP, the warehouse and payments – the heart of a B2B system
A B2B system rarely lives on its own. Its heart is the integrations, because they decide whether the price on the screen matches the invoice, and the declared availability matches the actual stock. The key is synchronizing price lists, stock levels and order statuses through an API, ideally in a continuous and predictable way. A customer who orders a product shown as available and a day later learns it is out of stock loses trust in the entire platform. And it is hard to blame them.
In project practice, integrations are the area of the biggest surprises. The typical traps we run into are a lack of API documentation in an older ERP, delays in synchronization and data conflicts when two systems modify the same record at the same time. A direct, rigid connection where “the system asks the ERP on every click” tends to be brittle: one moment of unavailability and the platform stops working. That is why we design an error handling strategy and task queuing. Operations go into a queue, are retried on failure, and the user is not left with a blank screen when the ERP happens not to respond.
It is worth writing down the full list of systems to connect at the beginning, because the appetite usually grows along the way. Most often it covers:
- ERP – the source of price lists, business partners and sales documents.
- WMS, that is the warehouse system responsible for real stock levels and locations.
- Payment gateways handling transfers, deferred payments and trade credit limits.
- Accounting systems for invoices and settlements.
- CRM linking the history of sales contacts with orders.
Each of these integrations has its own pace, data format and limitations. The sooner we recognize them, the fewer costly surprises during the rollout. Tip: before construction starts, ask the ERP vendor for test access and documentation, and if there is none, plan time for reverse engineering the interfaces.
Security, data and scalability – what the demo does not show
A demo shows pretty screens but says nothing about the hardest parts: security, data protection and how the system behaves under load. In B2B, individual price lists and commercial terms are especially sensitive. A leak of such information to the competition can do more damage than an outage, which is why we design access so that every business partner sees only their own prices and data. Data isolation between customers is not an add-on, it is a basic requirement.
The second pillar is access control. Solid authentication, a precise role model, event logging and limits on what the partner and the sales rep can see protect both the company and its business partners. An event log, meaning who performed which action and when, can be invaluable when clarifying disputed orders or suspicious logins. It is also part of compliance with requirements concerning personal and commercial data.
Scalability is settled at the design stage, not when traffic is already growing. You have to anticipate seasonal peaks, growth in the number of business partners and an expanding product catalog. A system designed for a hundred companies and a thousand SKUs handles load differently than one prepared for ten times that. That is why from the beginning we look at query performance, database indexes and mechanisms for caching repeatable reads.
A separate and often overlooked topic is field work. A sales rep at a customer’s site is sometimes in a place with no signal, so it is worth providing an offline mode and later synchronization of the orders placed. The application should remember actions locally and safely send them once the connection returns, without the risk of duplicating orders. These are details you do not see in a presentation, and they decide whether people really start using the system.
Rollout, maintenance and total cost of ownership (TCO) of the platform
A sensible rollout starts with an MVP, meaning a version covering the most important processes, not with the full system straight away. A minimum product lets you check whether the designed ordering path actually matches the work of customers and sales reps, before the company pumps money into the full scope of features. It is better to discover a wrong assumption on a small scale than after a year of building an extensive platform. That order of work limits risk and puts priorities in order.
The total cost, that is TCO, is far more than the build itself. The bill also includes:
- Hosting and infrastructure that scale along with traffic.
- Monitoring and incident response, so that a problem is caught before the customer notices it.
- Library updates and security patches.
- Continuous development, because sales processes change over time.
Leaving these items out of the budget leads to disappointment when “unforeseen” expenses appear after the rollout, expenses that were in fact quite foreseeable. A separate and heavily underestimated risk is migrating data and business partners from the old system. Historical price lists, outstanding settlements, inconsistent records. This can consume more time than building several modules. That is why we treat migration as a separate project with its own plan and tests, not as a task for the last day.
And finally the simplest thing, and the one most often dismissed: a maintenance plan. A system with no technical owner, no updates and nobody responding to tickets slowly turns into abandoned, unsupported software. After a few months nobody knows how a certain module works, and the fear of changing anything grows. Well planned maintenance means the platform ages with dignity and still supports sales instead of blocking it.
FAQ – the most common questions about a custom B2B system
How long does building a custom B2B system take and what determines the time?
Realistically, a sensible MVP usually takes a few months, while the full platform develops in stages over a longer period. The pace depends on the number of roles, the complexity of price lists and discounts and, above all, on the integrations. Those tend to be the hardest to estimate when the ERP documentation is poor or the interfaces behave unusually. The sooner we identify those limitations, the more accurate the schedule we can give.
Can the system be connected to our ERP if it is old or unusual?
Most often yes, although the route varies. When the ERP exposes an API, we connect directly and synchronize data through queues with error handling. With closed systems we use exports, file exchange or an intermediate integration layer. The key is analysis at the start: we check what data can be read and written and how often it can be synchronized without the risk of conflicts.
Is it worth starting with an MVP or building the full platform right away?
We almost always recommend an MVP. It lets you confirm that the process has been designed well and gather reactions from real users before expensive additional features are built. A full platform built without that validation easily gets over-invested in areas nobody uses. A staged approach protects the budget and leaves room for correcting course.
If you are planning a custom B2B system, the modernization of an existing platform or an integration with an ERP, warehouse or payments, we will gladly look at it from the technical side. At Web Systems we will help you plan the MVP, design the architecture and safely connect the systems you need, including elements of automation and AI applications. Get in touch and together we will work out a sensible first step.
