Charging by width and height, or by the square metre

Shopify prices a variant. A measurement is not a variant. Blue, Large and 1 240 mm by 1 600 mm are three different kinds of thing, and only the first two fit in the box Shopify gives you. Stores that sell blinds, glass, worktops, banners, decking, mesh and signage all arrive at the same wall: the price the customer should pay does not exist anywhere in the product record, because it is calculated from something the customer has not typed yet.

This one is solved, and cheaply. The honest version of this page names the apps first.

The apps that do the calculation

Three that state a price on their listing:

Each puts width and height fields on the product page, multiplies them by a rate you set, and shows the customer a price before they add to the basket.

Test all three with the same awkward order before you settle. The calculation is the easy half.

The question their listings do not answer

A calculator has worked out that the customer owes $184.60. It now has to get that number to the checkout, and Shopify gives an app four ways to do it. Five of the six listings we read do not say which one they use. The choice is invisible while you are shopping for an app and permanent once you have one, because it decides what your own reports say for as long as you keep the data.

As the real price of the line. What you would assume. It needs Cart Transform, which is the section below, and only one of the six listings we read names it.

As a discount. The product is listed at a high round figure and the app subtracts the difference. The customer pays the right amount. But your discount reports then contain your ordinary trade, every order carries a discount it did not really get, and any genuine promotion you run afterwards is mixed in with it. If you ever want to answer "what did we actually discount last year", the answer is gone.

As a hidden variant. The app creates a variant at the calculated price and hides it. This works until the variants pile up. They leak into collections, into your product feed and into Google Shopping, and clearing them out has its own trap — "cleaning up old variants can break abandoned carts that referenced them". A store selling made-to-measure blinds can produce thousands in a season.

As a draft order. The customer asks, you send an invoice. Correct in every way except that it is no longer a store: nothing is bought at two in the morning.

Ask the vendor which of the four it is, in those words, before you subscribe. It is a fair question and a straight answer takes one line.

Not sure how your calculator's price reaches the checkout? Describe what you sell →

Cart Transform, and the plan rule everybody states wrongly

The tool that sets a genuine line price is Cart Transform. Its plan restriction is real, and it is per operation rather than across the whole thing — which matters, because the flat version of the rule has closed this door for people who did not need it closed.

• lineUpdate is the Plus one. Shopify's documentation: "Only development stores or stores on a Shopify Plus plan can use apps with lineUpdate operations." A Shopify staff member added in July 2026 that the kind of app makes no difference — "only Shopify plus stores can use this, regardless of being a public/custom app."
• lineExpand is not on that list, and it takes a fixed price per unit. A Shopify staff member, July 2025: "Cart transforms CAN be used for all Shopify plans. Specifically, the update cartTransform operation can only be used by Shopify Plus stores."

Read that as an absence rather than a permission. Shopify does not say a store below Plus may set a line price with lineExpand; it only never says it may not. One developer reported it working on a development store in February 2026, and nobody has published a test on a live store below Plus. Apippa's listing says it needs no Plus and names lineExpand as its mechanism — its own blog and its own support page then disagree with each other, so treat that as what the listing claims.

And there is a second plan rule underneath, which applies whichever operation an app uses. Cart Transform is a Shopify function, and Shopify's line on functions is about how the function reaches your store rather than about what it does: "stores on any plan can use public apps that are distributed through the Shopify App Store and contain functions", while "only stores on a Shopify Plus plan can use custom apps that contain Shopify Function APIs." So an app from the App Store is available to you; something built for your store alone is not, below Plus. That matters here because "have somebody build me one" is the obvious next thought after reading the section above.

If this decides whether an app is any use to you, say so to the vendor and ask them to confirm it against your plan. It is the one thing on this page worth a written answer.

Blinds are not a formula

Every calculator app assumes your price is width times height times a rate. The blind trade does not price that way. It prices from a matrix — a grid of width bands down one side, drop bands across the top, a figure in each cell, a separate grid per fabric. The figures are not a curve anybody can fit, because they come from how the fabric is cut and what the mechanism costs, and a 1 200 mm blind at 2 400 mm drop is not twice a 1 200 by 1 200.

Most of the cheap calculators cannot express a grid at all. Some let you upload a table, and that is the feature to look for if this is your trade. If you have been given a formula that is close to your price list, check the corners of the grid before you trust it, because that is where a formula and a matrix disagree most.

If you sell by the metre, this is the wrong page

Cutting to length is a different problem with a different answer, and it has its own page: selling in decimal quantities and cutting to length. It covers fabric by the metre, why 2.5 m reaches the till as a quantity of 25, what variant-per-length does to your catalogue, how shared stock oversells, and what the temporary-SKU apps do to your reporting.

What Shopivibe does here

Pricing by size is a problem we solve. You describe the rule the way your trade actually states it — "price from the width and drop grid for this fabric, round up to the next band, add the motorised surcharge over 2 400 mm" — and it is built for your store and kept working, including the part the calculators skip: the price the customer pays reaching the order as the price of the line, so your reports read the way your invoices do.

A matrix is the case to say out loud when you describe it, because it is the one most of the apps above cannot express. So is a formula with exceptions, a different grid per fabric, a minimum charge, and a surcharge that only applies past a size.

And the rule does not stop at the price. A made-to-measure order usually needs something to happen to it afterwards — tagged for the workshop, held until the measurements are checked, routed to whoever cuts that fabric, costed against the offcut. That is the same rule, described in the same conversation.

If your pricing really is just width times height times a rate, one of the apps above is cheaper than anything bespoke and you should use it. Ask it the four-ways question first, and check the corners of your grid.

Shopivibe solves the problem in your store and keeps what it adds maintained, including when Shopify changes something underneath. If the app cannot complete your request on the spot, somebody at Shopivibe takes it on straight away and has it working in your store within 24 hours, included in the plan at no extra charge. Shopivibe is free during early access, with 3,500 credits included. Credits beyond the included 3,500 cost $0.06 each.

Selling something that is priced by its size? Describe it in your own words →