Sound Quest Phase 2

Inspiration

Our inspiration for Phase 2 came from a single, tough question: "So what?" We had a beautiful, functional dashboard from Stage 1, but we were inspired by the (real or imagined) feedback of a critical judge: "A dashboard is a passive tool. Your game looks like a cost center. How does this make money?” This question forced us to pivot. We weren't inspired to add more features; we were inspired to prove our business model. Our new goal was to show that our "Rewards" system wasn't a gimmick, but the core of a powerful Data Factory.

How we built it

In Phase 2, we stopped adding new screens and focused on making our existing UI prove our new strategy. Our build process was about modifying our UI to become the "Data Factory" we described. Modified the UI: We immediately mocked up two critical changes to our Dashboard UI. The Incentive (Game): The static "Sound Quest" banner was replaced with a Dynamic Widget: "You have [ 3 ] tickets! Pay your next bill to earn [ 5 ] more." The Action (Factory): The passive "Payment Due" text was replaced with an Active Call-to-Action: [ Pay Now & Win 5 Tickets! ] Defined the Tech: We solidified our lightweight tech stack to support this data-first approach. Front-End: React (to build the dynamic UI components). Back-End: Serverless Functions (to instantly analyze the "Repay Log" and trigger the Cross-Sell Engine). Data: Plaid API (for "Cold Data") and a Mocked Partner API (for benefit rules).

Challenges we ran into

Our biggest challenge in Phase 2 was a strategic disconnect. Our new pitch was all about the "Data Flywheel," but our old UI didn't look like it. Our original Dashboard was passive. The "Sound Quest" banner was just a pretty picture, and the "Payment due" was just a line of text. There was no visual connection between the game and the user's action. We overcame this by realizing the UI itself had to tell the story. The challenge wasn't just "How do we build it?" but "How do we make it obvious?" The solution was the two UI modifications we built today. By adding the [ Pay Now & Win 5 Tickets! ] button, we visually "welded" our game (the incentive) to our core business action (the repayment). This small UI change solved our biggest strategic problem and made our entire pitch click into place.

What we learned

Our "Aha!" moment in Phase 2 was realizing that our "Game System" and our "Data Flywheel" had to be the same thing.We learned that the most valuable asset we could create isn't the UI; it's the "Hot Data"—the behavioral data—that Plaid and other APIs can never provide.Plaid (Cold Data): Tells us a user has a Chase card.Our Game (Hot Data): Tells us a user actively repaid their Chase card, why they did it (to win tickets), and which reward (Seahawks tickets) they truly desire.This led to our breakthrough strategy, which we visualized in a simple equation:$$[Rewards \ (Cost)] \rightarrow [Behavioral \ Data \ (Investment)] \rightarrow [Cross-Sell \ (ROI)]$$We learned that the "Game" isn't a cost; it's an investment in acquiring the data needed for the Cross-Sell Engine to function.

What's next for Sound Quest Phase 2

Phase 2 focuses on building the true Minimum Viable Product (MVP) of our "Data Flywheel." This means connecting our existing UI to a lightweight, serverless backend. We will stop mocking the core loop and start building it: We will develop the dynamic "Repay & Win 5 Tickets!" button to actually capture the "Repay Log," build the first simple "Rewards" page to deliver the prize, and deploy the first automated "Cross-Sell" trigger. This MVP will be the first working prototype of our "game = data factory" strategy.