Wholesale is still sold by email. A message arrives: "we need such-and-such items, please confirm availability and price." A sales manager opens 1C (Russia's leading ERP and accounting platform), finds the customer, looks up their contract discount, checks the stock, replies by email, agrees the changes, and then keys the order in by hand. Twenty requests a day means one and a half people busy retyping. Sooner or later the director looks at this and says: let's build a customer portal and let them order for themselves. And almost in the same breath names a deadline: "a month, two at most."
The rest of this article is about what that month is really made of.
A "customer portal" is five different projects
Clients mean very different things by the same two words, and the spread between them is enormous.
- A status window. The customer logs in and sees which orders have been accepted, what has shipped, and what is in transit. The data is pulled in from your accounting software, and nothing can be changed on the site.
- Statuses and documents. Invoices, delivery notes, and closing documents go there too. The customer's accounting department stops writing "please send it again, we lost it."
- Ordering from a personal price list. This is where everything changes: contract prices appear, along with discount matrices, pack multiples, a minimum shipment amount, and stock reserved for an order.
- Money and roles. Payment, receivables, a shipment credit limit, and different permissions for the customer's staff: the buyer sees prices, the warehouse clerk sees only shipments.
- The full portal. Uploading an order from Excel, repeating a previous delivery, approving specifications, claims, delivery cost calculation.
The difference between the first level and the fifth isn't a factor of one and a half. It's roughly ten. That's why talking about timelines without an answer to "which of the five" is pointless: any number would be a guess.
The visible part is the smaller part of the work
The customer sees a product list, a search box, a button, and a cart. It looks like an ordinary online store, hence the feeling that there isn't much work in it.
Take a single line: the price. In wholesale, a customer-specific price almost never sits there as a ready-made number. It's a set of rules: customer A gets twelve percent off the "light fixtures" group, customer B has a fixed price list from an appendix to the contract, customer C's price depends on the volume taken over the month, and customer D is on an old agreement that only one sales manager knows about. The rules exist, but they live in the accounting software and in people's heads. Before a price can be shown on the site, they have to be pulled out down to the last caveat, and that isn't a programmer's job. It means going through your processes together with your sales department.
The same goes for stock. You can honestly show "in stock" only when it's clear where the number comes from and how fresh it is. We run a catalog of 400,000 items where the exchange with 1C used to go on a schedule: between exports the storefront showed yesterday's prices, and a customer had time to order something that was already gone. The cure wasn't a button in the settings. It was a separate program that keeps a fresh copy of prices and stock levels and serves them to the site even at a moment when 1C is unavailable.
In our experience, what you can see with your eyes is about a third of the work. The rest is price calculation, access rights, the link to the accounting system, and the part people notice only when it breaks.
Where the months come from
Break a level-three or level-four portal down into stages and the picture looks like this.
- Process analysis and design: 2–4 weeks. Who places orders, how the price is calculated, what happens with a partial shipment, who approves going over the limit. Half of this time is spent not by us but by your staff: the questions go to them.
- Prototype and visual design: 2–3 weeks. First a clickable draft with no pictures, then the look.
- Development: 6–12 weeks, in chunks of one to two weeks, with a working version shown at a test address after each chunk.
- The link to 1C: from 2 to 6 weeks, and this is the least predictable part: everything depends on the state of the accounting software and on whether it has a specialist of its own.
- Data migration, testing, and launch: 2–3 weeks.
That adds up to three to five months, not one. And part of that time isn't in the developers' hands at all: we wait for access to the accounting system, wait for a decision on who owns the pricing rules, wait for the one person who remembers the logic of the old contracts to come back from vacation. On projects where those answers arrive within a day, the work moves noticeably faster.
Who takes part
A portal isn't built by one person, and here is why. You need someone who draws and thinks through the screens, so that a buyer finds what they need without training. You need someone who writes the invisible part: price and discount calculation, orders, access rights. You need someone who builds the pages, buttons, and cart. You need a person for the servers: updates, backups, watching that the site is working at night and during a sale. You need a tester who, before release, walks through scenarios like "a customer with an overdue payment tries to place an order." And you need someone who holds all these threads together and talks to you: the project manager, a role we have already covered separately.
That doesn't mean six people working on the project full-time. On a mid-sized portal, one developer covers both the visible and the invisible part, the designer comes in for a couple of weeks, and the server specialist for a few days and then now and again. There is also the one-man-band option, and it honestly works at levels one and two: there are few rules and no link to the accounting software. At level three that format starts to let you down, not for lack of skill but because one person becomes the single point of failure. They get sick, leave, or lose interest, the project stops, and there is nobody to make sense of their code.
Where expectations and the result part ways
The main risk in projects like this isn't "they'll build it badly" but "they'll build the wrong thing." The portal comes out working, tidy, and out of step with how the business actually runs.
The gap almost always grows from three places. The first is the brief "make it like our competitor's": the competitor has different contracts, a different product range, and possibly a different problem. The second is sign-off by picture: the mockup was approved, but nobody talked through returns and partial shipments, because they weren't in the picture. The third is testing on made-up data: on "Product 1" everything flies, while on the real catalog, with SKUs written in Cyrillic letters and items with no stock, half the problems come out.
The cure is boring things. A clickable draft before development starts: it shows what's missing, and a change costs hours, not weeks. A working version shown every one to two weeks instead of one big demo at the end. A list of "what has to work" written in plain words: specific situations, not "a user-friendly interface." Testing on an export of real data. And one person on your side who makes the decisions. Otherwise three departments keep correcting each other in circles and approvals eat up the schedule.
The cost of a mistake here is easy to measure. A portal that customers don't use saves nothing: sales managers keep keying in orders by hand, and on top of their work comes the upkeep of a system nobody logs in to.
When it's too early for a portal
Not everyone needs custom development. If you have fifteen regular customers and each orders once a quarter, manual processing costs less than any portal, and it's more honest to do the math that way. If your pricing rules are simple, a common price list and three discount tiers, look at ready-made solutions first: off-the-shelf B2B modules and add-ons for the accounting system launch faster and cost several times less. They have one limitation, but a serious one. As soon as your rules stop fitting the template, a fight with the product begins, and reworking it ends up costing more than building from scratch.
An intermediate step works too: build the window with statuses and documents first, without ordering. That's weeks of work, not months, and it immediately takes away a noticeable share of the "where is my order" calls. It also shows whether customers log in at all, which is the best argument for or against the next level. Development built around a specific process has its downsides too: a higher upfront cost, and the need for someone to look after the system afterward, because a living portal has to change along with the business.
What to look at first
Before discussing timelines and budget, answer three questions for yourself:
- Exactly which manual work you are removing, and how many hours a week it takes now.
- Which of the five levels the portal you need sits on.
- Who on the company's side can produce the price calculation rules in writing within a week.
The answers affect the timeline more than the choice of contractor or technology does.
And keep a simple proportion in mind: the more time goes into analyzing processes before the work starts, the less goes into rework after launch. Saving on the first stage is the most expensive saving there is.
