# Ripply Case Study: Viral Waitlist Platform Source: https://www.plutonapps.com/work/ripply Published 2026-09-22, updated 2026-10-23. By Irfan Habib (https://www.plutonapps.com/authors/irfan-habib). A viral waitlist platform in two halves: a launch builder any brand can use — pick a template, make it theirs, go live on their own web address, no code, no designer, no wait — and a private console the founder runs the whole business from: payments, refunds, support, incidents and the audit trail. He designed both halves in Lovable on our Starter plan. We built everything underneath — a queue that cannot collide, rewards that go out exactly once as gift cards, merchandise or shop codes, wallet passes for the front of the line, and thirty-day erasure when someone asks to be forgotten. ## At a glance Ripply (formerly Ekko) is a viral waitlist platform: a no-code launch builder brands use to run waitlists with real rewards, and a private console the founder runs the business from. The founder designed both halves in Lovable, on the Plutonapps Starter plan; Plutonapps engineers built the system underneath in 36 working days. Stress-tested with 25,000 synthetic waitlist entries, it sent zero duplicate rewards. Ripply is pre-launch. - **Product:** Viral waitlist platform (B2B SaaS) - **Designed in:** Lovable, by the founder - **Plan:** Plutonapps Starter plan - **Stack:** React · PostgreSQL · Edge - **Build time:** 36 working days - **Compliance:** GDPR - **Status:** Pre-launch, launching in 2026 Product site: [getripply.app](https://getripply.app) **0** Duplicate rewards sent.. 25,000 synthetic waitlist entries pushed through the queue under load, with four locks in a row on anything worth money. Not one gift card, parcel or shop code went out twice. > I designed both halves in Lovable in two weeks, and people wanted to sign up on the spot. If I had launched it myself, the first viral spike would have collided the queue and paid the same reward out twice. Plutonapps turned my prototype into a company that can actually take the traffic. > > — Founder, Ripply ## What did the founder design in Lovable? The founder designed the entire product in Lovable in under two weeks, on our Starter plan: the page builder, the template gallery, the automation editor, the reward screens, the participant portal and his own admin view. It was not a brief or a mockup. It was the whole product, drawn end to end, and early customers tried to sign up on the spot. Our job was to make every pixel of it real. ## Why could it not go live as it was? Viral is a nice word for a traffic spike. Fifty thousand people can join in ten minutes, and each one must get one exact position — a collision becomes a public argument on social media. Every reward on the end of an automation is worth real money: a gift card, a cash payout, a t-shirt in the post, a discount code in someone's shop. Send one twice and the founder pays for it. The page each brand builds runs on strangers' phones and inside other companies' websites, where a slow script gets the whole product banned. And the founder needed to run all of it — payments, refunds, support, deletions, failures — without leaving one screen or asking an engineer for a query. None of that exists until someone builds it. ## Product decisions ### Half one: the app brands use Brands pick a template, set their colors and fonts once, and every page — landing, sign-in, verify — restyles to match. Text is edited by clicking it. Desktop, tablet and phone are one toggle apart. They can put the campaign on their own web address, and the whole thing goes live without anyone writing code. ### Half two: the founder's console A separate, private deck at its own address: every workspace and customer, subscriptions, refunds, failed payments, support tickets, job and webhook backlogs, incidents, moderation, announcements, data exports and the full audit trail. There is a search box that opens anything on the platform by name or invoice number, and switches that turn a misbehaving feature off without a release. He runs the company from it. ### Rewards people actually want Three kinds, all fulfilled on their own: gift cards and cash paid straight out, custom merchandise printed and posted, and discount codes created inside the brand's own shop. Add an Apple or Google Wallet pass for the people at the front of the queue, scannable at the door on launch day. ### Automations written as sentences Someone signs up, they invite friends, they become an ambassador, they get rewarded. Brands set the threshold and pick the reward; the rule does the rest and shows its full history — what fired, when, and what happened next. ### Metrics that explain the growth Not a page-views chart. Spread — how many people the average member brings. Depth — how far the longest referral chain reaches. Network health, top referrer today, and a referral tree you can open and walk person by person. ## What did Plutonapps engineer? ### A queue that cannot collide Risk in the prototype: Fifty thousand people can join in ten minutes, and two of them getting the same position becomes a public argument on social media. Positions are assigned by the database itself, in one atomic step, never calculated in code that can race. Ten people or ten thousand in the same minute, every position is exact, unique and provable — and the live count updates without a refresh. ### No reward ever goes out twice Risk in the prototype: Every reward is real money — a gift card, a cash payout, a t-shirt in the post. Send one twice and the founder pays for it. Four locks in a row protect anything worth money. Each payout gets one permanent name derived from the person and the reward, so every retry lands on the same slot. The payment provider is handed that same name and refuses a duplicate. Incoming confirmations are recorded once and only once. And if a worker dies mid-payment, the slot is held for five minutes, then safely reclaimed and retried. Under load testing, not one duplicate got out. ### Their own web address, working in seconds Risk in the prototype: Brands expect their campaign on their own domain, without raising a ticket or waking up to an expired certificate. A brand points its domain at the campaign and the certificate is issued and installed automatically, with the page served from the edge network nearest each visitor. No tickets, no waiting, no expired certificate at midnight. ### Pages that render anywhere, fast Risk in the prototype: The page runs on strangers' phones and inside other companies' websites, where a slow script gets the whole product banned. Whatever a brand builds compiles into a self-contained page with no layout shift, and into an embed that loads fast, never touches the host site's styles and cannot see another brand's data. It renders in under 35 milliseconds on customer sites. ### Shops that stay in step Risk in the prototype: A discount code that lives only in the campaign, and not in the brand's real shop, is a reward nobody can actually use. Discount codes are created natively inside Shopify, WooCommerce, Wix and WordPress — money off products, money off the basket, buy-one-get-one, free delivery. Paid orders mark the reward as used; cancellations and refunds pull the code back. Every fifteen minutes the system re-checks recent orders, so a dropped message never leaves a reward in limbo. ### An AI builder that does not cost a fortune Risk in the prototype: Letting a model write raw pages is expensive on every generation and quietly produces broken, off-brand layouts. Instead of asking a model to write raw code, the builder fills a fixed set of brand-safe building blocks. It cuts the cost of each generated page by more than four fifths and, more importantly, the result is always accessible, always on brand and never broken. ### A locked door the internet cannot find Risk in the prototype: The founder runs the whole business from one private console — a login screen on a guessable address is an invitation. The founder's console lives on its own address, and anyone who is not on the allow-list gets a plain page-not-found — not a login screen to attack. Names on the list get only the powers their role needs, and anything destructive asks for a second factor again before it runs. Every action is written to a log that cannot be edited. ### Deleting someone properly Risk in the prototype: When a person asks to be erased, half-deleting them across payments, logins, artwork and passes is a breach waiting to happen. When a customer asks to be erased, the request is scheduled with thirty days to change their mind and a one-click cancel link in their inbox. After that, everything goes: records, uploaded artwork, wallet pass files, profile photos and the accounts held at the payment and login providers. The history log survives with the personal details scrubbed out of it, so the business keeps its books without keeping the person. ## What were the results? - **25,000** Synthetic waitlist entries in the queue stress test - **0** Duplicate rewards or queue collisions under load - **<35ms** Widget render on customer sites - **36** Working days to build ## Outcomes - 25,000 synthetic waitlist entries stress-tested with zero queue collisions. - Zero duplicate rewards issued across gift cards, merchandise and shop codes under load. - One console for payments, support, incidents and deletions — no other tool to open. - Launching in 2026 — built, hardened and operated by us on the Starter plan. ## What do we hold ourselves to while it runs? - **Queue integrity:** Atomic positions, enforced by the database - **Rewards:** Four locks so money never goes out twice - **Own web address:** Certificates issued and served at the edge - **Privacy:** Thirty-day erasure with an unbroken audit trail ## What else do people ask about Ripply? ### What is Ripply? Ripply (formerly Ekko) is a viral waitlist platform in two halves: a no-code launch builder brands use to run waitlists with real rewards, and a private console the founder runs the whole business from. ### Who built Ripply? The founder designed both halves in Lovable, on the Plutonapps Starter plan. Plutonapps engineers built everything underneath: the queue engine, rewards and payouts, custom web addresses, shop integrations, wallet passes and the console with its safety rails. ### How was Ripply tested before launch? The queue was stress-tested with 25,000 synthetic waitlist entries, with zero queue collisions and zero duplicate rewards across gift cards, merchandise and shop codes. ### Is Ripply live? Not yet. Ripply is pre-launch: built in 36 working days and being hardened by Plutonapps for launch in 2026. ## Sources - [Ripply's own site, getripply.app](https://getripply.app)