BrandQuest - Playable Ads. Real Rewards. Measurable Engagement.

Inspiration

Most online ads are easy to ignore. We skip them, scroll past them, block them, or forget them a few seconds later.

But people do not ignore games in the same way. People replay simple browser games for better scores. They check leaderboards. They collect badges. They come back when there is a reward or a challenge worth trying again.

That contrast became the starting point for BrandQuest.

What if brand engagement felt less like an interruption and more like a game people actually wanted to play?

We wanted to build an ad experience where the user gets something back for their attention. Instead of a passive banner or video, BrandQuest lets a brand launch a playable campaign. Players compete, earn XP, chase rewards, and the brand gets real engagement data instead of just impressions.

The idea is simple: if a brand wants attention, the experience should be worth interacting with.

What it does

BrandQuest is a full-stack platform for playable ad campaigns.

Brands create mini-game campaigns with rewards. Players discover those campaigns, play the games, submit scores, climb leaderboards, and track their progress. Creators can then see measurable engagement from every campaign attempt.

For players, BrandQuest feels like a small arcade of branded challenges. They can:

  • browse live campaigns
  • play skill-based mini-games
  • submit scores
  • compete on leaderboards
  • earn XP, badges, and rewards
  • view past participation and profile progress

For creators and brands, BrandQuest works like a campaign builder. They can:

  • create a branded campaign
  • choose a playable template
  • configure rewards, attempt limits, rules, difficulty, and dates
  • view only their own campaigns
  • track attempts, unique players, top scores, repeat play, and funnel analytics
  • submit custom game ideas for review

For admins, BrandQuest adds a safety layer. Custom game submissions are reviewed before they can go live, so the platform does not blindly run unsafe uploaded code.

User Main experience Why it matters
Players Play branded challenges, submit scores, earn XP and rewards Ads become something they choose to interact with
Creators / Brands Launch campaigns, configure rewards, track analytics Engagement becomes measurable beyond clicks
Admins Review custom game submissions before launch The platform stays safer as custom games grow

The core product loop looks like this:

Create campaign
      |
      v
Player joins game
      |
      v
Score is submitted
      |
      v
Backend validates attempt
      |
      v
Leaderboard updates
      |
      v
Rewards and analytics update

The playable templates include Brand Quiz, Memory Match, Reaction Tap, Word Scramble, Pattern Recall, Beat Tiles, and Brand Rush Runner. Each template is designed to produce a measurable game attempt that can feed into a leaderboard and campaign analytics.

Quick judge walkthrough 1. Open the live app and choose a player or creator path. 2. As a player, browse campaigns and try a game. 3. Submit a score and see how the leaderboard turns the ad into a competition. 4. As a creator, look at the campaign setup and analytics flow. 5. Check the custom game review idea to see how BrandQuest handles safety before letting new formats go live.

How we built it

We built BrandQuest as a real backend-first product, not a static mockup. The interface is playful, but the important work happens behind the scenes: authentication, campaign ownership, attempt validation, leaderboard updates, analytics, and custom game review.

The stack is built around:

Layer What we used Why
App and UI Next.js App Router, React, TypeScript, Tailwind, shadcn/ui Fast full-stack development with a polished player and creator experience
Hosting and auth Vercel, Auth.js, Google OAuth, protected admin credentials Clean deployment plus separate player, creator, and admin access
Data and trust Amazon DynamoDB, Zod, server-side score checks Scalable campaign data with validation, ownership checks, and anti-cheat rules

Architecture

BrandQuest is designed around one main idea: the client can play the game, but the server decides what counts.

                         BRANDQUEST ARCHITECTURE

  +--------------------+      +--------------------+      +--------------------+
  |      Players       |      |  Creators / Brands |      |       Admins       |
  | play games, earn   |      | build campaigns,   |      | review custom game |
  | XP, claim rewards  |      | review analytics   |      | submissions        |
  +---------+----------+      +---------+----------+      +---------+----------+
            |                           |                           |
            +---------------------------+---------------------------+
                                        |
                                        v
  +-------------------------------------------------------------------------+
  |                         Vercel + Next.js App                            |
  |                                                                         |
  |  +--------------------+     +--------------------+     +-------------+  |
  |  | Next.js UI         | --> | Auth Layer         | --> | Server      |  |
  |  | player arcade,     |     | Google OAuth +     |     | Actions +   |  |
  |  | creator dashboard, |     | protected admin    |     | API Routes  |  |
  |  | admin review       |     | credentials        |     |             |  |
  |  +--------------------+     +--------------------+     +------+------+  |
  |                                                               |         |
  |                                                               v         |
  |                         +---------------------------------------------+ |
  |                         | Validation + Anti-Cheat                     | |
  |                         | Zod, ownership checks, attempt limits,      | |
  |                         | campaign dates, score rules                 | |
  |                         +----------------------+----------------------+ |
  +------------------------------------------------+------------------------+
                                                   |
                                                   v
  +-------------------------------------------------------------------------+
  |                         Amazon DynamoDB                                 |
  |                                                                         |
  |  Users + Profiles   Campaigns + Templates   Attempts + Leaderboards     |
  |  Analytics Events   Rewards, XP, Badges     Custom Game Reviews         |
  +-------------------------------------------------------------------------+

In plain English, the player experience and creator dashboard both go through the same trusted backend layer. That backend checks who the user is, whether they are allowed to perform the action, whether a campaign is live, whether an attempt is valid, and whether the score should count.

DynamoDB stores the product data that makes the platform feel real:

  • users, player profiles, and creator profiles
  • campaigns and playable templates
  • attempts and leaderboard records
  • participation history
  • XP, levels, badges, and rewards
  • analytics events for views, starts, completions, repeat play, and suspicious attempts
  • custom game submissions and admin decisions
Why DynamoDB fit BrandQuest BrandQuest creates a lot of event-heavy data: game attempts, score submissions, reward updates, analytics events, and leaderboard reads. DynamoDB made sense because the app is built around fast access patterns like: - list live campaigns for players - list campaigns owned by a creator - get attempts for a campaign - build a leaderboard - get a player's participation history - calculate campaign analytics - review pending custom game submissions Security and anti-cheat choices - Scores are validated on the server before they reach the leaderboard. - Attempt limits and campaign dates are checked server-side. - Creators can only access campaigns they own. - Admin review routes are separated from normal onboarding. - Custom games are metadata-first and require approval. - Uploaded JavaScript is not executed directly. - AWS credentials stay on the server and are never exposed in frontend code.

Challenges we ran into

The biggest challenge was realizing that playable ads are not just a frontend idea. They are a fairness problem, a data problem, and a security problem.

It was easy to imagine the fun parts: the arcade, the branded games, the rewards, the leaderboard. The harder part was making those pieces trustworthy. Once rewards are involved, we cannot treat a score like a casual client-side number. We had to think about fake scores, duplicate attempts, expired campaigns, creator permissions, and custom games that should not be allowed to run without review.

DynamoDB modeling was another challenge. We had to design around the questions the product needs to answer:

  • What campaigns are live right now?
  • Which campaigns belong to this creator?
  • Who is winning this campaign?
  • What has this player already played?
  • Which attempts look suspicious?
  • What did a campaign actually achieve?

The custom game flow was also tricky. Letting creators upload arbitrary JavaScript would be unsafe, so BrandQuest uses an approval-first model. In the future, custom games can run inside a sandboxed iframe with a secure score API, but for this version we focused on the safer foundation.

Accomplishments that we're proud of

We are proud that BrandQuest feels like a complete product loop instead of a one-screen demo.

Players can understand the value quickly: play a game, submit a score, compete, and earn progress. Creators can understand the business value: launch campaigns and measure active participation instead of passive impressions. Admins give the system a realistic safety layer for future custom games.

The pieces we are proudest of are:

  • a player arcade that makes campaigns feel discoverable
  • a creator flow for configuring campaigns and rewards
  • server-validated score submission
  • leaderboard logic designed around fairness
  • DynamoDB-backed product data
  • analytics that reflect real engagement signals
  • an admin review model for custom games
  • multiple playable templates instead of a single hardcoded demo

The most satisfying part was seeing the full loop work:

campaign -> game -> attempt -> validation -> leaderboard -> reward -> analytics

That loop is BrandQuest.

What we learned

We learned that a good playable ad platform has to respect both sides of the experience.

For players, it has to feel fun and fair. If the game is boring or the leaderboard feels fake, the reward does not matter. For creators, it has to produce useful signals. A campaign should show more than "someone clicked." It should show who played, how often they tried, whether they completed the challenge, how they ranked, and whether they came back.

We also learned how important it is to design the backend early. A playable ad seems simple until it has rewards, leaderboards, role-based dashboards, admin review, and analytics. Then the backend becomes the product.

The biggest lesson was this:

Interactivity is only valuable when it creates trust, feedback, and measurable outcomes.

What's next for BrandQuest

Next, we want to make BrandQuest feel even closer to a real playable ad network.

The next version would add:

Area What we want to add next
Play More templates for puzzles, timing challenges, product discovery, social competitions, and team campaigns
Trust Sandboxed custom games, secure score APIs, stronger fraud detection, and safer reward redemption
Growth Verified brand pages, richer analytics, reward inventory, winner notifications, and a campaign marketplace

Long term, BrandQuest could become a new kind of advertising platform: one built around participation instead of interruption.

Playable ads. Real rewards. Measurable engagement.

Built With

Share this project:

Updates

Submission history