Most guest-contribution features fail for the same reason: the owner sees everything immediately, so the moment never feels special. I wanted the opposite — a wall that fills up all season, stays sealed, and opens on one agreed date.
That idea became Deco My Tree: a free online Christmas tree you create in the browser, share as one link, and let friends hang ornaments that carry wishes. The messages stay locked until December 25. Until then you can see that someone hung something (and often who), but not what they wrote.
This post is a design note on that pattern: link-based guest contributions, sealed state, and a reveal-on-a-date boundary.
The product surface (what actually ships)
There is no app to install. You name a tree, pick from 8 tree styles and 6 toppers, then copy one URL or share it to WhatsApp, Messenger, Telegram, X, or Threads. Anyone with the link can open it on phone, tablet, or desktop.
Friends choose one of 20 ornaments (baubles, bell, candy cane, snowflake, envelope, cocoa, rocking horse, and more), write a wish, and hang it. When a page of 12 ornaments fills up, the tree grows another page so nobody is left off. Wishes can keep arriving until January 1, and the owner can stop accepting new ones any time in tree settings. Creating the tree, sharing it, and hanging wishes are all free. One tree per account each year; the look can change without losing the wishes already hung.
That is the whole loop. The interesting part is how the sealed state shapes the UX.
Why "sealed until a date" changes behavior
If every contribution is readable on arrival, the wall becomes a chat feed. People optimize for witty one-liners, and the owner checks it like email.
A sealed wall flips the incentives:
- Writers compose for a future moment. Knowing the owner will open everything on December 25 encourages longer, more personal notes.
- The owner watches progress without spoiling the gift. You see ornaments accumulate — the tree fills — but the content stays sealed. Progress is visible; meaning is deferred.
- The reveal is a ritual. Opening day is like unwrapping presents: one batch, one sitting.
On Deco My Tree, that contract is explicit in the product copy and FAQ: until Dec 25 every wish stays sealed; you may see who sent it, but not what it says. That single rule does more product work than a dozen feature toggles.
Link-shared guests without turning the tree into a dump
Open links are powerful and risky. The design choices that keep the wall usable:
Identity light, not identity-free
Friends sign in once to send a wish (social account, or phone number and password). That is enough to attach a reportable author without forcing a heavy onboarding. Owners also need an account to save a tree. Staying signed in on the device keeps the friction low for people who come back to hang another ornament.
Privacy defaults that match the metaphor
Every wish is private unless the writer opts in. Defaults:
- Only the tree's owner can read a wish.
- The writer can turn on "Let others read it" so visitors can read it once wishes open.
- "Hide my name" shows the writer as Anonymous, even to the owner.
That mirrors how people actually hang cards on a physical tree: some notes are for the host alone; some are meant for anyone who walks by.
Moderation without a control panel
Unkind content can be reported from the wish itself. Reports are private and reviewed. For a seasonal, link-shared space, "report on the object" beats burying tools in an admin dashboard most guests will never find.
Capacity that grows instead of rejecting
When branches fill, another page of 12 ornaments appears. Rejection ("tree is full") is the worst guest experience for a gift wall. Growth preserves the social promise: everyone who shows up gets to hang something.
Implementation shape (without inventing stack details)
You can map the UX to a few durable states:
| Concept | State |
|---|---|
| Tree | owner identity, style, topper, accepting / closed |
| Ornament | author (or anonymous), visibility, sealed payload |
| Time gate | now < Dec 25 → sealed; else → readable per privacy |
| Capacity | pages of 12; allocate next page when full |
The sealed payload is the key invariant: metadata (ornament type, optional name, hang time) can be public to the owner early; the wish body only unlocks after the gate. Public-to-visitors is a second gate that only applies after open day and only if the writer opted in.
Share is just a stable URL. No invite codes, no app install, no "request access" queue. The tree is the resource; the link is the permission surface for hanging; reading still respects owner/writer privacy rules.
Why this fits a developer audience
Seasonal products get dismissed as gimmicks, but the pattern is reusable:
- Cohort unlocks (course submissions that open after deadline)
- Team retros sealed until the meeting
- Gift exchanges / secret notes with a calendar boundary
- Guest books that fill during an event and publish afterward
If you are shipping any "many people contribute, one person (or group) opens later" flow, the sealed wall is a cleaner mental model than a live feed with a hide toggle. Put the date in the product contract, show progress without spoiling content, and keep guest entry as a single shareable link.
Try the loop
Make a tree, drop the link in a group chat, and watch ornaments appear while the wishes stay sealed. On December 25, open them together.
Start here: Deco My Tree.
If you have built something similar — time-gated guest content, anonymous-by-default notes, or growable walls — I would love to hear what broke in production and what you would change next season.
Top comments (0)