DADO · One Big Wish · Payments and consent
Someone asks for one wish, and the people around them pledge toward it. Contributors authorize once and are charged days before the gift, which means strangers’ money, months of waiting, and a promise that has to survive both.
Outcome
Surface
The wish wizard and the contribution rail
Timeline
Jul to Sep 2026
Tools
Figma · FigJam · Claude Code · Stripe · React / TypeScript
steps in the wish wizard, ending on a funding review
steps in the contribution rail, amount to confirmation
states shown here, of 8 in the audited lifecycle
minimum charge notice, enforced by the database itself
The decision: authorize now, charge at the moment.
The first build charged contributors immediately: DADO held group money for months, and every edge case became a money-in-hand problem. It worked, and it collided with a hard constraint: DADO can’t hold customer money, because holding it means acting as a bank. After that, authorization-first was the only real option, and it protects contributors from paying for a gift that’s never bought.
DADO doesn’t refund contributions. So the model had to make refunds unnecessary: the card is only saved at contribution time, every contributor is warned before the batch run, and a missed goal still ends in a gift.
The redesigned model inverts the first build: contributing runs 3DS and saves the card against a Stripe mandate, and the charge waits. It comes as a batch run anchored to the gift’s moment date, 7 to 10 days before it, when the order is placed. Before any card is touched, every contributor gets the promised email. An authorization moves through its life like this:
The under-funded wish became a simple choice: nobody has been charged yet, so the wisher decides. Either way, every contribution still ends as a gift.
- Complete it yourself: the wisher pays the gap and the wish completes.
- Keep what you raised: the raised amount becomes a digital gift card.
- Do nothing: after two days the gift card is the default.
The contradiction I wouldn’t ship.
The Terms promised every contributor an email at least 3 days before their card is charged. The admin console was specified with a charge-now button. The two couldn’t both be true for long.
The Terms promised
An email at least 3 days before any charge.
vs
The console spec asked for
A charge-now button.
The database enforces the fix, so the console can’t break it.
An authorization can’t enter charging unless its notice went out at least the notice period ago.
The console schedules charge runs and sends notices, with no path to fire a charge directly.
One break-glass path exists for genuine emergencies. It requires two employees and writes a loud audit record.
Consent designed like infrastructure.
Figure 1. The review step after the contributor ticks the checkbox, which starts unticked and names the amount and the delay.
When a charge lands months after the click, everything rests on what was disclosed at the click. So the review step carries it above the button, always fully visible: no money is taken now, the exact amount, when the charge happens, the maximum delay, the 3-day notice, what happens if the wish fails, and the statement descriptor the contributor will see at their bank. The checkbox starts unticked, blocks the button, and names the amount and delay in its own text. Substitution consent sits on the same screen in plain language. And the record grew up: a single boolean became a full consent event storing the exact disclosure text shown, its version, the Terms version, and the timestamp, retained for seven years.
The edge cases.
The two flows and the progress bar.
Making a wish takes five steps. The last one reviews how funding works before the wish goes live.
View the full One Big Wish user flow →
Contributing is a separate four-step rail: Amount, Payment, Add a note, Confirmation. The confirm button reads “Authorize contribution,” because that’s what happens.
Guests contribute too, with the same consent
A wish shared by link accepts guests. A guest gives a name, an email, and a date of birth, verifies the email with a 6-digit code, and authorizes exactly like a member. DADO checks the date of birth against the age rule and discards it. The emailed manage link is the guest’s only credential.
The progress bar counts pledges
Under the authorization model, “raised” means promised money. The bar sums live pledges, and the number is deliberately unclamped: it keeps counting past 100%. Try the three states:
Figure 2. The wish progress bar at three real states from staging. Over goal, the bar is split at a 100% pin. A privacy variant hides the raised amount and shows only the goal, and the dates in the staging card are test values.
Where things landed.
One Big Wish shipped as one of DADO’s three launch products. The launch drew 4,100 users from 5,000 invitations. Numbers for One Big Wish on its own come next.
What I’m watching:
Contribution completion through the rail
Withdrawal rate around the charge notice
Charge-run success and grace recoveries
The under-funded rate
Reflection
The scariest scenario here is a stranger’s card getting charged months after a click. So when it happens, it arrives announced and itemized, with consent on record. The open question is whether 3 days of notice is enough. I’d want the first charge runs to settle that before the number is treated as fixed.
Project takeaways.
Next case study
Requesta, an AI question generator for educators
Read the case study →
← Back to DADO
Anchal Nagdev