Case study · B2B dental wholesaler
A wholesaler that sells burs
by code, by shape and by procedure
DrillStom is the exclusive Polish importer of MDT diamond burs and sells only to dental practices and clinics. We built the store from scratch on Medusa: a technical catalog, a variant matrix instead of dropdowns, sales by the pack, company accounts and document issuing. The store runs at drillstom.pl, so every screen on this page can be opened and checked.
- B2B
- Medical devices
- Medusa
- ERP integration
- Technical catalog
From first commit to a working store
3 months
Catalog categories
35
Product pages in the sitemap
177
Variants of one shape on a single screen
25
Starting point
A technical catalog no store template knows how to handle
A dental bur is not a product in the sense a typical online store understands. One shape means a code from a printed catalog, five grit grades, five diameters, three handpiece types and a pack of five. The buyer knows the code, because it is printed on the box, and wants several variants at once. A standard product page with dropdowns asks them to walk through the same form twenty-five times.
The problem
Sales worked, but entirely offline. Orders arrived by phone and e-mail, prices came from the manufacturer PDF, and every code was retyped by hand onto the invoice. At a dozen lines per order that is not an inconvenience, it is a job.
- Buyers know the code from the box, 368 or 801, not the commercial name. A store search over names does not help them.
- One shape exists in 25 variants: 5 grit grades across 5 diameters. Dropdowns turn a single order into 25 separate decisions.
- Burs ship five to a pack, while some competitors quote per piece. Without the per-unit figure alongside, the offer looks more expensive than it is.
- These are medical devices. Sales are permitted only to practices and clinics, so the store has to verify who is ordering.
- Invoices and shipping labels were produced by hand after each order, retyping codes and company details.
- The manufacturer catalog has its own structure, organised by handpiece and shape. Buyers think in that structure, not in categories invented by an agency.
The goal
Not "to have a store", but to move online the ordering pattern that already worked on the phone, and to take the manual part of the work off the desk. We set the goal in the Blueprint, before the first line of code, in five sentences that could be checked after launch.
- A buyer finds a bur three ways: by code, by shape, or for one specific procedure.
- A whole order for one shape, up to twenty-five variants, is built on a single screen.
- The price is visible without logging in, gross per pack, with a per-unit figure alongside.
- Invoices and shipments come out of the order automatically, with no retyped codes.
- The client team extends the catalog without raising a ticket with a developer.
How we answered it
Rather than fit the trade to a template, we moved the logic of the printed MDT catalog into the data model. That single decision drives almost everything else: the category structure, the shape of the product page and the variant matrix.
01
Blueprint: the data model before the interface
First we broke the manufacturer catalog into axes: ISO 6360 code, head shape, grit grade with its micron range, diameter, working-part length, handpiece type. Only then did the Medusa product model follow. Our first category structure rested on two axes and proved wrong; we rebuilt it as thirty-five categories in the structure the client actually uses.
02
Three entrances to the catalog instead of one menu
Search accepts a code, a shape name and a grit grade. Two separate routes sit beside it: browse by shape, and choose by procedure. Filters on handpiece, shape and grit narrow the result without leaving the list, and a count beside each option shows how many products will remain.
03
A variant matrix in place of dropdowns
A component that mirrors the table in the printed catalog: rows are grit grades, columns are diameters, and a cell is one variant with its availability and pack count. We describe it separately below, because it is the strongest part of this build.
04
The pack as the unit of trade
Price, cart, invoice and shipping label all count packs rather than pieces. The per-unit figure sits alongside, so a buyer can compare against competitors who count differently. That is a rule in the pricing model, not a note in the description.
05
A professional gate
With medical devices the store has to establish who is on the other side. Verification sits before the purchase, not before the catalog: prices are visible immediately, because hiding them behind a login also shuts out search engines and language models.
06
Integrations that clear the desk
The invoicing system receives the order with line items, codes and company details. The carrier receives the shipment. Both work from the same order data, so there is no point at which a person retypes code 368 from a screen onto paper.
Catalog
Three routes to the same bur
A buyer in a practice is not looking for "a tapered bur". They are looking for the code they know from the box, the shape they can picture, or a bur for one specific procedure. The catalog serves all three entry points at once. The thirty-five categories follow the structure the client actually uses, rather than the two-axis version we started with. The whole catalog is open without a login, so all 228 sitemap URLs can be indexed by Google and fetched by language models.
What sets this build apart
The variant matrix: twenty-five decisions
collapsed into one screen
This is a component built for the trade, not a feature off the shelf. The audience has been ordering from a printed manufacturer table for decades and thinks in its layout: grit in rows, diameter in columns, a specific bur at the intersection. We reproduced that table inside the store, with availability and pack count in the cell. A buyer sees all twenty-five variants of one shape at once and selects several without leaving the screen.
Rows and columns from the catalog, not the admin
Rows are the grit grades a given product actually has, with the ISO 6360 code and the micron range: K0 is 20 to 38 µm, K5 is 152 to 181 µm. Columns are the diameters that exist for this shape. The matrix never shows a variant the product does not have, so there are no empty intersections to guess at.
A silhouette in true proportions
Above each column sits a drawing of the bur that keeps the real ratio of diameter to working-part length. The difference between ⌀014 and ⌀023 becomes visible rather than merely written down. A separate row underneath carries the working-part length, because that is the second figure that settles a purchase.
Grit colour matching the ring on the bur
Each grit grade has a colour, the same one the manufacturer puts on the ring of the shank. Buyers recognise it from the box. We checked the background and text pairing in a selected cell against WCAG AA, because colour here carries information rather than decoration.
Availability in the cell, not after a click
Every cell carries a stock dot. Missing variants are visible immediately, so a buyer does not assemble an order that falls apart in the cart. Where a variant is out, a back-in-stock notification takes over.
Pack count directly in the cell
Once selected, a cell becomes a minus, number, plus counter. The value is packs rather than pieces, with a reminder that one pack is five. A twelve-line order is built in twelve clicks inside one table.
A matrix-or-list switch
Not everyone wants a table, so a classic variant list sits beside it. It is one switch on the product page over shared data underneath, so neither view is a separate implementation to maintain.
This one component answers the question of why build on Medusa at all rather than rent a template. A matrix cannot be produced by configuration. It needs access to the variant model and to the product page, and that is exactly the boundary where closed platforms end.
Product page and categories
The technical data that settles the purchase
In this trade a product page is a document rather than marketing copy. The code, the ISO 6360 designation, the brand, the pack size and the working-part length sit in the header, because the decision rests on them. The price is gross per pack with a per-unit figure alongside, and a returning customer sees a note about individual terms without having to log in.
01
A header that answers before the scroll
Code 368, ISO 6360 257, brand MDT, pack of 5. Four figures on one line under the title, ahead of the photo and ahead of the description. The gross price per pack sits above the gallery, because in wholesale that is the content of the page. The panel on individual terms states plainly that prices are visible without a login, and that regular customers may have their own.
02
Categories in the manufacturer structure
Diamond burs for turbine handpieces run to fifty-eight products, so the category has to filter rather than merely list. Tabs across the top follow handpiece type, the left panel follows shape and grit, and a count beside each option shows how many products remain once it is on. Grid cards carry photographs of real burs rather than renders, because in this trade the ring on the shank is information.
Stack
- Medusa 2.8.4
- Next.js 15
- PostgreSQL
- Fakturownia
- Apaczka
- Railway
Terms
The basis this was built on
Not a methodology slide, but the four agreements that actually shaped the project. We apply each of them the same way on later builds, so this is the closest thing to an answer to "what is it like to work with you".
- Delivery time
- 3 months
- From first commit to a store taking orders. Without a staging environment, which we say plainly below.
- Billing model
- fixed scope
- Scope closed in the Blueprint, before code. Anything beyond it goes as separate work, so the project does not swell mid-flight.
- The quote
- before the start
- One fixed figure for a closed scope, known before the first line of code rather than discovered afterwards from hours worked.
- Care after launch
- a separate agreement
- Maintenance, security updates and catalog development signed after launch, not forced as a condition of the build.
We do not publish this build’s budget. That is the client’s information rather than ours, and we do not put it out without a reason, even where it would look good in a case study. Our own range for comparable scope sits openly in our pricing, so the scale can be checked without looking at somebody else’s invoice.
State after launch
What stands in the store, and what we deliberately leave out
The store is live and still being developed. September 2026 alone brought changes to the checkout, the delivery price list and the structured data for search engines. The figures below describe scope and working method, not a sales result.
228
URLs in the sitemap
The whole catalog is indexable: 177 product pages and 35 categories. Nothing sits behind a login.
25
variants on one screen
Five grit grades across five diameters in one table, instead of twenty-five passes through dropdowns.
0
codes retyped by hand
Invoicing and the carrier receive the order with line items and company details straight from the store.
212
changes shipped via pull requests
Every change through a branch and a review, never a file dropped onto production.
What this case does not say
We publish no revenue, conversion, order count or before-and-after comparison. We do not hold that data and will not estimate it. We publish what we know from our own invoice, not what we would know from their P&L. The second thing worth saying plainly: the project has no automated tests and no staging environment yet, so a regression in discount or delivery logic is caught today by a person rather than a gate in CI. That is the first item on the work list, because in a B2B store the most expensive bug is the silent one.
FAQ
Questions we get after this case study
What does a B2B store on Medusa cost?
We do not publish the DrillStom budget, because that is the client’s information. Our own range is open: builds from PLN 60,000 net, typically PLN 80,000 to 200,000. Three things drive the price: the number of markets and currencies, the number of systems on the other side of an integration, and whether pricing depends on the customer. The number of products matters least. The whole pricing model sits in our pricing, and we break the bill down in what an eCommerce build costs.
How long does it take to build a wholesale store from scratch?
Three months here, from first commit to a store taking orders. The main things that stretch it are integrations with systems we do not control and product data that needs cleaning up. Migrating off an existing platform such as Shoper or IdoSell runs closer to thirty days, because the catalog and the customers already exist.
Is Medusa suitable for selling medical devices?
Yes, and that is one reason we chose it. Selling medical devices requires buyer verification before purchase, and that is logic you cannot add by configuration on a closed platform. In DrillStom verification sits before the purchase but not before the catalog: prices are visible without a login, because hiding them also shuts out search engines and language models.
How do you sell in packs rather than single pieces?
The pack has to be the unit of trade in the pricing model, not a note in the description. Then price, cart, invoice and shipping label all count the same thing. The per-unit figure sits alongside, because some competitors quote per piece and without it the offer looks more expensive than it is. In DrillStom one pack is five pieces, and that appears beside the price and in every matrix cell.
What is a variant matrix and when is it worth building?
A table in which rows and columns are two axes of the variant, and a cell is one product with its availability and pack count. It pays off when customers order many variants of one shape at once and already know them from a printed manufacturer table. Beyond burs, that is how people order profiles, bearings, seals, fasteners and much of the building trade. If a customer orders one variant, a matrix only gets in the way.
Can a store like this be extended without a developer?
The catalog, yes: products, categories, descriptions, photos, prices and availability live in the Medusa admin and the client team runs them. Logic, meaning pricing rules, integrations and components such as the matrix, needs a developer, because that is code rather than a setting. We draw that line in every Blueprint, so nobody is disappointed after launch.
Can a store like this be migrated off Shoper or IdoSell?
Yes, and that is our typical migration project, at around thirty days. We move the catalog, the customers, the URLs with redirects and the order history, and only then add what the old platform could not do. We compared both platforms and what actually blocks work in Shoper or IdoSell, and all our comparisons sit in the platform comparison hub.
How do the invoicing and shipping integrations work?
An order from the store reaches the invoicing system with line items, codes and company details, and the shipment reaches the carrier. Both integrations work from the same order data, so there is no point at which a person retypes a code from a screen. We use the same pattern with other accounting systems and carriers; it is described on the B2B platforms service page.
A similar catalog, a similar problem?
If you sell technical products in many variants, in bulk packs, or to buyers who have to be verified, this is exactly the conversation we have most often. We start with a Blueprint: scope, budget, and the line between what your team will run and what stays code.
