What I built
I built a small planning application that turns saved ideas into shared or personal plans. It keeps useful places searchable after an outing is archived and helps people recover when two browser tabs edit the same plan.
The product starts with two practical needs: shared information should not expose every personal note, and an older tab should not overwrite a newer decision. The portfolio edition makes those behaviors inspectable with fictional people, places, and plans.
Follow the local walkthrough
Alex finds a restaurant from an archived outing, adds it to a shared plan, and links a walk without duplicating either saved item. Jamie can see the shared plan, while Alex’s personal preparation stays out of Jamie’s results.
Opening the same plan in two tabs exposes another rule: a stale save is rejected, but the form keeps its unsent text so the person can recover. Each person’s note has its own version, allowing independent notes without unnecessary conflicts.
Architecture and decisions
- Filter visibility before search. Results and counts include only items visible to the selected role; a shared plan can reference only items visible to both people.
- Separate saved items from outings. Stable item IDs let plans reuse places without copying them, and archiving an outing does not remove its places from discovery.
- Make plan retries predictable. Request IDs, payload receipts, and deterministic plan IDs prevent a repeated creation request from producing another plan; conflicting reuse is rejected.
- Keep persistence understandable. A single-process file store serializes writes and replaces files atomically, with explicit recovery behavior between saving state and saving request receipts.
My contribution
I defined the requirements and adapted planning and visibility mechanisms from my personal application into this fictional sample, using the AI-assisted development approach described on the About page.
Scope and verification
Fresh local validation passed 22 tests, and hosted CI passed at the reviewed revision; the repository also records browser checks for navigation, interrupted-save retry, stale edits, and a narrow layout. Alex and Jamie are selectable demo roles, not secure account authentication, and the file store supports one server process. This local fictional sample does not establish a hosted multi-user service, database transaction durability, or measured user impact.
Source snapshot 7af924a · Reviewed 2026-09-22. This case study describes that revision; development may continue separately.