NineLabNineLab.ru
CasesPrices
Contacts
August 13, 2026Evgeny · Senior Systems Engineer

B2B customer cabinet MVP: 7 screens partners actually open


“We’ll build a customer cabinet — partners will order themselves.” Six months later Figma has 30 screens, production has a pretty dashboard, and dealers still ping WhatsApp: “Do you have SKU X, and when does it ship?” The failure is not design. The MVP tried to ship a dream portal instead of the seven screens people actually open.

Below is a frame for CEOs and sales leaders: the B2B customer cabinet MVP, what to defer, budget/timeline ranges, and an acceptance checklist before you pay the vendor.

B2B customer cabinet MVP: seven screens for dealers and buyers

The cabinet pays off when a repeat order needs no sales call

Why a cabinet if you have managers and Excel

Managers do not scale: 50 active dealers × “in stock?” × “send the invoice” burns hours and breaks prices. Excel fails on versions and access control. A cabinet exists so self-service covers 60–80% of routine requests: repeat order, status, document.

If pain already lives in sheets and chats, see when Excel no longer works. Here the focus is the MVP composition for external clients.

Seven MVP screens

B2B customer cabinet MVP map: seven screens from login to support

From login to a repeat order — without an admin dream

  1. Login and roles. Auth, password reset, at least two roles: “can order” and “view only.” A dealer sees their price list and documents — not someone else’s.
  2. Catalog / stock. Search, filters, stock as “yes / low / no” or quantity with an agreed lag. Without stock the cabinet becomes a brochure plus a phone call.
  3. Cart and order. Qty, line comments, credit limit or minimum order if that is a business rule. “Reorder last” saves half the clicks.
  4. Order status. List and detail: accepted → packing → shipped → closed. ERP number if you have one. Without status, sales becomes a call center again.
  5. Documents. Invoices, delivery notes, acts, specs — PDF from the cabinet. The partner’s accounting should not wait for “see attachment.”
  6. Price and terms. Current (or personal) price list, payment terms, ship-to, account manager contacts. One screen of truth instead of “latest file in chat.”
  7. Support. Ticket or form: topic, order, reply status. Not necessarily WhatsApp-inside — a tracked “received / in progress / closed” is enough.

That is the MVP. Anything that does not help login → order → download a document belongs in the backlog.

Defer to v2 on purpose

B2B cabinet MVP scope versus features deferred to version two

Self-serve orders first — marketplace polish later

  • AI recommendations, personal storefronts, heavy BI.
  • Native mobile apps (responsive / PWA often enough).
  • Full messenger inside the cabinet.
  • White-label for a distributor network and heavy multi-tenancy.
  • Full two-way ERP sync “like a mini-ERP” in sprint one — often enough: stock and status from accounting, order into accounting or to a manager via an agreed channel.

Timeline and money (ranges)

B2B cabinet MVP (7 screens) — roughly 1.2–3M RUB, 8–12 weeks with product + backend + frontend and 1–2 exchange contours with ERP.

Cost jumps not from “one more button,” but from personal prices, credit limits, strict stock SLA, and two-way master-data sync in release one.

Payback is simple: manager hours per month on “in stock?”, “send invoice”, “where is my order?” × loaded cost. If the cabinet removes half of that, payback is often quarters, not years.

Common estimate mistakes

  • “Design the whole portal first” — 40 mockups, zero working order. Start with one end-to-end path on seven screens.
  • “Catalog like a marketplace” — B2B needs stock, units, pack size, personal price — not an endless recommendation feed.
  • “ERP integration later” — without stock and status nobody trusts the cabinet; lock exchange in Discovery.
  • “One role for everyone” — partner accounting sees competitor buy prices, or the buyer cannot place an order.
  • “Native app in the MVP” — separate contract; first prove the same seven screens work on a phone browser.

Acceptance checklist

Acceptance checklist for a B2B customer cabinet MVP

Accept scenarios, not slides

  • Dealer logs in and sees only their price list and orders.
  • Order gets an ERP number or an agreed “accepted by sales” status.
  • Shipment status updates without a phone call (at least within the sync window).
  • Invoice / delivery note downloads from the cabinet.
  • Stock is not wrong longer than the agreed window (hour / day — write it down).
  • Roles exist for view-only and ordering.
  • A typical reorder works on a phone.
  • Admin can revoke a departed partner user’s access in minutes, not days.

Bottom line

A B2B customer cabinet pays off by section count only if dealers and buyers complete order and document flows themselves. The seven screens above are a working MVP. Add the rest after WhatsApp stops being the primary order system.

Need a scenario review or an MVP for a dealer network — send a request. Services: web applications, corporate / partner portal.

Executive FAQ — B2B customer cabinet MVP

The smallest set of screens that lets a dealer or buyer place a repeat order, see status, and download documents without calling a sales manager for every step. Not a 40-section portal — a working path: login → catalog → order → status → documents.

Seven: login and roles, catalog with stock, cart and checkout, order status, documents (invoices, delivery notes), price list and contract terms, and support tickets. Analytics, AI, native apps, and full chat usually belong in v2.

Typical SMB range: roughly $15k–$35k equivalent (about 1.2–3M RUB) and 8–12 weeks with a clear scope and 1–2 integrations (often stock and status from ERP/1C). Cheaper for a simple catalog and one-way sync; more for per-partner prices, credit limits, and full two-way ERP exchange in release one.

Intranet is for employees: news, wiki, approvals. A B2B cabinet is the external layer for partners and buyers: price, order, documents. They can share a platform, but MVP and roles differ — clients need stock, status, and closing docs, not a corporate feed.

Write one “dealer repeat order” path from login to a downloaded invoice. Name the source of stock and status (ERP / warehouse / manual). If that path still needs a manager, you do not have an MVP yet. Spec the seven screens and acceptance criteria — not a marketplace feature list.

Want to apply this in practice?

Tell us about your system — we’ll propose a work plan and the metrics worth fixing in an SLA/SLO.

All posts: High-Load

High-LoadJuly 7, 2026
White-label SCADA for integrators: go to market in weeks, not years

Why system integrators choose ready cloud SCADA over building from scratch: Modbus → MQTT, live monitoring, alarms, white-label branding, pilot in 2–4 weeks.

Read Article
High-LoadJune 19, 2026
Golang for High-Load: When Go Is the Right Backend Choice

Go for high-load backends: goroutines, gRPC, Kafka, when to choose Golang over Python/Node, and how to avoid architectural mistakes from day one.

Read Article
High-LoadJune 17, 2026
15,000 Concurrent Connections on Next.js SSR: Judo Battle Case Without 503

How a heavy Next.js + Strapi portal handled 15,000 concurrent connections: three-node architecture, Varnish, PM2 cluster, stress test results, and a peak checklist.

Read Article
High-LoadJune 7, 2026
Industrial IoT: Why Your Sensor Pilot Never Reaches Production

Typical industrial IoT failures: from demo gadgets to 1000+ sensors. Downtime math, MQTT/edge/cloud architecture, and a checklist before you scale the pilot.

Read Article