Build or buy? The backend behind an instant-win promotion

What an internal build normally requires

The campaign site is the visible part and usually the smaller part. Behind it, a promotion that awards prizes of real value needs all of the following, and the list is longer than most briefs admit:

Component	What it has to do
Secure code generation	Non-sequential, unguessable codes from a print-safe alphabet, at volumes of hundreds of thousands to millions, with no duplicates.
Batch management	Several print runs per campaign, a CSV the printer can use, and a way to revoke a batch that was lost or misprinted.
Redemption endpoint	Accept a code, normalise what the consumer typed, decide, respond in well under a second at peak.
Winning logic	Release prizes by rule over the campaign, not to whoever arrives first on launch day.
Prize inventory	Know at all times how many of each prize are left, won, collected and expired.
Concurrency protection	Two simultaneous entries must never win the same prize or redeem the same code twice.
Idempotency	A retried request after a timeout must return the original answer, not create a second entry.
Participant limits	Entries per person per day, with a definition of "person" that does not require collecting personal data.
Rate limiting	Per IP, per participant and per integration, so neither code guessing nor a bug in a client's site can hurt the campaign.
Fraud controls	Invalid-code budgets, captcha on the public surface, manual approval for high-value wins.
Claims	A state machine from win to fulfilled, with expiry, approval, rejection and in-store collection.
Webhooks	Signed, retried, logged deliveries so the agency's systems learn about wins and claim changes.
Audit logging	Every attempt, outcome and change, kept long enough to answer a dispute months later.
Reporting	Numbers that reconcile: for every tier, won equals fulfilled plus expired.
Load testing	Proof that the above holds under launch-day traffic, with the locks in place.
Operational monitoring	Someone who knows within minutes that redemptions are failing, on a Saturday.

Building internally

Advantages

Complete control. Every rule, every screen, every field is yours. Nothing is decided by someone else's product roadmap.
No external dependency. No third party in the critical path, no vendor to vet, no procurement conversation with the client's legal team.
Custom logic. A mechanic nobody else offers, a tie-in with the client's loyalty programme, a prize rule specific to one market. Some campaigns genuinely need this.

Disadvantages

Engineering time. The table above is weeks of senior backend work before a single screen is designed, and the concurrency and audit rows are the ones that get cut when the deadline moves.
Repeated work. The next campaign has a different brand, a different prize table and the same backend problems. Internal builds tend to be rebuilt rather than reused, because the last one was tied to the last client's site.
Testing burden. The failure modes that matter only appear under concurrency. Testing them properly means writing tests that race, which most teams do not have time to do for a twelve-week campaign.
Launch-day risk. The first real traffic a promotion backend sees is usually its peak traffic. There is no soft launch for an on-pack campaign; the packs are already in the shops.
Security responsibility. A prize is money. If a code can be guessed, replayed or redeemed twice, the agency carries the conversation with the client, and possibly the cost.
Audit requirements. When a consumer disputes an outcome or a brand's finance team asks where prize 4,117 went, the answer has to come from records that were kept from day one.
Maintenance after launch. Someone has to watch it, patch it and answer questions about it for the length of the campaign and the claim period after it, long after the project budget has closed.

Using promotion infrastructure

The alternative is to keep building the campaign experience and stop building the prize engine. The agency still owns the client relationship, the creative, the frontend, the analytics and the consumer relationship. The sensitive backend, the part that has to be correct under load and defensible months later, runs on infrastructure built for exactly that and reused across every campaign.

With LuckLogic specifically, that looks like this:

Your backend posts the consumer's code to POST /v1/redemptions and gets back win or lose, a prize and a claim token. Every screen is still yours. See the docs.
Codes, batches, Winning Moments, locks, idempotency, limits, claims, webhooks, the entry log and the reconciliation report exist already and are the same on every campaign.
Pricing is per campaign, sized by code volume, so it is a line in the client budget rather than a subscription the agency carries between campaigns. See pricing.
Everything can be built and tested in the Sandbox before a client campaign is activated, including forcing a win to test the prize path.

What you give up is the custom-logic case. If the mechanic is not "a valid entry at the right moment wins a prize from a tier", LuckLogic is the wrong tool, and this guide would rather say so than have you find out in week three.

A short way to decide

Build it yourself when	Use infrastructure when
The mechanic is genuinely novel and cannot be expressed as tiers, quantities and release rules.	The mechanic is an instant win from printed codes or QR, with prizes released over a window.
The client requires the whole system on their own infrastructure, with no processors.	EU hosting, a data processing agreement and a processor that never needs consumer identities are acceptable.
You run one campaign and already have a tested backend from the last one.	You run several campaigns a year, for several clients, and the backend is rebuilt each time.
The prizes have no real value and a duplicate award costs nothing.	The prize table includes anything a duplicate award would make awkward.

Build the frontend. Don't rebuild the prize engine.

The quickest way to evaluate is to run the whole flow in the Sandbox: create a campaign, generate test codes, redeem them from a scratch backend, force a win and look at the claim and the stats. It takes an afternoon.

Open Sandbox For Agencies

Keep reading

How Winning Moments workThe mechanic, with a timeline and the edge cases. An on-pack campaign with the APIHow the pieces fit, from packaging to reconciliation. SecurityThe controls that run on every campaign.