Breadcrumbs is a social app I have been designing and partly building around a small daily exchange: a few things from your day, shared with a specific group, released together, and gone after 24 hours by default.
My favorite group chats rarely feel like publishing. Someone sends a terrible library photo, someone else sends dinner, and that is enough. I wanted to make that easier without creating another feed to maintain.
This is an unfinished prototype. The clearest development record is from March 2026: photo upload, draft saving, and a daily counter. Scheduled release, group rules, and the location trail remain design work.
The rule I started with
The original rule was five items per day, per group. Text, photos, and short videos would collect during the day, publish at a time chosen by the group, and expire a day later. Each group would have its own audience and schedule.
Five was intuition: enough room for ordinary details without an endless stream. I had no experiment showing it was right.
That left a contradiction I had not resolved. Some early notes treat five as a maximum. The draft implementation notes describe reaching five as the condition for being ready to publish. Those are different products. A limit says “you can stop here.” A requirement says “you still owe us two photos.”
The second version could recreate the pressure I wanted to avoid. I need to test whether five feels like permission to share less or an obligation to fill every slot.
What reached the prototype
The March 13 development notes describe a photo flow backed by Supabase. A helper reads the captured image from the device, uploads it to storage, creates a post with draft status, and increments the day's submission count. The camera pane shows a loading state followed by a saved or failed badge. The feed shows a per-group count such as two of five drafts saved.
The group IDs were explicitly placeholders. A working capture interaction does not establish invitations, private membership, or automatic publication.
| Part | What the record supports |
|---|---|
| Capture and upload | Notes describe a photo-to-storage path and UI feedback |
| Draft saving | Notes describe a post insert and daily counter update |
| Group selection | UI wiring described; group IDs were placeholders |
| Data model | Proposed SQL for membership, posts, reactions, and daily counts |
| Scheduled publishing and expiry | Designed behavior; no verified running scheduler in the record |
| Location trail | Proposed table and feature idea, not a demonstrated feature |
A group is the audience
Combining my family, friends from home, and basketball friends into one audience makes me write for whoever needs the most explanation, or not post.
Breadcrumbs would ask me to choose the group before posting. Memberships connect people to groups, and posts carry both an author and a group. Daily limits are scoped by person, group, and date: family posts should not use my friends-group slots.
That model still needs rules for leaving a group, removing a member, and deciding whether new members can see retained posts. “Private groups” is a product promise; the database has to enforce the same boundary on every read and write.
One post has a lifecycle
The draft schema gives a post four states:
draft → queued → published → expired
A draft is private preparation; a queued post is ready for release. Publication begins visibility, and expiry ends it. Saving something and showing it to other people are different actions.
A separate daily_submissions counter preserves how many slots someone used even after deleting a post. Whether deletion should consume a slot is a design choice, not something a technical convenience should settle.
A counter introduces a consistency problem too. If saving the post succeeds and incrementing the count fails, the interface and database disagree. If a request is retried, the app should not count it twice. A real implementation needs one reliable operation for reserving the slot and inserting the post. The notes describe both actions, but do not establish those guarantees.
Someone has to set the time
A group leader would choose the release time. Someone can explain the choice and change it after a conversation, which seems manageable for a few friends.
What if the leader stops using the app? What does 9 p.m. mean when half the group is traveling? Do late publications still get 24 hours?
The proposed table stores a time of day without a group timezone. I still need to define that timezone, the date of each daily batch, and a release operation that is safe to retry.
I also remain unsure about missing the window. Withholding that day's batch might create a shared rhythm, or just punish the person with a long lab or an evening shift. The rule needs to earn its place through use.
Expiry needs a precise meaning
The default is 24-hour visibility, with retention a group choice. I hope temporary posts feel easier to send, but have no user evidence yet.
“Gone” could mean hiding an item, denying image access, or deleting both the row and stored file. A status field alone does not make a photo disappear.
The early SQL illustrates this. Its proposed post-read policy checks group membership, but does not itself restrict results to published, unexpired posts. It is a design draft, not a reviewed privacy implementation. Before using real groups, I would need to check draft visibility, storage access, and deletion behavior together.
If a group enables retention, members should know before contributing. A hidden setting would defeat the point of a simple audience model.
The location trail can wait
An optional map, assembled from background location samples, could give photos context without making someone narrate every stop.
It also carries much more information than a deliberately selected photo. A route can reveal where someone lives, studies, or spends an evening. A premium toggle does not solve the audience or consent questions.
The location table belongs to a user without specifying which groups receive which parts of a trail. Automatic sharing needs audience selection, a preview, stop removal, and an obvious off switch. I would leave it out of the first trial.
What I need to learn next
The next useful test is a few existing groups using a small version: choose an audience, save a few items, release them together, and let them expire. Location history and elaborate reactions are unnecessary to learn whether that exchange is enjoyable.
I would watch for less glamorous signals than time spent in the app. Does someone post because they want to, or because the counter is unfinished? Do people understand who will see a draft and when? Does the fixed time help a group reconnect, or become another deadline? When someone skips a day, do they return comfortably?
The hard part is getting a group to arrive together and stay. I cannot seed this with strangers. For now, the goal is a small thing a few people like, then letting their experience change the rules.
Sources and scope
This note draws on my original Breadcrumbs write-up, its revision history in the website repository, and my March 13, 2026 development notes. The notes record draft-upload work and proposed Supabase SQL; they do not verify deployment, active users, scheduled jobs, or a complete authorization system.
Proposed behavior is separate from documented prototype work. The unresolved rules and next steps are my design assessment, not results from a user study. A source-scope summary records those boundaries without publishing the raw development notes.