Short answer
RaftLabs built the coupon distribution and fraud-prevention system behind a Power NI promotion, delivered through BrandFire, in about 30 days. Each customer received a unique redemption URL, and an IP-based eligibility check stopped multiple people at the same address from claiming separate coupons. All 250 coupons were redeemed within a week of launch, with zero duplicate redemptions recorded.
Engagement
The Power NI engagement
- Client
- Power NI
- Sector
- Utilities and energy services in Northern Ireland
- Delivery
- Fixed-scope project, about 30 days, delivered through BrandFire
- Team
- One project manager, two developers, and QA
- Scope
- Unique-URL coupon distribution and IP-based redemption fraud prevention
- Status
- All 250 coupons redeemed within a week; RaftLabs continues to take on BrandFire-sourced builds
A limited-quantity coupon giveaway has one failure mode that ruins it for everyone: the same household claims several codes while other genuine customers get nothing. Power NI's original setup could only enforce one coupon per IP address total, which meant the first visitor from a shared connection, like a household, an office, or a block of flats, locked out every other real customer behind it.
The founder running the promotion wanted something sharper: a unique redemption URL for every customer and every coupon, with fraud protection that told genuine multi-person households apart from someone gaming the system. RaftLabs took on the build through BrandFire, on a fixed scope, with a two-developer, one-QA team over roughly 30 days. All 250 coupons were redeemed within a week of launch.
before & after
From one-IP-one-coupon to fair, fraud-resistant distribution
- One IP address could redeem only one coupon, full stop, no matter how many real customers shared that connection
- Every customer used the same generic redemption link, so there was no way to trace a code back to a specific person
- The founder faced pressure to get a workable fraud control live before the limited coupon stock ran out
- With no way to tell one household's five members from one person running five browsers, the team had no better option than a blunt total block
- Each customer received their own unique coupon URL, tying a code to a person rather than a shared link
- An IP-based eligibility check ran per redemption attempt, catching rapid multi-claim patterns from the same address without a blanket one-per-IP rule
- Genuine multi-person households could still redeem legitimately, since eligibility was evaluated per coupon claim rather than as a lifetime IP block
- The admin view showed redeemed versus unredeemed coupons in real time, so the team could watch the giveaway run down without guessing
The decisions that made the fraud control work
- 01
Telling a real household apart from a repeat claim
The brief sounded simple: block coupon fraud. The harder problem showed up once the team modeled real usage. Multiple genuine people, family members, flatmates, colleagues on the same office network, could easily share a single IP address. A flat one-per-IP rule, which was the original setup, punished those legitimate cases as collateral damage while doing nothing to stop someone who just switched browsers or used a VPN.
The team's answer was to check IP address and eligibility per redemption attempt rather than applying a single lifetime block per address. That distinction, evaluating each claim rather than locking out the address permanently, was the decision that let real multi-person households through while still catching the rapid repeat-claim pattern that signaled abuse.
- 02
Generating a unique URL for every coupon, not just every user
Power NI wanted unique URLs for both users and coupons, a two-layer identity problem rather than the usual single-token link. Each generated URL had to resolve to exactly one coupon and be traceable to the customer it was issued to, so a code could be redeemed once and only once, and any dispute could be traced back to the original send.
This mirrors a pattern RaftLabs has built more than once: a referral and campaign platform the team shipped separately used the same unique-URL foundation to keep attribution accurate across shares, forwards, and link copies. The core discipline is the same regardless of the campaign mechanic: generate the identifier before any redemption logic runs, and never let two coupons resolve to the same link.
- 03
Multiple genuine people, one IP address, one edge case that hit fast
The edge case that caught the team off guard early was exactly the collateral-damage problem the old system created: multiple different, real people redeeming from the same IP address, not because anyone was gaming the system, but because they lived in the same household or worked from the same office.
Fixing the fraud problem without breaking the legitimate case meant the IP check had to carry more nuance than a simple denylist. The system needed to reason about redemption patterns, not addresses in isolation, which pushed the eligibility check from "has this IP claimed before" to "does this claim pattern from this IP look like normal household usage or like abuse."
the build
What the coupon system changed
The redemption experience and the fraud control had to work together. A unique URL means nothing if the eligibility check behind it still blocks legitimate customers, and a smart fraud check is pointless if the underlying link can be duplicated or guessed.
Every customer redeemed through their own coupon link
Each customer received a unique URL tied to their specific coupon. A code could not be redeemed from a link that was not issued to that customer, closing off the simplest form of code-sharing abuse before the IP check even ran.
IP eligibility ran per claim, not as a lifetime address block
Instead of banning an IP address after its first redemption, the system evaluated each new claim from that address against the pattern of prior claims. Genuine households kept working; rapid, repeated claims that looked like abuse got stopped.
The admin view tracked redeemed against unredeemed in real time
A simple admin panel let the team see how many of the 250 coupons had been claimed against how many remained, without needing to query the database directly. The panel intentionally did not include an editable terms-and-conditions or FAQ builder; the fixed scope and short timeline meant that page content stayed as a manual edit rather than a self-serve feature.
Proof
What changed after launch, and what supports each claim
These figures come from the retained PM questionnaire responses. Exact redemption timestamps and any cost figures are not part of the public record.
| Result | What changed | Period or context | Evidence and limitation |
|---|---|---|---|
| Redemption completion | All 250 coupons redeemed | Within one week of launch | PM-reported project record |
| Fraud incidents | Zero duplicate redemptions from the same household | Across the full 250-coupon run | PM-reported project record; measured via the admin redeemed/unredeemed view |
| Delivery time | About 30 days, fixed scope | From kickoff to launch | PM-reported project record |
What clients say
What Power NI said about the delivery
Feedback shared by the founder who ran the promotion.
Power NI Program Lead
Founder, Power NI promotion team
Northern IrelandWe wanted unique URLs for every user and coupon, which felt like a hard ask going in. The team got there anyway, and once it was live, the coupons were gone quickly with no complaints about someone else claiming a code first.
After launch
What happened after launch
- 01~30 days
The coupon and fraud-prevention system launched
Power NI moved from a one-IP-one-coupon block to unique-URL coupons with per-claim IP eligibility checks. - 02Within 1 week
All 250 coupons were redeemed
The admin view tracked redemptions in real time. No duplicate redemptions from the same household were recorded. - 03Ongoing
The BrandFire relationship continued
Power NI came to RaftLabs through BrandFire, and RaftLabs continues to take on BrandFire-sourced engineering work for loyalty and campaign clients.
The lesson
For limited-quantity giveaways, fraud prevention is a per-claim decision, not a per-address rule
The instinct with coupon fraud is to write a rule that blocks the address. That rule also blocks every legitimate person who happens to share it, which is exactly what was happening to Power NI's real customers before this rebuild.
If you are running a limited-quantity coupon, voucher, or ticket giveaway, treat eligibility as a judgment made on each redemption attempt: look at the pattern behind an IP address, not just its presence on a list. A rule that only counts addresses will always trade fraud prevention for false positives against your own genuine customers.
stack
Why we chose this approach
- 01Unique URL generationEach coupon needed its own traceable, non-guessable redemption link tied to one customer and one code, generated before any eligibility logic ran.
- 02IP-based eligibility checksRedemption eligibility was evaluated per claim against the pattern of prior claims from that address, rather than as a single lifetime block, so legitimate multi-person households were not locked out.
Evidence and limitations
Reviewed 24 September 2026
- Project scope and implementation: based on the PM's retained questionnaire responses collected for the case study revision project (Asana task 1215260233074980).
- Outcomes: the 250-coupon redemption count, one-week redemption window, and zero-duplicate-redemption result are PM-reported and have not been independently audited by RaftLabs or Power NI. Exact budget and delivery dates were not disclosed and are omitted here.
- Client relationship: Power NI was a BrandFire-sourced engagement. RaftLabs built the coupon distribution and fraud-prevention engineering; BrandFire held the client relationship and campaign management.
- Quote: the testimonial above is a paraphrase of PM-reported client sentiment, not a verbatim quote from a named contact. This page should not go live without BrandFire's or the client's sign-off on the quote and metrics, per the case study framework's client-approval requirement.
- Visuals: product screens are interface reconstructions based on the delivered workflow, not screenshots of the live product.
Questions about the Power NI coupon fraud prevention build
Power NI's original system allowed only one coupon redemption per IP address in total, which blocked genuine multi-person households sharing a connection while doing little against someone who simply switched browsers. RaftLabs built unique per-user, per-coupon URLs and a per-claim IP eligibility check so real customers could redeem while abusive claim patterns were still caught.
The build was a fixed-scope project delivered in about 30 days, with a team of one project manager, two developers, and QA. The project was delivered through BrandFire, which held the client relationship.
A flat one-per-IP rule punishes real customers who share a connection, such as household members or office colleagues, as collateral damage. RaftLabs evaluated eligibility per redemption attempt against the pattern of prior claims from that address, which let genuine multi-person households redeem normally while still catching rapid, repeated claims that signaled abuse.
Given the fixed scope and short timeline, the admin panel did not include a self-serve editor for terms and conditions or FAQ content; those pages stayed as manual edits rather than becoming admin-configurable fields. This was a deliberate trade-off disclosed to the client, not an oversight.
The same unique-URL-plus-per-claim-eligibility pattern applies to any limited-quantity coupon, voucher, or ticket giveaway where a business needs to stop the same household or address from claiming multiple codes without blocking genuine repeat visitors. See our loyalty program development and utilities loyalty program development services for how we scope similar builds.
RaftLabs continues to take on engineering work sourced through BrandFire, which brought the Power NI engagement to RaftLabs in the first place. BrandFire manages the client relationship and campaign strategy; RaftLabs builds the platform engineering behind qualifying programs.
Related work
