Last updated on August 7th, 2026 at 09:12 pm

Prize competitions and online raffles have quietly become a real UK sector over the last few years. Not a novelty, not a side hustle trend, but a category with operators turning over seven figures, running paid acquisition at scale, and employing people. Naturally, more businesses are looking at it and asking the obvious question: how hard can it be to build a competition website?

The honest answer is that the website is the easy part. The brief that most people write is a design brief, and design is the component that causes the fewest problems. What sinks launches is everything sitting behind the interface, and almost none of it appears on a standard ecommerce build spec.

A competition website is not an ecommerce website with different products

The surface resemblance is strong enough to be misleading. There’s a homepage, there are product pages, there’s a basket and a checkout. Underneath, the model works differently in three ways that matter structurally.

The product is an entry, not an item. Value is created at the draw, not at dispatch, which means the platform has to hold and reconcile state over the life of a competition rather than close a transaction and move on. And critically, the legal structure that keeps the business lawful lives inside the checkout flow itself. It isn’t a page in the footer. Get that wrong and you don’t have a compliance problem, you have a criminal classification problem.

That last point is what separates competition website design from general ecommerce work, and it’s why the discipline doesn’t transfer cleanly from a portfolio of retail builds.

Requirement one: the legal structure is architecture, not copy

Under Section 14 of the Gambling Act 2005, a prize competition is lawful without a Gambling Commission licence if entry requires a genuine element of skill, or if a free entry route of equal standing exists alongside the paid route. Free draws sit under a separate provision, Section 339.

The phrase doing the heavy lifting there is equal standing. Plenty of sites include a free entry route in the sense that it technically exists, buried three clicks deep in the terms, harder to use than the paid path, described in language designed to discourage anyone from taking it. That is exactly the pattern regulators have taken an interest in, and it’s a structural failure rather than a cosmetic one. If the free route isn’t genuinely usable and genuinely visible, the model collapses back into an unlicensed lottery.

Building this properly means the skill question is enforced at checkout on every paid entry, the free route carries the same question and the same visual prominence, and every free entry is logged and enters the same draw as paid entries with a record you could hand to a regulator. That’s a data model decision and a checkout flow decision. It cannot be retrofitted onto a finished build without touching both.

The bar has also moved recently. The DCMS Voluntary Code of Good Practice for prize draw operators, published in late 2025 with a May 2026 implementation deadline, added expectations around per-user spend limits, age verification, published draw dates, transparent odds and restrictions on credit card use for certain mechanics. Voluntary in name, but it’s the standard the sector is now measured against, and most of it has to be enforced at the platform level rather than promised in a policy.

Requirement two: payments have to be solved before the build, not after

This is the single most common way a launch stalls. Stripe, PayPal and Worldpay all classify competition and prize draw ticket sales as restricted or high-risk activity. Not because any individual operator is doing something wrong, but because the category as a whole carries chargeback and regulatory exposure they’ve chosen not to underwrite.

The usual sequence is that a business commissions a build, gets a finished platform, applies for payment processing, and then discovers it needs a specialist merchant account. The site sits idle for weeks while the application works through. Sometimes an account gets approved, takes live transactions, and is then closed retrospectively once the processor reviews what’s actually being sold, which is considerably worse than being declined upfront.

The fix is unglamorous: treat merchant approval as a parallel workstream that starts when the build starts, with the right specialist provider and the right documentation. There’s a downstream reason to care beyond going live, too. How the merchant account is structured affects Meta advertising eligibility, which payment methods you can offer, and how your banking holds up as volume grows. An account set up expediently at launch tends to become the constraint on scaling twelve months later.

Requirement three: you need a draw engine, and that’s software

Beneath the marketing pages, a competition platform is an operational system. Ticket caps and allocation. Per-customer entry limits that hold under concurrency. Randomised winner selection that can be independently verified, which is why random.org integration has become something close to a sector norm. Bulk entry pricing. Instant win mechanics, which carry their own compliance edges. An auditable record for every draw. A winner announcement page that satisfies both the CAP Code and the Voluntary Code.

Multiply that by several competitions running simultaneously from one dashboard and you’re describing a web application, not a website. This is where template and off-the-shelf approaches tend to fall over, not on day one, but at the point where an operator wants to run four draws at once and needs the numbers to reconcile.

Requirement four: infrastructure sized for the last hour

Competition traffic is not distributed. Entry volume clusters heavily into the final hours before a draw closes, where a site can reasonably expect something like ten times its normal load. That spike lands on the least cacheable parts of the stack: basket, checkout, remaining-ticket counts, live odds. A CDN protects the homepage. It does nothing for the pages that generate every pound of revenue.

Hosting therefore has to be provisioned for the peak rather than the average, and load testing has to reflect the shape of the event rather than steady-state traffic. Operators who skip this discover the ceiling on the night it costs the most.

Which build route makes sense

Three broad options exist, and the honest framing is that each shifts responsibility somewhere different.

A SaaS competition website builder gets you live quickly and cheaply. In exchange you’re on shared infrastructure, working within someone else’s compliance interpretation, limited on brand and layout, and typically paying a monthly fee plus a cut of transactions. You’re renting, and you don’t own the platform, the data or the customer relationship in any meaningful sense.

A WordPress template or Shopify setup gives you more design freedom and lower ongoing cost, but leaves the compliance structure, payment approval and draw mechanics entirely to you. It’s the route that looks cheapest and most often gets rebuilt.

A bespoke build costs more upfront and takes longer, and delivers a platform you own with the compliance structure and payment route handled as part of the project. Specialists exist here precisely because the domain knowledge compounds. Nera Marketing, for example, works only on UK competition and raffle builds, with packages starting at £2,995 and merchant approval managed alongside the build across 50-plus platforms delivered, which is a different proposition to a generalist agency solving each of these problems for the first time on your project.

None of the three is universally correct. A one-off brand campaign or a concept test doesn’t warrant a bespoke platform. A business intending to run continuously and advertise at volume will hit the ceilings of the other two routes, usually within the first year.

Realistic timelines and budgets

Four to eight weeks from brief to launch is a reasonable expectation for a properly structured build, with faster turnarounds achievable when payment approval is prioritised from day one. Budget in the low thousands for a compliant launch platform, rising with custom design and bespoke mechanics.

The thing worth internalising is where the money goes. Buyers instinctively price the visible work, the design and the pages, and treat compliance, payments and infrastructure as details to sort out later. In this sector that’s inverted. The interface is the cheapest problem you have.