What a custom B2B platform costs, and why the range is so wide

In short. An MVP of a B2B platform covering one user role takes 8–12 weeks. A working platform with several roles, approvals and integrations takes 4–6 months to production and costs several times more. The spread inside the range is set by three things rather than by the volume of programming: how many user roles the system has, how complicated the status transitions are, and how many external systems the platform must exchange data with.

What follows is what the sum is made of, what moves it most, and why an estimate given without examining the process is almost always wrong.

We quote in roubles, so the figures below are given as proportions and timelines rather than converted amounts — convert at the rate of the day if you need an absolute number, or ask us for a quote.

What the budget is made of

It helps to see an estimate not as “development hours” but as five different kinds of work. A vendor who names a price straight away is usually counting only the second.

Line	Share of budget	What is inside
Process analysis and design	10–15%	Interviews, role map, status diagram, mockups of the key screens
Development	40–50%	Backend, interfaces, access rights, reports
Integrations	15–25%	Accounting system, mail, payments, the client’s external services
Data migration	5–15%	Moving reference data and history out of spreadsheets and old systems
Launch and stabilisation	10–15%	Load testing, training, fixes in the first weeks

Two lines are usually underestimated. Integrations get counted as “we will connect the API” with a week allowed, and then it turns out the client’s accounting configuration is non-standard and the exchange has to be designed from scratch. Data migration does not make it into the estimate at all until someone discovers that ten years of client history lives in three spreadsheets that disagree with each other.

Three scenarios

MVP for one role, 8–12 weeks. The system has one type of user: a dealer, say, who sees the catalogue, the stock and their own orders. One end-to-end process, one integration with the accounting system, no complex approvals. This is a sound entry point, and it is what we recommend when a platform is being built for the first time.

A working platform, 4–5 months. Two or three roles (manager, client, head of department), a process with approvals, data-level access rights, reporting, two or three integrations. Most projects live here.

A platform with heavy exchange, 5–6 months and longer. Four roles or more, several parallel processes, two-way exchange with the accounting system, warehouse, payments, electronic document interchange. The price grows with the number of places where the system has to agree with another system, not with the number of screens.

What moves the estimate most

The number of roles. Each new role is not “one more screen” but its own set of rights, its own data visibility logic and its own acceptance scenario. Going from one role to three usually doubles the budget rather than adding a third to it.

How complicated the approvals are. A linear process — created, submitted, done — is cheap. A process where a request goes back for rework, goes out for parallel approval and changes route depending on the amount costs several times more, because it has to be described well enough that the client recognises their own work in the description, not just programmed.

The number of external systems. Every integration goes through a full cycle: work out how it behaves today, reproduce it, test against real data, switch over. Five integrations are not five small tasks but a visible share of the project. For a sense of scale, see what an accounting integration costs: that money sits inside the platform budget, not beside it.

What inflates a project quietly

Nobody to accept the result. The most common cause of missed deadlines in our projects is not development, it is acceptance. You need someone on the client side who will explain how the process actually works and check the result against their own data. The working benchmark is 20–30% of that person’s time for the length of the project. If nobody is named explicitly, two-week pauses appear between a finished piece of work and its review, and a six-month plan becomes a year without a single technical problem.

“Let’s have it, it might be useful.” Features added without a concrete scenario cost as much as real ones and get used in isolated cases. The test is simple: if you cannot name the employee who will open that screen next week, the screen is not needed.

Data in an unknown state. Until someone has looked at an export, migration is estimated blind. A counterparty list with duplicates and empty tax numbers takes several times longer to move than a clean one.

What brings the cost down

Start with one role. An MVP for the first role gives a working system and real feedback in 8–12 weeks. After that the remaining roles are designed from facts rather than assumptions.

Hand the commodity parts to ready services. Mail, payments, notifications, file storage: none of that is worth writing yourself. Custom development is justified where the logic is unique and nowhere else.

Audit first, estimate second. Analysing the process costs a fixed amount and takes weeks. After it the conversation is about a specific number instead of a wide range.

What ownership costs after launch

This gets asked about less often than it should. The benchmark is 15–20% of the development cost per year for support and development: hosting, dependency updates, fixes, small changes requested by users.

If that line is not in the plan, after a year the system starts falling behind the processes, and a year after that it gets declared a failure.

How to compare vendor proposals

If you have several estimates, comparing their bottom lines is useless: they were calculated for different things. What to ask each vendor:

1. How many roles are included, and which ones. The difference between two and four roles in an estimate is often bigger than the difference between vendors.
2. Which integrations are in the price and which are listed as “to be agreed”. The second phrase means they were not counted.
3. Whether data migration is included, and whether the vendor has looked at an export.
4. Whose time is needed on the client side, and how much. An estimate without an answer here assumes acceptance will happen by itself.
5. What support covers in the first year, and what it costs.

A fixed price named before the process has been examined is a bad sign in both directions. Either it contains a margin you will pay for, or the vendor will hit unbudgeted scope and start economising on what is not visible from outside.

Common questions

Can it be done for a small budget? Sometimes, if the task is genuinely narrow: one process, one role, no integrations. More often a number below the MVP range means the process analysis and the acceptance work have been taken out of the project, and they will have to happen anyway, later and at a higher price.

A platform, or customising an off-the-shelf CRM? It depends on the share of customisation. The rule we use ourselves: if the ready product needs more than a third of its functionality reworked, a custom platform is usually cheaper over three years. The full comparison is in custom build versus off-the-shelf.

Why a range instead of one number? Because until the process has been examined the main unknowns are unknown: how many roles, how branched the approvals, how many external systems. A vendor who names one number from a three-paragraph description is naming it blind.

How long does estimating take? A preliminary range: a few days from a description of the task. An estimate you can sign: two or three weeks of audit with interviews and a look at the data.

What the first step actually is

The position inside the range is set by the number of roles, how branched the approvals are and how many external systems are involved — not by the volume of code or the look of the interface.

So the sensible first step is not picking a vendor by price but examining the process. After that the range turns into a number and the conversation turns into a plan.

If the task is already defined, look at how we build custom B2B platforms and write to us: we will say honestly whether development is needed here at all.