Picture the part of the week no one budgets for. A supplier sends a notice that costs are going up next month. A new tariff lands on a whole category. The accountant points out that a chunk of the catalog is selling below the margin you need. And then a person, often the owner, sits down with the Shopify admin open and starts changing prices one product at a time: filter to a group, open the bulk editor, read the current price, do the math in their head or a calculator, type the new number, tab to the next row, and do it again. Fifty rows later the page ends and they load the next fifty. It is not hard. That is exactly why it is so corrosive. It is easy, repetitive, and error-prone, and it scales with the size of your catalog.

This is one of the most common operational complaints in the merchant forums, and it almost always sounds the same. Someone needs to raise every price by a set percentage, or add a fixed amount, or push a vendor's products up to protect margin, and they want to know how to do it in bulk without retyping hundreds of numbers. The replies point at a bulk editor that has no formula, a CSV export you edit in a spreadsheet and import back, or a paid app built only to do this one thing. The merchant is not asking for anything exotic. They want the obvious thing a store with more than a handful of products needs: change these prices, by this rule, all at once, and round them the way I always round. The platform that runs the whole store leaves that to a human with a calculator.

Shopify will store a price on every variant all day long. It just will not do the math to change them all at once.

Why repricing by hand is a tax that scales with your catalog

Changing one price takes maybe twenty seconds. The damage is not in any single one, it is in the multiplication and in what those seconds crowd out. At three hundred products, often with several variants each, a single across-the-board change is hours of pure arithmetic and typing, done in batches of fifty, and it is the kind of work that gets put off until it is urgent and then done in a hurry. Hurry is where the real cost lives. A percentage gets miscalculated on one line. A digit gets transposed, so a forty dollar product goes out at four dollars. A variant gets missed, so the small is repriced and the large is not. The compare-at price gets left where it was, so a price you just raised now shows as if it were a discount.

Every one of those small slips lands downstream as something bigger. A price typed too low is real margin given away on every unit until someone notices, and on a popular SKU that can be a lot of orders. A price typed too high quietly kills conversion on a product that was selling fine. A half-finished reprice, where some variants moved and some did not, means customers see the same item at two logics depending on the option they pick. And because the storefront shows whatever is in the field the moment you save it, a mistake in the price box is a mistake shown to every shopper with your name on it. The manual step is not just slow. It is the most financially direct error you can make in the admin, because it is the number people pay you.

What Shopify actually does, and where it stops

Shopify is glad to store and display prices. Every variant has a price, a compare-at price, and a cost field, and the storefront renders them instantly. What it does not do is change a lot of them by a rule. The gap shows up in three places merchants hit quickly.

First, the bulk editor has no math. From the Products page you can select items and open a bulk editor that puts the price field in a grid, which feels like progress until you realize it only lets you type values. There is no "increase by ten percent," no "add two dollars," no "round everything to end in .99." You still compute each new price yourself and type it in. It shows a page of products at a time, commonly fifty, so a real catalog means working through it batch after batch. And it does not expose variant prices in the same view as the parent, so a store with sizes or colors edits each variant on its own.

Second, the CSV and the Markets tool each solve only half. You can export products to CSV, open the file in a spreadsheet, write a formula to compute new prices, and import it back. That does the math, but it turns repricing into a careful spreadsheet and re-import job where a wrong column or a stale export can overwrite fields you did not mean to touch. Shopify does have a percentage price adjustment, but it lives under Markets and applies one percentage to an entire market's catalog, a tool for setting international prices, not for selectively repricing your home catalog by vendor, collection, or margin. Neither one is "reprice this group by this rule and round it."

Third, Flow cannot change a price. Shopify Flow, free on every plan, can react when a product is updated, can tag it, and can notify you. But Flow has no action that sets a product or variant price, so it cannot raise prices by a percentage, apply a rounding rule, or reprice anything at all. You can automate a message that a cost changed. You cannot automate the response. The one step that actually moves the number is the step Flow does not have, which is why merchants who need to reprice end up in the bulk editor, in a spreadsheet, or buying a separate app.

◆ DATA The tell that this is a real gap is the size of the cottage industry built to fill it. There is a whole shelf of bulk price editor apps whose entire job is to apply a percentage or fixed change to a selection of products and variants, round to the endings you use, schedule the change, and roll it back later. They exist, and merchants pay monthly for them, precisely because the native bulk editor stops at a grid of values you type by hand. When an app category exists only to add math to one field, the platform has told you where its automation stops.

Why the usual fixes don't hold

Once repricing starts to hurt, merchants reach for one of a few workarounds. Each one helps and each one breaks in a predictable spot.

"I will just use the bulk editor." Fine for changing a handful of prices you already know. The moment the change is a rule rather than a list, the editor stops helping, because it cannot compute anything. You are back to a calculator and a grid, fifty rows at a time, and every product with variants multiplies the typing. It is faster than opening each product individually, and that is the whole of what it offers. It is a better way to hand-type prices, not a way to avoid hand-typing them.

"I will export a CSV and do it in a spreadsheet." This is the workaround that quietly turns a merchant into a data-entry clerk with higher stakes. You export, write a formula, sort out the variants, handle the rounding, and import. It works until something in the file is off: a column you did not mean to include overwrites descriptions or inventory, a product added since the export is missing, the handle or variant SKU does not line up, and the import writes confidently over live data. The math is easy in a spreadsheet. The danger is that the spreadsheet is now the source of truth for your storefront, and one bad cell ships to every shopper.

"I will install a bulk price editor app." There are good ones, and for a store that reprices the same way every time they are a fair answer, which again proves the native gap is real. But most work from fixed rules you set up in advance: pick a percentage, pick a scope, run it. They do not read "raise everything from this vendor except the clearance tags, hold anything that would fall under a thirty percent margin, and round to .95," reason about each item, and stop on the ones that look wrong. They apply the rule you encoded, including to the products where the rule should not have applied. The judgement about which products the change is really for is the part that was hard in the first place.

What the automation actually has to do

The real job is not "edit prices." It is "when a cost or a policy changes, take the products and variants the change is really for, compute a new price for each one by the rule, round it the way this store rounds, keep compare-at honest so a raise does not read as a discount, and stop on anything that would break a margin floor or land on a strange number." That is selection, arithmetic, and judgement, run across the catalog. As a Dugong playbook, in plain prose, it reads like this: 

# trigger
On a cost change, a tariff or tax, a margin
   breach, or a planned reprice coming due

# steps
1. Select the products and variants in scope by vendor,
   collection, tag, cost, or margin
2. Compute a new price per item from a percentage,
   a fixed amount, or a target margin
3. Round to the price endings you use, like .99
   or whole numbers
4. Fix compare-at so a raise does not show as a
   fake discount
5. Hold anything below a margin floor, above a
   ceiling, or on a strange value for review
6. Write the new price across every variant in one
   pass, no fifty-per-page batching
7. Log the old price, the new price, and the rule,
   so the change is reversible

Seven lines. The compiler fills in everything underneath: resolving which products a loose description like "this vendor except clearance" really means, reading each item's current price and cost, doing the percentage or margin math per variant, applying the rounding you always use, deciding whether compare-at should move or clear, and writing it all in one pass while pulling the outliers aside. The merchant never sat with a calculator and three hundred rows over a weekend. They described how a careful pricing manager would handle the change, and let the compiler do the volume and catch the exceptions.

◆ NOTE The reprice that does damage is the confident wrong one. A percentage applied to the wrong products raises prices on items that were meant to stay on promotion, or cuts them on items you needed to protect. A dropped digit prices a product at a tenth of its value to every shopper at once. A rule with no floor pushes a thin-margin item below cost. The job is not "apply the math to everything," it is "move these specific prices by this rule, keep every one of them sane, and when a number looks wrong, stop and ask rather than write it." Automation that cannot tell a reasonable price from a broken one should not be writing to the storefront.

Why this is a compiler problem, not an app problem

There are capable bulk price editors, and for a store that reprices the same way every time they are a reasonable answer. But the thing that makes repricing safe to automate is not pushing a number into a field, it is the selection and the judgement around it: working out which products a plain-language scope actually covers, computing from cost or from current price depending on what the change is, knowing when compare-at should move with the price and when it should clear, and noticing when the rule would produce a price no sane store would charge. Those are decisions about a particular catalog on a particular day, and the right answer changes with every change, which means a fixed app rule was never going to hold.

A natural-language compiler fits because repricing was never really a data-entry problem. It is a selection and arithmetic problem wearing a price box's clothes. Typing one new price is the easy part, which is why the shortcuts do it. The hard part is everything around it: decide which products the change is for, compute each new number, round it your way, keep compare-at honest, and pull a human in on anything that looks off. You can write that brief in a paragraph. You could never hold it across three hundred products and their variants by hand. It sits in the same family as the sale you have to start by hand, which is the temporary version of the same gap, where Shopify will not schedule or revert a promotion by rule, and the meta description you write one at a time, where bulk editing a field is possible but doing it well, one good value per product, is not something the grid can do.

The workflow worth building this week

If you carry more than a handful of products and a cost increase, a tariff, or a margin call means retyping prices in batches of fifty, this is the automation to set up before the next change lands, because every price you key in by hand is twenty seconds you will never get back and one transposed digit away from selling at a tenth of the price to everyone at once. It pairs naturally with the merchandising and catalog work we have written about, like the sale you have to start by hand, the temporary cousin of this same problem, and it feeds the same flywheel as the Shopify automations no one builds, where the work that compounds is the part merchants never get to.

Describe it the way you would brief a careful pricing manager: when a cost goes up, take these products, move each price by this rule, round them the way we always round, do not let anything fall below our margin, keep the compare-at honest, and bring me anything that looks wrong before you save it. That is the whole brief. The compiler does the selection, the math, the rounding, and the writing. You keep your weekend, and you stop being the slowest, most expensive step between a cost change and a correct price.

◆ READING If this resonates, two companion pieces: our dispatch on the sale you have to start by hand, the temporary version of repricing where Shopify will not schedule or revert a promotion, and the field study on the Shopify automations no one builds, where the work that actually compounds is a sliver of what merchants wire up.

If you are a Shopify merchant who has wired up repricing that runs by rule instead of by calculator, or you have a story about the morning you raised three hundred prices by hand before the supplier increase hit, the inbox is open: field-notes@dugong.live. We are collecting case studies for the next issue.