I built Pricely off the same complaint showing up over and over: you run a sale across 40+ products, and then someone has to sit there afterward putting every price back one at a time. It schedules the sale, reverts every price automatically when it ends, and ends early in one click if you change your mind.
It’s on the App Store now. What I don’t have is enough real stores on it to know where it falls over — and I’d rather find that out from a merchant than from a support ticket six months from now.
So: 3 merchants who run sales regularly and are willing to actually use it and tell me what’s wrong with it. The 14-day trial covers the test, and if you need longer to get through a real sale cycle, say so and I’ll extend it. I want the feedback more than the $9.
What I’d ask of you: run one real scheduled sale end to end, then tell me the part you didn’t trust. Especially interested if you have a large catalog, or if you’ve been burned by pricing automation before and have a reason not to trust this one.
Full disclosure: my own app — Pricely - Bulk price edits & scheduled sales with one-click rollback | Shopify App Store . Reply here and I’ll follow up.
Steve — the audit history you’re describing already exists, so I’d rather show you than promise it: every job lands in a history table with a timestamp, the type (edit, scheduled sale start, sale end, rollback), the status, and a verified count like “6/6 verified” — that count is the app re-reading every variant after the write to confirm the price actually landed, not just that the API returned OK.
The rollback preview is a fair hit, though — that one genuinely isn’t there. Preview today covers a change you’re about to make, not the rollback itself: hit Rollback and it goes, no “this will restore 214 variants across 38 products, here’s the summary” step first. You’re right that it should, and it’s going on the list as a real request rather than an idea I made up.
Since you’ve now thought about this app more carefully than most people who’ve installed one: does your store actually run sales often enough for this to matter to you? If yes, take one of the three spots and try to break the rollback — that’s the part I most want someone hostile to test. If it’s not a fit for what you sell, say so plainly and I’ll stop pitching it at you, no hard feelings.
Steve — the rollback preview you asked for is live.
Clicking Rollback no longer starts anything. It opens a confirm step directly under that job’s row in the history, showing exactly what would happen: how many products and how many variants would be restored, and a row-by-row list of each product’s current price next to the price it would go back to. Nothing is written until you confirm it. If some variants are already sitting at their original price, it says so rather than padding the number.
Two details you didn’t ask for but might care about:
- It’s free whether or not you’re on a paid plan. Restoring your own prices isn’t something you should have to pay for, and neither is looking at what would happen first.
- If a scheduled sale hasn’t started yet, it still just cancels — there’s no restore to preview, because nothing was changed.
A few other things went in at the same time:
- Big jobs now run in the background with a live count as they go, so the click comes back straight away and you can close the tab and come back to it. On a 300-product test catalogue a sale applies and re-verifies every variant in about 20 seconds.
- If Shopify rate-limits a large job, it waits for the limit to clear and carries on.
- Scheduled sales start within about 15 seconds of the time you set.
You were right that the preview was the gap. Thanks for saying it plainly — please keep trying to break it.
I like the approach of asking merchants to test it in real-world conditions rather than just collecting installs. That’s usually where edge cases show up, especially with stores that have larger catalogs or multiple sales running simultaneously.
If I were testing it, the things I’d pay the closest attention to would be:
- Whether every product price is restored correctly after the scheduled sale ends, even if products are edited during the promotion.
- How it handles products with multiple variants and compare-at prices.
- Whether it’s reliable across larger catalogs, where hundreds or thousands of prices may change at once.
- What happens if a sale is stopped early or if two scheduled sales overlap.
Those are the kinds of scenarios that tend to determine whether merchants feel comfortable trusting pricing automation.
Wishing you the best with the testing phase. Getting feedback from merchants running actual promotions will probably uncover the most valuable improvements before you scale further.