On day fifteen we deleted the shared catalog. It was finished: search across every seller's products with suggestions, a category menu, section pages. Two weeks after kickoff all of it left the project, and the marketplace took a different shape, with each supplier getting a catalog of their own at their own link.
This is about Kup2B, a marketplace where companies sell to companies: a supplier lists products and sets prices for each customer, and the customer puts together an order and gets an invoice without anyone's help. We built it for ourselves and had no client to argue with, so it's easy to see which decisions set the amount of work. Almost none of them were about screens.
First, who pays
The familiar marketplace model is a percentage of every deal. It's a poor fit for wholesale, for two reasons.
Commission nudges both sides to leave. A supplier and a buyer find each other, run the first order through, and place the second one in a messaging app because it's a few percent cheaper that way. In retail the buyer is new every time. In wholesale the same pair of companies works together for years, and the marketplace gets paid exactly once.
The second reason is legal. To keep a percentage, the marketplace has to take the buyer's money and pass it on to the seller. That's a different role with different obligations, from the rules on accepting payments to liability for the goods.
We chose a subscription. The seller pays a fixed amount per month, the buyer pays nothing, and the money for a deal goes from one company's bank account to the other's without touching the marketplace. The decision has a price: revenue doesn't grow along with customers' turnover, and the seller has to pay before seeing any benefit. So we needed a trial period and separate rules for non-payment: the catalog is hidden, while orders, invoices and messages stay available.
Next came subscription invoices, matching payments against the bank statement, reminders, suspension. Not one of these items was in the first plan.
The shared catalog we had to remove
The first version copied a consumer marketplace: every seller's products in one set of results, where a buyer searches for "cable" and compares offers. Convenient for the buyer. For the supplier it means standing in one list with competitors and competing on price. And in wholesale the price comes out of arrangements with a particular customer, and nobody wants it shown next to someone else's.
There was another side to it. A marketplace that decides whose product to show higher is responsible for the rules behind that ranking: what criteria it uses to order sellers and whether it gives anyone an advantage. Sellers have questions about rules like that, and so does antitrust law.
After the rebuild, a seller picks one of three modes:
- the catalog is open to everyone and gets indexed by search engines;
- the catalog is visible only to buyers the seller has approved;
- the catalog opens with a password, for those the seller has given it to.
Search and filters work inside a single catalog.
There's no point hiding the downside: a marketplace like this doesn't bring in buyers. A supplier arrives with their own customers and gets a tool for working with them. Anyone expecting a stream of new customers needs a different model.
Every buyer has their own price
In retail a product has one price. In wholesale there are as many prices as customers: one gets 15% off cable and 5% off everything else, another a fixed price on three items until the end of the year, a third a discount starting at a hundred units.
We boiled this down to rules with three parts. Who: everyone, a customer group, or a single company. What: the whole catalog, a section, a tag, or an individual product. How: a percentage off the retail price, a fixed price, or a discount as a flat amount. A rule can also carry a quantity threshold and an expiration date. When several rules fit a buyer, one applies: by priority first, then by precision, so a rule for a specific company beats a rule for a group.
Two practical conclusions follow. A seller has to have a "view as customer" mode: pick a company and see the catalog with its prices and a note on which rule applied. Without it, people get lost in their own discounts by the time they have a dozen or so rules. And the price in an order is stored as a copy taken at the moment the order is placed, otherwise tomorrow's discount change rewrites yesterday's orders.
If you have ten customers and they all get the same discount, this whole mechanism is overkill. One "wholesale price" column from 1C (Russia's leading ERP and accounting platform) is enough.
Checking that a company is real
Registration looks simple: you enter a taxpayer ID (INN), and the company details are pulled in from the state business register. Then come the questions the form doesn't show. Is the person registering really an employee of that company? What do you do if someone has tied up another company's taxpayer ID with an unfinished registration?
In the end the phone number is confirmed by a call, the company attaches documents, and a person makes the decision. One user can have no more than three unverified companies, so that other people's taxpayer IDs can't be grabbed in bulk. We verify a buyer only after the seller has confirmed that this is their customer. Otherwise the manual checks get spent on people who dropped by to look around.
Manual verification is slow, and we know it: at night and on weekends a company waits. An automatic check against the register is faster, but all it confirms is that the legal entity exists. The register doesn't know who is sitting at the keyboard.
What you can't see on the screen
Most of the time went into situations that take up one line in a task description. A manager clicked "confirm order" twice. A company was submitted for verification from two tabs at once. A seller accepted a quote request and the buyer canceled it in the same second. Every change to an order, an invoice or a subscription first locks the record for the length of the operation and reads it again. The second request waits and sees the new state.
Speed took separate thought. Visitors get the pages of open catalogs from copies assembled in advance, so a rush of traffic puts no load on the database. That doesn't work for closed catalogs: a page that only the seller's own buyer should see has no business ending up in a shared copy. A mistake here looks like prices leaking to competitors.
Over the month the project collected about a thousand automated checks, and they run before every release. Even so, the first pass through the scenarios in a browser, with buttons clicked the way a user clicks them, turned up 56 issues.
Where to start the conversation about a marketplace
None of these decisions is about screens. They're all about money, access and responsibility, and they belong to the business owner; the developer only carries them out. Changing them is expensive. Dropping the shared catalog on day fifteen set off six rebuilds in a row, from categories to pricing plans. With live sellers and their buyers, a turn like that can no longer be made without losses.
So before listing pages, answer five questions in writing:
- Who pays the marketplace, and for what exactly.
- Who sees whom: are products and prices open to outsiders.
- How the price for a particular customer is worked out.
- Who confirms that a participant is real, and how.
- What happens to the data of a participant who has stopped paying.
If there's one supplier with customers of their own, no marketplace is needed at all: a closed portal will do. We covered what goes into a portal like that and where the timelines come from in a separate article.
The good news is that all five answers fit on one page and don't require a single developer. We spent less time on them than on any of the rebuilds that happened because an answer was missing. Once that page is written, things get noticeably easier: it's clear what to do first, what to drop, and how long it will take. The marketplace stops being a big, vague undertaking and becomes an ordinary project with a beginning and an end.
