Case study · Retail & loyalty
Offers are easy to give away and hard to control
Model Rocket needed a web-based coupon platform. The interesting engineering in offers is not creating them — it is making sure each one is redeemed once, by the right person, and that the merchant can prove it afterwards.
Engagement · Build & operate
A web platform where the rules are the product.
- Industry
- Retail, offers & loyalty
- Solution
- Coupon & offers platform
- Engagement model
- Product team
- Engagement length
- 1 yr 1 mo (Feb 2022 – Mar 2023)
- Market stage
- Build & launch
- Client
- Model Rocket, Reno, Nevada
- Scope
- Custom software development
- Platform
- Web application
Outcomes
What an offers platform has to guarantee
A coupon is a promise to give away value. Every figure here is about controlling that promise.
-
45%
Increase in offer redemption
Redemption takes seconds at a counter, so customers actually use the offers a merchant creates rather than abandoning them at the till.
Measured across issued and redeemed offers
-
70%
Faster campaign setup for merchants
Offers with real rules — dates, locations, limits, exclusions — are configured in an interface rather than requested from a developer.
Measured from campaign conceived to campaign live
-
0
Duplicate redemptions
Redemption is atomic and idempotent, so a retry, a double-click or a shared code cannot give away the same offer twice.
By design, verified under concurrent load testing
Context
The situation before the platform
Why showing a discount code is the easy part.
The business
Model Rocket, a Nevada company building a web-based platform for merchants to create and manage promotional offers.
The starting point
Anyone can build a page that displays a discount code. The difficulty starts the moment the offer has real conditions attached to it.
The trigger
Merchants need offers with genuine constraints — valid here, until then, once per customer, not with that other offer — and proof at the end of the month of what was actually given away.
What they wanted
A platform where merchants create offers with real rules, customers redeem them simply, and the redemption record is trustworthy enough to settle money on.
Constraints
Each coupon redeemable once, even on a bad connection · rules that combine: location, date, customer, other offers · redemption happens at a counter, quickly, in front of someone · the record has to be good enough to settle on.
System
What it runs at today
The platform as delivered.
-
4
Rule dimensions
Dates, locations, per-customer limits and exclusions, combinable
-
5.0
Client rating
Rated by the client in a verified review published on Clutch
-
1
Record behind dashboard and reports
Merchants reconcile against the same data the platform enforces with
-
0
Offers redeemable twice
Atomic redemption, verified under concurrent load
The engineering problem
Four problems in giving value away safely
A promotion is a target from the day it launches, and the attacks are predictable.
-
A promotion is attacked on day one
Offers attract exactly the people most interested in redeeming them more than once: replayed requests, shared codes, two devices at the same counter. Treating this as an edge case guarantees losing money on the first campaign.
What we did
Replay, sharing and concurrent redemption tested deliberately as part of the build, with protection designed in rather than added after the first exploited campaign.
-
Retries must not create value
A customer at a counter on poor signal presses redeem, sees nothing, presses again. If each press creates a redemption, the merchant has given away twice what they intended and cannot tell it happened.
What we did
Redemption made atomic and idempotent, so a retry resolves to the original redemption rather than creating a second one.
-
Rules that combine produce unexpected results
Location, date, per-customer limit and exclusions are each simple. Combined, they produce cases neither the merchant nor the platform anticipated — usually discovered by a customer who benefits.
What we did
The rule model defined and agreed in writing before implementation, so what an offer can express was bounded deliberately rather than accumulating.
-
Reporting that merchants cannot reconcile is worthless
A merchant settling a month needs to agree with the platform's numbers. Reporting built separately from enforcement produces two totals and a dispute.
What we did
Reporting built from the same redemption records the platform enforces against, so the merchant's reconciliation and the platform's enforcement cannot disagree.
Architecture
How it fits together
Simplified — the shape of the system rather than every service in it.
-
Application
- Web application
- Merchant dashboard
- Customer redemption flow
Merchant-facing offer creation and reporting alongside a redemption path designed for speed at a counter.
-
Rules
- Rule engine
- Validity evaluation
- Exclusion handling
What an offer can express, evaluated server-side at the moment of redemption rather than checked when the offer was displayed.
-
Data
- Relational database
- Atomic redemption records
- Reporting queries
Redemptions written atomically with the rule context that applied, which is what makes the record settleable.
-
Integrity
- Concurrency control
- Replay protection
- Audit record
The protections that make a promotion survivable: concurrent redemption handled, replays rejected, everything recorded.
The redemption is the only moment that matters, because it is where value changes hands. Everything else in the platform exists to make that one transaction correct, once, and provable afterwards.
Solutions
Creation, redemption and the record in between
Most of the engineering sits in redemption, because that is the moment where value changes hands.
-
Offer creation
Merchants build offers with validity rules — dates, locations, limits per customer, exclusions — in an interface that makes the rules legible rather than hiding them in fine print.
-
Redemption
Redemption validated against every rule at the moment of use, recorded atomically so a coupon cannot be redeemed twice by retrying.
-
Abuse prevention
Protection against the obvious attacks — replay, sharing, concurrent redemption — treated as a requirement rather than an afterthought.
-
Redemption record
Every redemption recorded with what, where, when and under which rules, so a merchant can reconcile rather than trust.
-
Merchant dashboard
Live view of offers and redemptions, and the reporting a merchant needs at the end of a period.
-
Customer experience
Finding and redeeming an offer kept to the fewest steps possible, because friction at a counter kills a promotion.
Key capabilities
What it does day to day
Six capabilities across creation, redemption and settlement.
| Capability | Runs | Refresh | What it does |
|---|---|---|---|
| Offer creation | Merchant | On publish | Validity rules — dates, locations, limits, exclusions — made legible rather than hidden in fine print |
| Redemption | Customer | Real time | Validated against every rule at the moment of use and recorded atomically |
| Abuse prevention | Automatic | Per attempt | Replay, sharing and concurrent redemption handled as requirements |
| Redemption record | Automatic | Per redemption | What, where, when and under which rules, stored for reconciliation |
| Merchant dashboard | Merchant | Live | Offers and redemptions as they happen, plus end-of-period reporting |
| Customer experience | Customer | On demand | Finding and redeeming an offer in the fewest steps, because friction at a counter kills a promotion |
Integrations
How the moving parts plug in
Every redemption passes the full rule set before anything is recorded.
Merchant & customer
- Offer creationRules set by the merchant
- Redemption attemptAt a counter, quickly
- Reporting requestEnd of period
Rules & integrity layer
- Validity evaluationDates, locations, limits, exclusions
- Concurrency controlOne redemption, even under load
- Replay protectionA retry is not a second redemption
Records
- Redemption records
- Rule context
- Merchant reporting
- Audit trail
Because reporting reads the same records enforcement writes, the merchant's month-end figure and the platform's enforcement are the same number seen twice.
Security & data
What stops an offer being exploited
A promotion is a financial instrument with a public interface, which is an unusual combination to have to protect.
-
Server-side rules
Every validity decision is made on the server. Nothing about whether an offer applies is decided in a browser.
-
Atomic redemption
Redemption is written in one transaction, so concurrent attempts cannot both succeed against the same coupon.
-
Replay protection
Repeated or replayed requests resolve to the original redemption rather than creating new value.
-
Full audit record
Every attempt, successful or not, is recorded with the rules that applied, so a disputed campaign can be reconstructed.
The brief
A coupon is a promise, and promises get abused
Anyone can build a page that shows a discount code. The difficulty starts with the rules: this offer is valid here, until then, once per customer, not with that other offer, and the merchant needs to be able to prove what happened at the end of the month.
Model Rocket needed a platform where merchants create offers with real constraints, customers redeem them simply, and the redemption record is trustworthy enough to settle on.
- Offers with genuine validity rules, not just an expiry date
- Redemption that cannot be replayed or shared around
- A simple experience at the point of use
- Reporting a merchant can reconcile against
What an offers platform has to enforce
- 01Each coupon redeemable once, even on a bad connection
- 02Rules that combine: location, date, customer, other offers
- 03Redemption happens at a counter, quickly, in front of someone
- 04The record has to be good enough to settle money on
Process
Rules first, because everything else depends on them
We settled exactly what an offer can express before building anything that had to enforce it.
-
Defining the rule model
What an offer can express — validity, limits, exclusions, combination — written down and agreed before it was implemented.
-
Redemption design
The redemption path designed for a counter: fast, unambiguous, and safe when the connection is poor or the button is pressed twice.
-
Building the platform
Offer creation, redemption and reporting over one record, with the rules enforced on the server and never in the browser alone.
-
Hardening against abuse
Concurrency, replay and sharing tested deliberately, because a promotion is a target the day it launches.
-
Merchant reporting
Reporting built from the same redemption record the platform enforces against, so the numbers cannot disagree.
Technology
A web platform where the rules live on the server
Every validity decision is made server-side and recorded, because a rule enforced in a browser is a suggestion.
Application
- Web application
- Merchant dashboard
- Customer redemption flow
Rules
- Offer rule engine
- Validity evaluation
- Exclusion handling
Data
- Relational database
- Atomic redemption records
- Reporting queries
Integrity
- Concurrency control
- Replay protection
- Audit record
Business impact
What changed for merchants
Three things that follow from rules enforced properly.
-
Offers with real limits
A merchant can promise something specific rather than something vague, because the platform will hold the boundary.
-
Predictable campaign cost
One redemption per coupon, enforced, means a promotion cannot quietly cost several times what was budgeted.
-
Reconcilable records
Month-end settlement is a reconciliation rather than an act of faith in someone else's total.
The result
Offers a merchant can launch without wondering what it will cost them
Merchants create offers with real constraints, customers redeem them in a few steps, and every redemption is recorded once against the rules that applied at the time.
The client described the work as exceptional quality in a verified Clutch review.
- Offers with genuine, enforceable validity rules
- Redemption recorded atomically — no double redemption
- Abuse paths tested deliberately before launch
- 5.0 rating in a verified Clutch review
What we would repeat on an offers product
- 01Define what an offer can express before building it
- 02Enforce every rule on the server, without exception
- 03Make redemption atomic — retries must not create value
- 04Assume the promotion will be attacked on day one
Client review
What the client said about the work
Published on Clutch, where the client is verified and we cannot edit or remove what they write.
-
Custom Software Development
Web-Based Coupon App Development
The work produced by the team was of exceptional quality.
Jon Thies
CTO, Model Rocket Feb 2022 – Mar 2023
Free discovery call
Have an idea? Let's turn it into AI-powered software.
Book a free discovery call with our experts. Share your idea and we will help you shape the scope, timeline and budget, under NDA.
- Free consultation
- NDA before we talk
- Transparent estimate