ImpregnatyBC: a store that matches a sealer to the surface and sells to companies at trade prices.
We designed and built a Medusa.js store for a seller of sealers and cleaners for paving, concrete, stone and facades. A customer starts from their surface or problem, not from a chemical name. They work out coverage on the product page, and a company buys on a trade account with net prices and volume tiers applied by the cart.
Figures come from the public store as of 22 October 2026. We do not publish sales results, because we did not measure them.

Construction chemicals are sold by product name, and the buyer only knows their paving.
Starting point
ImpregnatyBC sells sealers and cleaners from CTS Chemistry, Eksil and Guard Industry. The products are called HK-2, SK-2 or EC-87 and differ by base, finish and coverage. The buyer knows something else: a block-paved driveway that darkens after rain, or a facade with green growth.
The second group of customers are paving contractors, stonemasons, facade companies and wholesalers. They buy regularly and in volume, need net prices to quote a job, and want several people from one company ordering on one account.
That gave the project three challenges.
- product selection by surface and problem, with no need to know chemical names
- an answer to "how much do I need" on every product with a published coverage rate
- a trade account with wholesale prices and volume tiers that does not block the first purchase
Pick a surface or a problem, and the store shows only the products that fit.
Challenge 1: selection
The catalog is organised by substrate: block paving, concrete and floors, natural stone, and facades and roofs. The second entry point is the symptom: soaks up and darkens, lime efflorescence, moss and green growth, grease and oil. Both lead to the same product list, narrowed to what makes sense on that surface.
On the list, customers filter by pack size, base, finish, function, brand, coverage and price tier. Every price shows a per-litre figure next to it, and products with a published coverage rate also show an approximate price per square metre, so comparing a 1 l and a 5 l pack needs no mental arithmetic.
Surface and problem pages carry their own content: what to choose, when to seal, what a sealer will not fix. On top of that, 24 guides are linked to products. A stone product never appears among the suggestions for paving, so mistakes are hard to make.
A calculator on the product page turns square metres into litres and packs.
Challenge 2: quantity
The most common question before buying a sealer is how much to buy. The answer depends on the product's coverage, the number of coats and how absorbent the surface is, so the store works it out on every product with a published coverage rate.
The customer enters the area, picks the number of coats and the absorbency. The calculator shows the litres needed, splits them into packs with prices, shows the surplus over the requirement and the total. One button adds the whole set to the cart.
Coverage, protection periods and safety data come from the manufacturer's documents and appear as parameters, not slogans. A product without a published coverage rate has no calculator; instead it shows the application rule and an invitation to ask.
The trade account works from sign-up, and wholesale prices switch on after approval.
Challenge 3: the trade account
A typical B2B store makes a company wait for verification. Here the application creates the account at once: the company buys at list prices from the first minute, and after approval sees wholesale prices on products and in the cart. A rejected application takes nothing away; the account stays as a retail account with the same login.
In the form the company enters its tax ID, and the store pulls the name and address from the Polish business register. It also asks for the type of business, the surfaces the company works with and estimated annual usage, which is what the seller needs to decide on terms.
Volume tiers are calculated separately for each variant and apply in the cart automatically once the order reaches the quantity. Next to every gross price the company sees the net amount. Employees are invited by email, order history is shared across the company, and an order can be repeated in one click.
| Quantity | Net price per pack | Discount |
|---|---|---|
| 1-5 packs | 248.00 zł | none |
| 6-11 packs | 235.60 zł | 5% |
| 12-23 packs | 218.24 zł | 12% |
| 24 packs and more | 210.80 zł | 15% |
Reviews only from buyers, and preparation products before the customer buys a sealer.
Trust
Every review is tied to an order, so only people who bought that product in this store can write one. Medusa has no such module out of the box; we described separately what we built on top.
The product page ends with a "Prepare the surface first" section: an efflorescence or grease cleaner next to the sealer, because a sealer applied over dirt locks in whatever it finds. It sells, and it protects the customer from a bad purchase at the same time.
Medusa.js underneath, Next.js on top, Payload for content.
Platform
Medusa.js runs the commerce layer: products and variants, price lists for customer groups, the cart, orders and company accounts. The storefront was built in Next.js, so selection by surface, the calculator and the way prices are shown are not limited by a template.
Guides, problem pages and surface content live in Payload CMS and connect to the catalog, so the store team edits them without a developer. The store runs in Polish and English, with separate addresses for each version. Delivery by courier or InPost parcel locker, returns within 14 days.
One team from catalog structure to the trade account.
Scope and accountability
Evelumo was responsible for the design and implementation of the whole store. The catalog structure, the calculator, the wholesale pricing logic and the content were built as one product, not as a separate frontend and separate store logic.
Everything described here can be checked in the public store. It does not by itself prove sales growth or the number of trade accounts, which is why you will not find such numbers here.
- catalog by surface and problem, filters, search, price per litre and per square metre
- product pages with variants, technical tabs and a coverage calculator
- trade account: data from the business register, wholesale approval, net prices, volume tiers per variant, team members and order repeat
- a product reviews module tied to orders
- guides and problem pages in Payload CMS, two language versions
Questions about the ImpregnatyBC project
What was built for the ImpregnatyBC store?
Evelumo designed and built a store on Medusa.js with a Next.js storefront and content in Payload CMS. The scope covers a catalog of 70 products organised by surface and problem, filters and prices per litre and per square metre, a coverage calculator on the product page, a trade account with data from the business register, net prices and volume tiers, a reviews module tied to orders, and 24 guides. The store runs in Polish and English.
How does the trade account in the ImpregnatyBC store work?
The application creates the account at once and the company buys at list prices without waiting for verification. After the seller approves it, products and the cart show wholesale prices, volume tiers calculated separately for each variant and net amounts next to gross. The company invites employees to a shared account, sees shared order history and repeats orders in one click.
Why Medusa.js rather than an off-the-shelf platform?
Because this store's logic goes beyond the standard: two ways into the catalog, a coverage calculator tied to product coverage rates, a trade account active from sign-up with later wholesale approval, and volume tiers per variant. On an off-the-shelf platform some of this would need workarounds or paid add-ons. If your store sells in a standard way, we will tell you plainly that SaaS is enough.
Does the ImpregnatyBC case study demonstrate sales growth?
No. We did not measure impact on sales, conversion or the number of trade accounts, and we do not publish numbers we cannot prove. The case study shows what you can check yourself in the public store: the size of the catalog, the implemented features and the way a customer is led to a product.
Do you sell products a customer has to match first, and to companies at different prices?
Show us how a customer reaches the right product today and how companies buy. We will assess whether you need a new store, an extension of the current one or an off-the-shelf solution.








