Skip to content
B2B platforms

Build or buy: when a custom B2B platform pays off and when it does not

An honest breakdown of when an off-the-shelf product wins and when a custom B2B platform does. The 30% customisation rule, total cost of ownership over two to three years, and the questions that decide it.

By Nikolay Mazur · · 7 min read · Originally published in Russian: читать оригинал

Short answer: build a custom B2B platform when off-the-shelf products need more than 30% customisation, or cannot hold business logic that is critical to you — complex roles, document workflows, industry requirements. In every other case, buying is cheaper and faster. A good studio will talk you out of custom development more often than into it, because a custom platform does not win on the price of the rollout. It wins, if it wins at all, on cost of ownership over two to three years.

Here is how to make that decision without an expensive mistake.

Why “let’s build our own” is the most expensive hypothesis

The temptation is easy to understand. The off-the-shelf CRM “almost fits”, it is just missing a couple of fields, one status and an integration with the warehouse. It feels like your own system would solve everything, permanently. In practice a custom B2B platform is a six-figure budget and four to six months to production, plus support and development after launch.

So the first question is not “what do we want”. It is “what breaks if we take the product as it is and live with its limits?” If the answer is “nothing critical”, you do not need development. Building your own makes sense exactly when those limits cost you money every month.

The 30% rule

The working criterion we use during pre-sales:

  • The product covers 70% or more of the process out of the box or with light configuration — buy it. Custom work here is throwing money away.
  • The product needs more than 30% customisation — custom modules, rewritten logic, heavy integrations — then it is worth costing out a build. At that threshold, the price of bending someone else’s product catches up with the price of your own, and you are still hostage to their release schedule.

The 30% is not about the number of fields, it is about business logic. Adding a field and a report is something any product survives. But when you have four roles — customer, partner, manager, administrator — and the process runs on documents, statuses, payments and approvals that do not fit the vendor’s model, you are already past the line.

A decision tree between an off-the-shelf product and a custom B2B platform: up to 30 percent customisation means buying the product, more than that with business logic that does not fit the product model means costing out custom development and comparing cost of ownership over two to three years; before either option, try the cheapest thing that removes the pain

The 30% threshold is measured by business logic, not by the number of fields: any product survives an extra field and a report, four roles with approvals it does not.

Five signs you have outgrown the box

In our experience a custom platform pays off when at least three of these are true:

  • Several roles with different permissions and different interfaces — not “manager and admin”, but customer plus partner plus several internal roles, each with their own workspace.
  • The process lives in documents and statuses — approvals, generated contracts and acceptance certificates, multi-step workflows that the product forces you to fake.
  • Critical integrations — accounting, telephony, payments, warehouse, partner APIs, where the stock connector does not cover your specifics.
  • The product has become a drag rather than a support — half the working day goes into workarounds, and every vendor update threatens to break your customisations.
  • The process is your competitive advantage — the way you work with partners or customers is the reason people buy from you. That should not be constrained by somebody else’s product model.

One match and an off-the-shelf product with configuration will almost certainly do. Three or more and the conversation about building becomes concrete.

Cost of ownership, not the price of the rollout

The classic mistake is comparing launch prices. Look at two to three years instead:

  • Off-the-shelf: licences or subscription that grow with headcount, the cost of customisation for every change, the risk that a vendor update breaks what you built, and a ceiling you will not get past.
  • Custom: higher upfront investment, but a predictable cost of ownership, code and rights that transfer to you by contract, and a roadmap driven by your priorities rather than the vendor’s.

The crossover usually arrives where the subscription plus regular customisation over two to three years catches up with the cost of building — and all that time you are working in a system you do not control.

Reducing the risk: an MVP for one role, not everything at once

Even when the decision to build has been made, building all of it in one pass is a bad idea. We almost always start with an MVP for a single role — the one with the most manual work. That is eight to twelve weeks, rather than “six months and a large budget, blind”.

The logic is simple. The MVP closes the most painful scenario, produces a measurable effect — cycle time usually drops by 40–70%, the share of manual operations down to 10–20% — and once it runs on real data you can see what to build next. A full production platform with three or four roles and integrations becomes the next step, not the opening commitment.

The same principle works in reverse. Sometimes, instead of a platform for that first role, a Telegram bot that replaces the login-protected dashboard does the job for a fraction of the cost. Start with the cheapest thing that removes the pain.

When the honest answer is “you do not need development”

There are situations where we tell a client plainly not to commission a platform:

  • the process is standard and fits a mainstream CRM;
  • the team is under five to ten people and the process still changes every month — stabilise it on an off-the-shelf product first;
  • there is no product owner on your side who can make decisions about the logic, which is risk number one and more expensive than any code;
  • the budget covers the launch but not the support and development afterwards — an abandoned custom system is worse than a living off-the-shelf one.

The hybrid usually beats both extremes

A pattern worth naming, because it comes up constantly. Keep the storefront and the connectors on a ready-made service, and build your own layer only where your own maths is calculated. That is cheaper than a full build and more honest than pretending an off-the-shelf product understands your margins.

Four things push you towards your own layer:

  1. The calculation is specific to you and the vendor’s report cannot express it.
  2. You need history the vendor does not keep.
  3. Your internal systems need the data, not just a human looking at a dashboard.
  4. You want to expose the data outwards — to customers or partners, through an API or a portal. Someone else’s aggregator is not built for that, and you are not entitled to resell it.

In short

  • Do not ask “do we want our own”. Ask what the product’s limits cost you every month.
  • The 30% rule: less, buy it; more, cost out a build.
  • Three or more signs — roles, documents, integrations, hitting the ceiling, process as advantage — and building is a real option.
  • Compare cost of ownership over two to three years, not the price of the rollout.
  • Start with an MVP for one role, and sometimes with a bot instead of a portal.

If you are not sure whether you need to buy or build, describe the process and we will cost out both.

Facing a similar problem?

Tell us what you are building. We will walk through the architecture and give you a budget range in one call.