DiscountHub Web is now a full product, not just an app landing page
Hey Indie Hackers 👋
Quick update on DiscountHub.
At first, our website was only a simple landing page for the mobile app. Now we’ve turned DiscountHub Web into a full product.
People can now browse:
- real discounts
- promo codes
- partner offers
- stores with active deals
directly from the website.
The iOS app is already available, and Android is coming soon.
We also added a Partner Offers section for founders, indie makers, and online stores. If someone is building a product or running a store and wants to share a real discount, we can help give that offer more visibility.
I’d love to hear your feedback on the new web version and the positioning.
Website:
The web move is smart because coupon/search intent starts on the browser, not in an app store. The positioning issue I'd watch: the page is trying to serve two different jobs at once — shoppers looking for promo codes, and founders/stores who want to submit partner offers. Both are valid, but they need different landing paths. I'd make the homepage primarily shopper-first: "Find working promo codes and live deals by store." Then give Partner Offers its own clearer page/CTA: "List your founder discount." Also, "real discounts" is a good promise, but it needs a trust mechanism next to it: verified date, last checked, success rate, or "manually reviewed." In coupon products, freshness is the conversion lever.
Thanks for the practical advice—especially regarding the verification mechanism; I’ll certainly give that some thought. Also, there might be a slight misunderstanding regarding the partner offers page: it isn't exactly intended for "founders" in the traditional sense of the word. It will feature discounts, special offers, and promo codes from indie developers—people just like us. The process is simple: an indie developer sends me a private message with the necessary information and API details, and I post their offer on the page. The goal is to help those who are just starting out. )
Thanks for clarifying — that makes sense, and I may have framed "founders" too broadly. In that case, I'd make the Partner Offers page position itself more as an indie-maker support page than a business/vendor page. Something like: "Discounts and special offers from indie developers, for indie developers." That makes the intent warmer and clearer. It also separates it from generic coupon/affiliate pages, which often feel transactional. The trust mechanism still matters, though — especially if offers are submitted by DM. Even a simple "submitted by indie makers, reviewed before publishing, last checked on…" can make the page feel more reliable without making the process complicated.
The web looks super clean / fancy
Thank you for the kind words.
Smart pivot — going app-only meant missing the "store name + promo code" searches that are basically the entire top-of-funnel for this category. Now every store/deal page can rank and pull people in organically instead of relying purely on app installs. Curious how you're handling verification freshness at scale once you've got hundreds of stores listed — that's usually the make-or-break trust signal in coupons. The Partner Offers angle for indie makers is a nice wedge too, that's an audience that's actively looking for extra visibility.
Moving from app-only to web is bigger than it looks: coupon demand starts with a "brand + promo code" search, and an app can't capture that intent but store pages can. Treat every store and deal page as a landing page for that exact search and the web product becomes your acquisition engine, with the app as the retention layer. That's the playbook RetailMeNot rode to scale.
Congrats on the web version — that's the right move. I made a similar mistake with my own site, keeping it as a bare landing page way longer than I should have, since the app itself was where all my attention went.
On trust: since you're in the deals/coupons space, "when was this last verified" might matter more to people than any positioning copy — a promo code page that visibly shows a recent check date probably converts better than one that just claims to be accurate. I only really internalized this idea myself after shipping a small trust signal in my own app (an honest note about which devices I've actually tested on, instead of just claiming broad support) and seeing people react well to the plain honesty of it.
Question on the Partner Offers section — are you thinking indie makers could list something like a free trial code as a "deal," or is it strictly retail discounts?
I’m thinking about adding information on when and by whom it was last checked. However, I deliberately built both the website and the apps without a registration requirement to make them as easy as possible to use and to avoid unnecessary hassles with Apple and Google over data collection. That said, I realize that eventually, I’ll need to introduce user accounts to keep improving the project. That will come later; for now, the priority is building a large base of active users. Any offers from independent developers-such as promotions, promo codes, or discounts-are included; this applies even to free trials obtained via promo codes.
Progress is being made, and that’s a good thing.