How to Make an App Like Honey

Building a browser extension that automatically finds and applies coupon codes sounds deceptively simple. It isn't. Honey's core product touches browser internals, merchant checkout flows, affiliate networks, and real-time coupon databases all at once. This post breaks down how that system actually works and what decisions you'll face if you're building something similar.

How Does Honey Actually Work Under the Hood?

Honey is a browser extension available for Chrome, Firefox, Safari, and Edge. When a user lands on a supported merchant's checkout page, the extension injects a content script into the DOM. That script detects the coupon input field, pulls a list of codes from Honey's backend, and tries them sequentially. It captures the cart total before and after each attempt, compares the values, and keeps the best result.

The detection logic is the tricky part. Merchants don't use a standard field name or structure. Honey maintains a per-merchant configuration database that maps domain patterns to CSS selectors, XPath expressions, or JavaScript hooks. That database has to be maintained continuously. Merchants change their checkout templates, migrate platforms, run A/B tests. A selector that works today may break next week.

The Coupon Data Pipeline

Coupons come from a few places: affiliate networks (CJ Affiliate, Rakuten, ShareASale), direct merchant partnerships, and community submissions from users. Honey's community sourcing is significant. PayPal (which acquired Honey in 2020 for $4 billion) has stated the extension had over 17 million active users at the time of acquisition. That user base acts as a passive data source. Every failed or successful code attempt feeds back into the ranking model.

On the backend, codes are stored with metadata: merchant ID, expiry date, discount type (percentage off, flat amount, free shipping), success rate, and last-verified timestamp. The ranking algorithm surfaces codes with the highest expected value, not just the most recently added ones.

What Does the Technical Architecture Look Like?

At a high level, the system has four components: the browser extension, an API layer, a coupon data service, and an affiliate tracking layer.

Component	Technology choices	Key concern
Browser extension	WebExtensions API (Manifest V3)	Cross-browser compatibility
Coupon API	REST or GraphQL, CDN-cached	Latency at checkout moment
Coupon database	PostgreSQL + Redis cache	Freshness vs. read speed
Affiliate tracking	Redirect links, cookie injection	Compliance, cookie lifetime

Manifest V3 deserves attention. Chrome's move from MV2 to MV3 removed persistent background pages and restricted certain APIs. If you're building this today, you cannot use webRequest to block or modify requests the same way MV2 extensions could. You'll use declarativeNetRequest instead, which is less flexible. Safari's Web Extensions model adds further constraints. Plan for about 30% more engineering effort on the extension layer if you need all four major browsers from day one.

Affiliate Revenue and Cookie Injection

This is how Honey actually makes money. When a user activates the extension on a merchant's page, Honey can overwrite the existing affiliate cookie with its own. That means if someone clicked a blogger's affiliate link before opening Honey, Honey's cookie may take the commission instead. This practice has attracted significant controversy and at least one class-action lawsuit filed in 2024 by creators who argued it cost them commissions.

If you're building a similar product, you need to decide upfront how you handle existing affiliate attribution. Overwriting cookies is technically straightforward. The legal and reputational exposure is not trivial.

How Do You Handle Merchant Compatibility at Scale?

This is the hardest ongoing engineering problem. A small competitor can support 500 merchants with a hand-curated configuration file. Honey reportedly supports over 30,000 merchants. Getting from 500 to 30,000 requires automation.

The practical approaches:

• Rule-based selector inference: Train a classifier on labelled checkout page HTML to identify coupon fields automatically. Features include field name attributes, placeholder text, nearby label text, and form structure.
• Headless browser testing: Run Playwright or Puppeteer against merchant checkboxes in a sandboxed environment to verify selectors before pushing them to production.
• User-triggered fallback: If the extension can't find a coupon field, surface a manual input UI so users can still apply codes themselves. Log these events to identify merchants that need a new rule.

Versioning the merchant config is important. You want to be able to roll back a bad selector update without a full extension release, since extension updates go through browser store review queues that can take 24 to 72 hours.

Keeping Coupon Data Fresh

A coupon database that's 60% expired codes is actively harmful. Users who try bad codes and see no discount stop trusting the product. The verification pipeline matters as much as the sourcing pipeline.

Options for freshness:

• Passive verification: Log every extension-triggered attempt and its outcome. Failed codes get their success rate downweighted.
• Active scraping: Crawl merchant coupon pages, deal aggregator sites, and affiliate feeds on a schedule. Respect robots.txt or you'll get blocked.
• Merchant API integrations: Some platforms (Shopify, BigCommerce) expose coupon validity endpoints. Use them where available. They're far more reliable than scraping.

What Are the Realistic Build Costs and Timelines?

A minimal viable version, supporting one browser (Chrome), 100 curated merchants, and a basic coupon API, will take a focused team of three engineers roughly four to five months. That assumes someone with WebExtensions experience, a backend engineer comfortable with Node.js or Python, and a data engineer for the coupon pipeline.

A production-grade system with cross-browser support, automated merchant detection, an affiliate integration, and a coupon freshness pipeline is closer to 12 to 18 months of sustained development before it's operationally stable. The extension itself is not the bulk of the work. The data infrastructure is.

Cloud infrastructure costs are modest early on. Coupon data is read-heavy and highly cacheable. A CDN like Cloudflare in front of your coupon API will handle most load without significant compute spend. The cost curve steepens when you start running headless browser verification jobs at scale.

Is Building In-House the Right Call?

Depends on what you're actually building.

If your core product is a deal discovery or loyalty tool and coupon application is the primary feature, build it. The complexity is manageable and owning the codebase matters for iteration speed.

If coupon application is a secondary feature in a broader product (say, a shopping assistant or a fintech app with cashback), buying a white-label solution or integrating via an API provider like Coupons.com or Honey's own affiliate programme is the more sensible path. You'll spend less time on merchant compatibility and more time on your actual differentiation.

The affiliate revenue model also requires meaningful scale before it pays. If you don't have an existing user base to drive volume, you'll be subsidising the product for longer than feels comfortable.

Conclusion

The Honey model is well-understood at this point. The browser extension mechanics, the coupon pipeline, the affiliate layer — none of it is novel. What makes it hard is the operational discipline: keeping merchant configs current, keeping coupon data fresh, and managing the compliance surface around cookie attribution.

If you're evaluating whether to build something similar, start with the merchant compatibility problem. That's where most teams underestimate effort. Prototype the selector inference pipeline against 20 merchants before committing to a roadmap. It will tell you more about actual build complexity than any estimate will.

If you want to talk through the architecture in detail, the team at Sodio has built similar data-intensive extension products and can give you an honest read on scope before you start.

---

FAQ

How long does it take to build a browser extension like Honey? A basic single-browser prototype covering around 100 merchants takes three to five months with a small team. A production-ready system with cross-browser support, automated merchant detection, and a coupon freshness pipeline is realistically 12 to 18 months. The extension code is a small fraction of total effort. The data infrastructure takes the most time.

How do coupon extensions make money? Primarily through affiliate commissions. When a user applies a coupon or clicks through to a merchant, the extension can set an affiliate tracking cookie. If the user completes a purchase, the extension provider earns a percentage of the sale, typically between 1% and 10% depending on the merchant category and affiliate network terms.

What is Manifest V3 and why does it matter for extensions like Honey? Manifest V3 is Chrome's updated extension platform specification that replaced MV2. It restricts background page persistence and changes how network requests can be intercepted. Extensions that relied on flexible request modification in MV2 need to be substantially rearchitected for MV3. Building for MV3 from the start is the correct approach today, but it limits some capabilities.

Can you scrape coupon codes legally? Scraping publicly available coupon codes from deal aggregator sites sits in a legal grey area. The key risks are terms of service violations and, in some jurisdictions, computer access laws. Using affiliate network feeds and direct merchant partnerships is cleaner from a legal standpoint. If you scrape, get a legal review of your target sites' terms before building the pipeline.

What's the hardest part of building a Honey-like product? Merchant compatibility. Every retailer structures their checkout page differently, and those structures change frequently. Maintaining accurate CSS selectors or JavaScript hooks across tens of thousands of merchants requires either significant manual curation or a well-engineered automated detection system. Most teams underestimate this operational burden at the start.

Have a project in mind? Contact Sodio Technologies to discuss your requirements and explore the right technology solution for your business.