CMS-Based Wood Pricing Calculator - Website Redesign for a Building Materials Depot

Who is the customer?

Bielińscy Drewno is a lumber yard in Mirotki, in the municipality of Skórcz, located at the Kopytkowo exit off the A1 highway. It has been in operation since 2013, handles over a thousand deliveries a year, and delivers materials using its own fleet. It sells lumber, roof trusses, pressure-treated boards, and structural square-edged lumber—ranging from a single gazebo to a complete roof truss.

This is a company with a good product, a good location, and excellent reviews, but its bottleneck was the way customers found out about pricing.

What problem needed to be solved?

The sale of lumber is based on pricing, and pricing depends on three variables: the type of material, its dimensions, and the quantity. Every inquiry meant a phone call or an email, and on the other end was someone who had to calculate the volume and provide a price.

This works as long as there are only a few inquiries a day. With a thousand deliveries a year, there are many more inquiries than orders—because most people call to compare prices, not to buy. So the owner ends up providing quotes mainly to those who will buy elsewhere anyway.

On top of that, there’s a problem that isn’t visible from within the company: a customer who just wants to get a rough idea of the cost often won’t call at all. In the evening, with a project on the table, there’s no way to check whether this order fits within the budget. Not listing prices on the website doesn’t mean fewer questions—it means fewer customers.

What did we do?

Three things that make up a single solution.

1. We redesigned the website. The entire site was rebuilt from scratch: the homepage, the product catalog, eight separate product pages, a blog, and a contact page with an inquiry form organized by topic (quotes, roof trusses, shipping, consulting, and returns).
2. We integrated Strapi as the CMS. Content and product data are stored in a headless CMS, not in the code. This means the warehouse owner can update product descriptions and prices on their own, without having to call us or wait for a deployment.
3. We built a pricing calculator that uses data from the CMS. The customer selects a type of wood from a list of eight categories, enters the dimensions and quantity, adds items to the cart, and sees the total order value. The numbers come from the same price list that the owner edits in Strapi—so the calculator can’t drift out of sync with reality, because there’s no separate source of truth.

That last sentence is the crux of the entire project. A pricing calculator whose prices must be updated manually in a separate system ceases to be accurate within a month and then does more harm than good. That’s why the calculator and the CMS weren’t two separate tasks, but one.

Why a headless CMS instead of regular WordPress?

This is our opinion, based on how this project was built.

A lumber price list is data, not content. The same price for a square-edged board must appear on the product page, in the calculator, and in the shopping cart summary. In a classic content management system, that means three places to update—and three opportunities for error. In a headless CMS, it’s a single field used by all three views.

Second point: the warehouse owner should be changing prices, not learning how to use the admin panel. The fewer things they see in the editor, the greater the chance that they’ll actually update the price list—and an outdated price list on the website is worse than having no price list at all.

What does this mean for the client?

The buyer gets a price when they need it—that is, when working on a project—rather than during office hours. The print shop stops providing quotes over the phone for inquiries that will never turn into orders, and those that do turn into orders already come with a calculated price.

The company itself described this on its website as one of its four service steps: “instant quote.” The calculator is the technical fulfillment of a promise they were already making anyway.

Who does this model work for?

For companies that sell products that can be quantified according to fixed rules: building materials, custom-cut components, and services billed by the meter, piece, or hour. There’s one condition—the price must be calculable using a formula, rather than resulting from negotiations for each order.

It doesn’t work in situations where each quote is unique and depends on context that the calculator doesn’t know. In such cases, the calculator promises precision it can’t deliver, and you end up having to explain to the customer why the invoice doesn’t match what the website showed.