Droplet Rewards
Droplet Rewards is a customized browser extension that helps your audience save money while you earn commissions on their purchases.
Stack: Next.js, Clerk, Neon
The Observation
Every few weeks, the creators I follow would post a quick story: "A lot of you have been asking about my discount codes, so here they all are." Twelve slides. Forty brands. Gone in 24 hours.
I understood why they did it. It was the cleanest answer to a recurring question. But watching it, I found myself wondering whether anyone was thinking about what happens after the story disappears. The followers who were genuinely interested in those brands, who shopped those stores regularly, had no mechanism to remember a code existed at all. The creator got a commission spike for a day, and then the audience went back to paying full price. The relationship between that creator's influence and actual consumer behavior was essentially invisible.
That gap is what Droplet Rewards is built to close.
The Problem
Influencer marketing has a measurement problem, and the discount code workflow sits at the center of it. Creators post codes when followers ask. Followers use codes when they remember. Brands see a conversion number with no real context around it. Nobody in that chain has an accurate picture of how much purchasing power actually flows through a creator's audience.
The result is that creators negotiate brand deals on instinct rather than evidence. They know their follower count and their engagement rate, but they cannot tell a brand: "my audience spent $180,000 across your category last year." That number, if they had it, would change every conversation they walk into. Instead, they're selling attention when they could be selling demonstrated purchasing behavior.
The periodic story dump is the band-aid solution the industry landed on, and it works just well enough that nobody built anything better.
The Solution
Droplet Rewards is a white-label discount automation tool built specifically for creators, modeled conceptually on what Honey does for general consumers, applied to the influencer-audience relationship.
A creator signs up, uploads their promo codes, and we build a branded Chrome extension their followers can install. From that point forward, every time a follower visits a store the creator has a code for, the discount is applied automatically. The follower gets the savings without having to remember anything. The creator receives purchase data, specifically the store and the amount spent, every time that happens.
The architectural decision that defined the most interesting technical challenge was where to store the checkout detection logic. To apply a code at the right moment, the extension needs to know it's on a checkout page, and stores do not agree on how to label that. A Shopify storefront might structure it one way; a retailer running on Aptos structures it differently; a custom-built checkout might do something else entirely. Every store a creator has a code for needs to be mapped individually, and those mappings change when platforms update their layouts.
The tempting option was to bundle that logic inside the extension itself. It would be simpler to build initially. But it would also mean that every time a store changed its checkout flow, fixing it would require pushing an extension update and waiting for users to accept it. I chose instead to store all of that detection logic server-side, called at runtime. It adds a layer of infrastructure, but it means I can adjust to changes in real time without touching the extension. For a product where reliability is the entire value proposition, that tradeoff was not a close call.
Each creator gets their own auto-generated REST API. The extension is currently a manually adjusted template with per-creator customization built in, giving creators some control over how it looks and feels. Auto-generation of the extension itself is the next infrastructure milestone.
The stack is full-stack Next.js, with Neon for Postgres and Clerk handling authentication. Both were new to me on this build. Neon's serverless Postgres model fit cleanly with the per-creator API structure, and Clerk handled the auth layer in a way that let me move faster than rolling something custom would have. Getting familiar with both while building a product with real moving parts was a worthwhile tradeoff, and neither gave me a reason to wish I had chosen differently.
Where It Stands
Droplet Rewards is live and in beta. The focus right now is finding and fixing edge cases before a broader rollout, and the most direct path to real-world testing is getting actual creators using it. I am actively reaching out to creator agencies to identify clients who want early access.
The foundation is in place: the infrastructure handles the core loop, the server-side store detection is working, and the creator customization layer is functional. What comes next is proving the data story. Once creators start seeing their audience's actual purchasing behavior aggregated over time, that's when the product earns its full argument.