The hardest part of a roadmap is not the list of things you will build. It is the longer list of reasonable requests you decide, on purpose, to disappoint.
We get feature requests every week. Most are thoughtful, and many describe a real problem. But a small app cannot build everything and stay good at anything. So the roadmap is really a set of decisions about what not to do, and the discipline is being able to explain each no in one clear sentence.
Here are three requests we turned down this year, the reasoning behind each, and the one request we said yes to, so you can see the filter we actually use.
The filter: does it make the core job more reliable?
Our core job is narrow on purpose: run native discount and pricing logic through Shopify Functions so it applies correctly in cart and checkout, on any plan, without hurting margin. Every request gets held up against that sentence. If a feature makes that job more complete or more reliable, it is a candidate. If it adds a new, loosely related surface, the answer trends toward no, even when the request is popular.
This is not about being minimalist for its own sake. It is that every feature you ship is a feature you maintain, support, and reason about forever, including during BFCM at 2am. Scope is a liability with a long tail.
No 1: the countdown timer widget
The request: add an urgency countdown timer to product and cart pages to pressure customers toward the sale.
Why we said no: it is a storefront theme and conversion-optimization job, not a discount-engine job. Timers live in the theme, need design control to match a brand, and are handled well by a whole category of dedicated apps. If we built a mediocre timer, we would own a support burden for pixels and CSS that has nothing to do with whether a discount calculates correctly. The two problems do not share a spine.
The honest version of the no: a timer would help us look fuller in the App Store screenshots, and that is exactly the wrong reason to build something.
No 2: unlimited discount stacking
The request: let every discount stack on top of every other one automatically, with no limits.
Why we said no: this one is not just off-scope, it is actively harmful. Uncontrolled stacking is how a planned 20 percent quietly becomes an actual 40 percent when a volume tier, a code, and a shipping offer all land on the same cart. The value we provide is the opposite of unlimited: deliberate combination control, so you decide exactly what stacks with what. Building a switch that removes that control would undercut the reason the product exists. We covered the mechanics of this in our guide to how discount combinations work if you want the full picture.
No 3: a built-in email marketing tool
The request: send discount announcement emails directly from the app.
Why we said no: email marketing is a deep discipline with mature, dedicated tools, deliverability, segmentation, templates, compliance, and a decade of refinement behind them. A discount app that bolts on a thin email feature does two jobs worse instead of one job well. The better service to a merchant is to make our discounts easy to reference from the email tool they already trust, not to compete with it badly.
The one we said yes to: customer-specific pricing
Now the yes. Enough merchants kept describing the same wall: they wanted different prices for wholesale accounts, VIP customers, and staff, without standing up a separate wholesale storefront or upgrading a plan for it. That request passed all three tests.
- Many merchants hit the same wall. Wholesale and VIP pricing came up constantly, across very different store types.
- It sits inside the core job. Customer-specific pricing is still discount and pricing logic running through Functions. Same spine, wider reach.
- It makes existing features more useful. Volume tiers and pricing rules become far more powerful once you can scope them to a customer segment.
So we built it, and it shipped in May. You can read the launch note for B2B and customer-specific pricing, or see how it works on the B2B pricing page.
How to read a no from any tool you use
If a tool you rely on turns down a feature you asked for, the useful question is not whether they were nice about it. It is whether their no is consistent with a clear core job. A vendor that says yes to everything is a vendor whose product will eventually be a confused pile of half-features, none of them dependable. The ones worth trusting can tell you what they will never build, and why.
Setting this up with Discount Prime
If you want to see what we did choose to build, the volume discounts engine and customer-specific pricing are the core of it, and the current thinking lives on our public roadmap. For more on how merchant conversations shape those calls, see what 100 support conversations taught us and our one year of building Discount Prime retrospective.
