Role
Lead, Accounts
Team
Founder and CEO (PRD), four engineers
Timeline
Aug 2026 to present
Tools
Figma, Claude Code, React, Supabase, Postgres
The account on desktop and a thank-you sent from a phone, both recorded on staging. Names blurred.
The short version
Problem
What I decided
Result
The account
Most accounts store a password and an address. DADO’s holds a member’s gifting life: what they gave, who they give to, the dates that matter and what they would love. I lead the whole account. Here it is, tab by tab.
01
Every wish a member runs, every gift they chipped in on, and the drafts they haven’t sent yet. Wishing, contributing and drafts sit in one list, so nothing they started gets lost.
Wishing
Contributing
Drafts
A walkthrough on staging: My Gifting, the occasions calendar, wishlists and account security. Parts showing colleagues or personal details were cut.
02
Not a plain calendar or a reminder list. An occasion is a date worth remembering. An event is a time and a place. Members add, change and delete their own, and can host an event by inviting other members, or people who aren’t on DADO yet.
Occasion: a date worth remembering
Event: a time and a place
Invite members and non-members
Adding an event on staging: the type, who it’s for, a location, a time zone and custom details, then an invitation that joins their calendar when they accept.
03
Add people the way you would on any social app, then mark the ones who matter most as close connections. You can add someone who isn’t on DADO yet. When they join, their account links to everything you saved about them. Each person gets a private note that only you can see, better than a phone’s contact card.
Important occasions
Wishlist
Gifting
Preferences & sizes
Family info
Profile
The connection profile screens and tabs were built with Anchal.
My Connections as shipped, filtered by close connections, family, friends and colleagues. Colleagues blurred.
04
A memory album of gifts, given and received, on DADO or anywhere else. Log a gift adds one from outside DADO, so the record stays complete. From a gift, a member can send another member a thank-you card with a personal message.
Timeline
Log a gift
Thank-you cards
Gift history on staging: the timeline, a closed wish, logging a gift from outside DADO and a thank-you card.
05 to 07
The quieter tabs that make the rest work: what a member wants, what caught their eye, and the facts about them that a good gift depends on.
05
Wishlists
Wishlists from DADO and from other platforms, kept together in one place.
06
Saved
Pieces saved while browsing DADO, kept apart from what a member wishes for.
07
Account details
Important dates, preferences and sizes, family information and the DADO profile. Each occasion and preference field carries its own audience.
08
Every part of the profile has an audience. Contact info can be seen by Only me, Close connections or Connections. Important occasions and preference fields carry their own audience, set on each item.
Only me
Close connections
Connections
Profile visibility, rebuilt from the shipped screen. Pick an audience and see what a connection and a close connection get back.
Making the promises real
Most account screens were designed, and few had been checked against the data behind them. A setting hid a name on the page while the server still sent it. Family tabs read fields nothing wrote to. Two-factor lived only in the browser.
Six controls: what the data did when I arrived, and what it does now.
Decisions
Decision 01
Why
Hide contributor names was saved and then ignored. Hide amounts raised was never saved at all. A setting that only hides something on screen still hands the data to anyone who asks the server.
What it cost
Two database changes and a rewritten public lookup. None of it shows in a Figma file. It shows when someone asks the server directly.
Preferences as shipped: who can see your contact info, and where DADO reaches you.
Decision 02
Why
Family and Occasions were blank for every connection, because the profile read fields nothing ever wrote to. Preferences showed six of ten fields. Anchal built the profile screens and tabs (PR #207). I built the data that fills them.
What it cost
Eleven database changes in the first pass. One shared list of family relations now drives the grid, the family screen and who can see what.
Before and after: the profile read empty fields. Now it reads what members save, within the owner’s own settings.
Decision 03
Why
Notifications saved only who received them, so the bell showed an icon and nothing else. Now each one records who caused it, read through a small profile lookup that returns four fields.
What it cost
My first version exposed whole profiles to anyone named in a notification. I reversed it the same day, so one change became two.
The bell as shipped, and a thank-you sent on a phone: pick a card, write the note, and the card opens on a page of its own. Names blurred.
Decision 04
Why
A QA pass turned into a security pass. The leaks ranged from phone numbers and shipping addresses to anyone being able to write payment records. I confirmed each one on the live database before fixing it, and checked each fix the same way.
What it cost
None of the 38 users had two-factor on, so I confirmed live that the change locked nobody out. Sessions older than the window now see an error, logged as a follow-up.
| Where | What leaked | The fix | Status |
|---|---|---|---|
| Connection profile | What leakedAny signed-in user, by adding themselves as a contact | The fixNeeds a connection both people accepted, which cannot be faked. | Closed |
| Personal details | What leakedFull name, phone and birthdate to any signed-in user on a public wish | The fixA display-only lookup that returns four safe fields | Closed |
| Invite lookup | What leakedThe whole wish record, shipping address included | The fixA fixed list of safe fields, with no shipping address and no minor’s consent record | Closed |
| Explore page | What leakedRecipient addresses to anonymous visitors | The fixOnly safe fields are returned, never the whole record | Closed |
| Transactions | What leakedAny user could write payment records | The fixBrowsers can no longer write payment records. Only the payment processor can. | Closed |
The five leaks, what each exposed, and the fix. Engineers on the team confirmed every fix. There has been no outside audit.
Also decided
01
A member’s birthday shows on both connection views, behind the one important-dates setting they control.
02
Thank-you cards are saved, notify the giver and open from a private link, so someone without an account can see one.
03
Paying, adding a card and deleting the account all need two-factor confirmed on the server.
04
Setting a default card or address happens in one step that cannot half-fail. Deleting a card also removes it at Stripe.
05
Notification toggles show a toast and revert when a save fails, instead of failing silently.
06
Deactivate and Delete are real actions. Deletion is scheduled, and signing back in cancels it.
Full decision traces available on request.
Outcome
6
account controls made to do what they promise
5
live leaks closed and verified on production
10
preference fields on a connection, up from 6
0
members locked out when two-factor moved
The beta is private, so how members use the account is not measured yet, and there has been no outside security audit.
Reflection
Reading the logic behind each screen found all six broken promises. None of them were visible in Figma.
The team’s 307-case QA workbook, run by twelve people before the beta, logged two of the five leaks on its own.
What I kept
The dossier was redesigned, and then its tabs turned out empty for a data reason. Next time I would reverse the order.
