PRD Library

Spotify Shoutouts

A creator tool, built with Spotify, that turns listening into a personal connection and a new income line for independent artists.

The 30-second version. Shoutouts lets independent artists record short personalized video and audio messages for fans, the way a fan might gift one for a birthday or a graduation. It was scoped as a Columbia PM Lab capstone built directly with Spotify, grounded in four research-backed artist personas and Spotify's own audience economics (monthly active listeners drive 60% of streams and 80% of merch purchases, super listeners drive 50% of ticket sales). The PM work here is the hard part of any two-sided marketplace: defining a North Star around the loop closing rather than vanity signups, setting pass/fail Beta gates benchmarked against Cameo and Patreon, and sequencing supply, demand, and trust so problems surface early rather than at scale.

---

🔗 Try it live: Concept built with Spotify, not a public product.

📄 Build artifact: Spotify PM Lab Final Presentation · persona research · metrics logic

🛠 Approach: Product strategy, persona research, KPI design, and a launch plan delivered as a final presentation. Built on existing Spotify infrastructure (payments, Creator Partnerships, trust and safety) rather than net-new systems.

---

Timeline: Columbia PM Lab capstone, partnered with Spotify. Strategy and metrics complete, scoped for a curated Beta.

---

1. Problem statement

Independent career artists sit in a structural trap Spotify research calls the "Sponsorship Gap." They have released consistently for three or more years and are trying to make music full-time, but they remain undercapitalized: too little income, too inconsistently, to invest in growth, with no label advances and no brand sponsorship. The competition is brutal. Spotify reports over 100,000 new songs released daily, and the payout distribution is steep. In Spotify's 2024 transparency reporting the 100,000th-ranked artist earned almost $6,000 while the 10,000th earned $131,000.

The escape hatch is not more reach. It is converting reach into durable fandom. Spotify's own data shows monthly active listeners are roughly 33% of an artist's audience but drive 60% of streams and 80% of merch purchases, and super listeners (around 2% of listeners) drive over 18% of streams and 50% of ticket sales. Existing tools (Discovery Mode, Marquee, Countdown Pages) help artists get heard. None of them give a fan a reason to pay an artist directly for a moment of connection, and none of them give the artist a new income line they fully control. Cameo proved the personalized-shoutout model works, but it lives off-platform and off the artist's audience graph.

2. Goals and non-goals

Goals

• Give Sponsorship Gap artists a new, optional income line they control, without giving up ownership or royalties.
• Convert a fraction of an artist's existing listeners into paying, returning fans by turning a Shoutout into a giftable occasion.
• Prove a two-sided marketplace loop closes before spending to scale it (supply reliability, demand satisfaction, minimum economic viability).
• Strengthen Spotify's artist value proposition by adding a monetization surface native to the audience graph artists already have.

Non-goals

• Not a royalty replacement. Positioned as supplemental and optional, to avoid the perception that Spotify is shifting income risk onto artists.
• Not open self-enrollment at launch. A curated cohort protects quality before scale, so we onboard through Creator Partnerships first.
• Not a new payments stack. We extend existing Spotify rails rather than build, to reduce risk and time to Beta.
• Not a celebrity marketplace. The thesis is mid-tier independent artists (5,000 to 100,000 monthly listeners), not A-list talent.
• Not a general video platform. Shoutouts are short, occasion-driven messages, not a content feed.

3. The product

A fan opens an artist's Spotify profile, requests a personalized Shoutout (often as a gift, with an occasion and a short note), pays, the artist records and delivers within an SLA window, and both sides leave the loop satisfied or get a frictionless refund.

The economic model is a single equation the whole team can reason about: revenue per artist = monthly listeners x Shoutout request rate x average Shoutout value. Every product decision must move at least one of those three levers.

4. User stories

Independent artist (supply)

• As an undercapitalized career artist, I want a new income line I fully control, so that I can reinvest in releases without signing away ownership.
• As an artist with a real but modest fanbase, I want to turn my most dedicated listeners into paying fans, so that my income reflects loyalty and not just raw streams.
• As a busy artist, I want clear delivery expectations and reminders, so that I can fulfill reliably without it taking over my week.

Fan (demand)

• As a superfan, I want a personal message from an artist I love, so that I feel a real connection beyond passive streaming.
• As a gift-giver, I want to buy a Shoutout for a friend's birthday or graduation, so that I give something memorable and specific.
• As a first-time buyer, I want clear pricing and a visible rating, so that I trust the experience before I pay.

Edge and trust states

• As a fan whose Shoutout is not delivered within 7 days, I want an automatic refund, so that a missed deadline never costs me money or trust.
• As Spotify, I want baseline moderation on requests and deliverables, so that an abusive or off-brand message never reaches a fan.

5. Requirements

Must-have (P0)

• Artist opt-in and onboarding through a curated cohort. Given an invited artist, when they complete onboarding, then they are activated and discoverable for Shoutouts.
• Fan request and payment flow on existing Spotify rails. Given a fan on an opted-in artist's profile, when they submit a request and pay, then the artist receives the request and funds are held.
• 7-day SLA with reminders and automatic refund on miss. Given an undelivered Shoutout, when 7 days elapse, then the fan is refunded automatically.
• Delivery, rating, and payout. Given a delivered Shoutout, when the fan confirms or the window closes, then the artist is paid and a rating is recorded.
• Baseline trust and safety filtering on requests and deliverables.

Nice-to-have (P1)

• Gifting flow with occasion presets (birthday, anniversary, graduation) and scheduled delivery.
• Pricing guidance for artists, anchored to a $40 midpoint for the emerging tier.
• In-app prompts timed to high-intent moments (post-stream, profile visit).

Future (P2)

• Self-enrollment at scale once curated quality is proven, modeled on Cameo's CameoX.
• Bundles (Shoutout plus merch, Shoutout plus ticket presale).
• Deeper trust and safety layering beyond keyword filtering.

6. Key product decisions and trade-offs

Decision: North Star is monthly completed Shoutouts per active artist, not requests or signups.

Alternatives considered: total signups (rejected, vanity, signups do not equal value), gross revenue (rejected, masks a broken loop with a few whales). Why this won: in a two-sided marketplace, value only exists when the loop closes. An incomplete Shoutout means a refund, a frustrated fan, and churn on both sides. Measuring completions forces the team to defend the whole loop.

Decision: Curated cohort first, open enrollment never at launch.

Alternatives considered: open marketplace day one (rejected, quality and fulfillment risk would poison trust before the model is proven). Why this won: supply reliability is the single point of failure. Cameo's own move to a premium 24-hour expedited tier shows fulfillment is hard even at scale, so we optimize for reliability over reach first.

Decision: Revise the GA earnings target from $500 down to $300 per artist per month.

This is the unflattering one. The first draft set $500, which implied a 5x jump from the $100 Beta floor that the data did not support. Benchmarked against Cameo micro-influencer pricing ($20 to $50, $40 midpoint) and Patreon's sub-$200 median, $300 is defensible because it is explained entirely by volume (2 to 3 Shoutouts in Beta rising to 8 at GA) at a stable price. Honesty over an impressive-looking slide.

Decision: Repeat rate measured at 15% to 20% within 6 months, not 25% within 90 days.

Alternatives considered: a 90-day window (rejected, too short for occasion-based gifting). Why this won: gifting follows natural cycles. A January birthday buyer may return for a June anniversary. The 6-month window matches real behavior, and the 15% to 20% band is anchored to the superfan segment that drives outsized spending.

Decision: Position as supplemental income, not a royalty fix.

Alternatives considered: market it as the answer to streaming economics (rejected, creates PR risk and artist backlash). Why this won: framing it as optional and on the artist's terms protects both artist trust and Spotify's reputation.

7. UX

The core surface is the artist profile, which already carries fan intent. Shoutouts appears there as an offer, not a separate destination, so the request starts where attention already is. The fan flow is occasion-first (pick the moment, write the note, pay) to lean into gifting, which converts better than self-purchase. The artist flow is reliability-first: a clear request with context, a visible SLA countdown, reminders, and a one-tap deliver. Ratings surface prominently to build the social proof a new marketplace needs. Refund flows are designed to be frictionless on purpose, because trust is built by resolving problems well, not by pretending they never happen. [Screenshot 1: artist profile with Shoutouts offer] [Screenshot 2: fan gifting request flow] [Screenshot 3: artist fulfillment view with SLA countdown]

8. Success metrics and validation

The framework is two phases. Beta proves the loop closes. GA proves it scales into income and habit.

Beta gates (all pass/fail, all must pass to reach GA):

• Completion rate: 70% of Shoutouts completed within 7 days. Below this, refund requests spike and trust erodes. Benchmarked to Cameo's 7-day SLA.
• Artist opt-in: 40% of invited artists activate. Midpoint of the 30% to 50% range for curated outreach.
• Artist NPS at least 30 and Listener NPS at least 30. The threshold where promoters outnumber detractors meaningfully; supply refers supply, demand refers demand.
• Beta floor: $100 per artist per month. A proof-of-concept floor, roughly 2 to 3 Shoutouts at $40. If a curated, high-intent cohort cannot clear this, it is a product problem, not a scale problem.

GA targets (all due by month 6):

• 8 completed Shoutouts per active artist per month (habit cadence, roughly 2 per week).
• $300 per artist per month (volume-driven, defensible against comps).
• 15% to 20% repeat rate within 6 months (anchored to superfan gifting behavior).

What didn't work, and what I'd change. The original GA economics were aspirational rather than benchmarked: $500 per artist and a 25% 90-day repeat rate both overstated what comparable platforms achieve, and I revised them down once I stress-tested against Cameo and Patreon data. I would also flag that all persona-level listener and income figures are clearly-labeled modeled assumptions, not validated actuals, because Spotify does not publish typical ratios by artist size. The honest gap in this work is that none of the Beta gates have been run with real artists yet. The next step is a live curated Beta to replace every benchmark with an observed number, and the framework is deliberately built to catch a failing loop early rather than amplify it.

9. Open questions and roadmap

• What is the real request rate from listener to buyer at the mid-tier? (data, after Beta)
• Does gifting convert as strongly inside Spotify as Cameo's standalone context? (user, design)
• What moderation depth is required before opening beyond a curated cohort? (legal, trust and safety)
• How should FTC disclosure be handled if Shoutouts ever intersect with brand sponsorship? (legal)

v2 scope: open self-enrollment, bundles with merch and ticket presales, and richer trust and safety.

GTM hypothesis: seed a curated cohort through Creator Partnerships, prove the loop in Beta, then scale enrollment. Why defensible: the audience graph is the moat. No standalone competitor can place a personalized monetization surface on the exact profile where a fan's intent already lives.

10. What this project demonstrates

• Problem identification: named a structural, evidence-backed problem (the Sponsorship Gap) and tied a product to the specific audience segments Spotify's own data says drive value.
• Trade-off reasoning: curated vs open, supplemental vs royalty-fix, and a willingness to revise headline targets down when the data did not support them.
• Marketplace fluency: a North Star built on the loop closing, sequenced gates for supply, demand, then economics.
• Validation discipline: every metric benchmarked to a named comp, every assumption labeled, no fabricated actuals.
• Stakeholder communication: the whole strategy compresses to one revenue equation and a single takeaway slide, scaling from a 30-second skim to a full deck.
• Partner credibility: scoped to build on existing Spotify infrastructure and teams, not net-new systems, which is how real platform features ship.

---

Built and documented by Juliana Cardona Mejia, MBA '26, Columbia Business School

Work Nooks

A marketplace that turns quiet neighborhood cafés into bookable focus seats, so remote workers find a nearby place to work and hosts earn from empty tables.

The 30-second version. Work Nooks lets a remote worker in Barcelona find and reserve a verified café workspace for as little as 4 euros a day, while café owners list, manage, and earn from seats that would otherwise sit empty. It is a true two-sided marketplace: a mobile-first PWA for workers and a desktop SaaS dashboard for owners, with Stripe Connect payouts, a 90/10 split, geofenced check-in, and a five-axis review system. This was a Barcelona MA Digital Product Management capstone graded Summa Cum Laude, shipped from a 55-slide pitch to a live, browsable product seeded with 30 real cafés across 8 neighborhoods.

---

🔗 Try it live: Open Work Nooks

📄 Build spec: original build prompt

🛠 Stack: React, Supabase (auth, DB, RLS, storage, edge functions), Stripe Connect, Mapbox, Twilio. Mobile-first PWA for workers, desktop dashboard for owners.

---

Timeline: Barcelona MA capstone (Summa Cum Laude). Live prototype, seeded with 30 real Barcelona cafés.

---

1. Problem statement

Remote and hybrid workers want a third place to work that is not their apartment and not a 300-euro-a-month coworking membership. Cafés are the obvious answer, but the experience is a gamble: you do not know if a place has wifi that holds, an outlet near a seat, or whether the staff will welcome a three-hour laptop session or shoot you looks after one coffee. On the other side, café owners have empty tables in the off-peak hours between breakfast and lunch and no clean way to monetize them, and no proof of who is actually coming in.

Existing options each fail one side. Coworking spaces (WeWork, local equivalents) are priced for daily commuters, not a worker who needs a seat twice a week. Café-finder apps and Google Maps tell you a café exists but not whether it works for a laptop day, and they do nothing for the owner. Work Nooks closes the gap with a verified, bookable seat at a café price (from 4 euros a day) and gives owners a dashboard, payouts, and foot-traffic proof.

2. Goals and non-goals

Goals

• Give remote workers a nearby, verified seat they can trust and book in under a minute, at a café price.
• Give café owners a new revenue line from off-peak empty seats, with payouts and proof of foot traffic.
• Make "verified" mean something: confirmed wifi, seating, and a genuine welcome to stay, not a self-claimed badge.
• Build trust on both sides through honest reviews and frictionless refunds, so a bad experience never poisons the marketplace.

Non-goals

• Not a coworking subscription. No monthly pass at v1, because the wedge is the pay-per-day café price, not a membership.
• Not multi-city. Barcelona only, because density and verification quality beat breadth at launch.
• Not pick-your-seat or order-from-app. Out of scope to keep the booking flow simple and the café relationship light.
• Not a community feed or chat. The worker wants a seat, not a social network.
• Not beyond cafés. No bars, restos, or coworking types in v1 supply, to keep verification consistent.

3. The product

Two surfaces, one marketplace. Workers get a mobile PWA; owners get a desktop dashboard.

The economic model is a 90/10 split: the owner keeps 90% of the fare, Work Nooks takes 10% as the marketplace fee, captured at confirmation, paid out weekly via Stripe Connect Express.

4. User stories

Remote worker

• As a remote worker, I want to find a verified café near me with good wifi and outlets, so that I can have a focused work day without gambling on an unknown spot.
• As a worker on a budget, I want to pay a café price (from 4 euros) rather than a coworking membership, so that I only pay for the days I actually need.
• As a returning worker, I want a stamp card that rewards loyalty, so that working here regularly earns me a free coffee or a free day.

Café owner

• As a café owner, I want to earn from empty off-peak seats, so that my quiet hours generate revenue instead of nothing.
• As an owner, I want a dashboard showing reservations, ratings, and a foot-traffic uplift versus my organic baseline, so that I can see Work Nooks is actually working.
• As an owner, I want weekly automatic payouts, so that I do not have to chase money.

Edge and trust states

• As a worker who arrives but the café is not ready, I want an automatic full refund, so that a no-show on their side never costs me.
• As a worker trying to check in from home, I want the geofence to block it, so that check-ins are honest and reviews are trustworthy.
• As an owner whose rating drops below 4.0 over 30 reviews, I want my listing auto-paused with a clear message, so that I fix the issue before more workers have a bad day.

5. Requirements

Must-have (P0)

• Role-aware auth and onboarding (worker, owner, or both). Given a new user, when they pick a role at signup, then they see the correct surface and can hold both roles on one account.
• Verified-only search and discovery with filters and a Mapbox map. Given a worker searching, when results render, then only verified cafés appear.
• Reservation and Stripe payment. Given a worker on a café detail page, when they reserve and pay (Stripe test), then they get a confirmation and the owner sees the booking.
• Geofenced check-in and five-axis review at checkout. Given a worker at the café, when they are within 100m, then check-in succeeds; when they check out, then they are prompted to rate wifi, ambience, seating, and comfort.
• Owner verification flow within 48h. Given an owner who adds a location with a license, when ops verifies within 48h, then the status flips to verified and the listing goes live.
• 90/10 fee capture and weekly Stripe Connect payouts.
• Auto-pause on sub-4.0 average over 30 reviews.

Nice-to-have (P1)

• Stamp card (5 visits to a free coffee, 10 to a free day).
• Owner analytics: revenue over time vs organic baseline, foot-traffic heatmap, review trends.
• Referral credit (5 euros split between sender and recipient).

Future (P2)

• Veridas API for automated verification (replacing manual ops review).
• Workspace types beyond cafés (bars, restos, coworking).
• Additional cities and a monthly pass tier.

6. Key product decisions and trade-offs

Decision: Verification is manual ops review, not self-attestation.

Alternatives considered: trust owner-claimed amenities (rejected, a wrong "has wifi" badge breaks trust on the worker's first try), full automation at launch (rejected, no verification API was good enough yet). Why this won: "verified" is the entire value proposition for the worker. A human confirming wifi and seating within 48 hours is slow but trustworthy, and an auto-pause trigger keeps quality honest over time. The cost is roughly 30 minutes of ops time per verification, around 200 in Q1, which is the price of trust.

Decision: Café price wedge (from 4 euros), no membership in v1.

Alternatives considered: a monthly coworking-style pass (rejected, that is the incumbent model and the reason workers are underserved). Why this won: the surprising, clickable fact is that a verified workspace costs the price of a coffee. Pricing per day removes the commitment that keeps occasional workers out of coworking entirely.

Decision: Geofenced check-in within 100m, even though it adds friction.

Alternatives considered: trust-based check-in (rejected, breaks review integrity and enables fare gaming). Why this won: honest check-ins are what make reviews and foot-traffic proof credible to owners. The friction is the point.

Decision: Two distinct surfaces (mobile worker, desktop owner) instead of one responsive app.

Alternatives considered: one shared responsive layout (rejected, a worker booking on the go and an owner managing analytics have opposite needs). Why this won: the worker flow is glanceable and one-handed; the owner flow is a data dashboard. Forcing them into one layout would have compromised both. The trade-off is more to build and maintain.

Decision: Barcelona only, 30 real cafés, not a thin national demo.

Alternatives considered: a broad but shallow multi-city seed (rejected, density and real verified supply matter more than a big map with empty pins). Why this won: a worker in Gràcia needs real options in Gràcia. 30 verified cafés across 8 neighborhoods reads as real coverage, not a demo.

7. UX

The worker surface is search-first and deliberately unfussy. The hero does the only real selling ("Find a place to work. In your neighborhood. From 4 euros."), and everything below is functional: filter chips, café cards with a verified-workspace badge and a star rating, and a Mapbox map toggle. The voice is practical, local, and Barcelona-fluent (neighborhood names, euros) without performing it; the capstone polish shows as clarity, not flourish. The café detail page is the conversion surface, so it leans on real café photos and a clear attribute row (wifi, outlets, window seats, quiet) over stock imagery. The owner dashboard is calm and metric-led: a revenue row, today's reservation timeline, and a sub-4-star alert. Copy never says "user" or "customer"; it says "you," "the shop," and "the worker." [Screenshot 1: worker home search with verified café cards] [Screenshot 2: café detail with attribute row and reserve CTA] [Screenshot 3: owner dashboard with reservations timeline]

8. Success metrics and validation

Leading indicators

• Search to reservation conversion. Target [X%] of searches that end in a paid reservation, measured from the search_executed to reservation_completed event chain.
• Check-in rate. Target at least [80%] of reservations resulting in a geofenced check-in, measured from checked_in over reservation_completed.
• Owner activation. Target [X%] of signed-up owners completing Stripe Connect and getting a first location verified.

Lagging indicators

• Worker repeat rate. Target [X%] of workers booking a second day within 30 days (stamp-card progress is the proxy).
• Verified supply quality. Target average rating at or above 4.2 across active cafés, with auto-pause keeping sub-4.0 (over 30 reviews) listings out of search.
• Owner-reported foot-traffic uplift vs organic baseline, surfaced in the analytics tab.

What didn't work, and what I'd change. The honest limitation is that this is a seeded prototype, so the metrics above are targets, not observed results, and every bracketed figure is waiting on real demand. Manual verification is the right call for trust but does not scale; the roadmap to a Veridas-style API exists precisely because 30 minutes per listing breaks past a few hundred cafés. The original copy also buried the single most clickable fact, the 4-euro price, inside the meta description rather than above the fold, and the verified badge floated without explaining what was verified. Both were sharpened (the price now anchors the hero, the badge now reads "verified workspace"), but the broader lesson holds: for a search-first utility, the most surprising concrete fact should lead, and trust signals must say what they actually guarantee.

9. Open questions and roadmap

• What is the real off-peak fill rate owners can expect, and is 10% the right take? (data, after pilot)
• Does manual verification hold quality at 200-plus cafés, or is Veridas needed sooner? (ops, eng)
• How do we handle a café that is verified but degrades (slow wifi creep) between reviews? (data, ops)
• What insurance and liability framing do workers and owners need? (legal)

v2 scope: Veridas verification, a monthly pass tier, workspace types beyond cafés, and expansion to a second city.

GTM hypothesis: seed real verified supply in dense Barcelona neighborhoods, acquire workers through the surprising café-price hook, and let stamp cards and referrals drive repeat. Why defensible: verified supply is the moat. A café-finder cannot match a bookable, verified, owner-monetized seat, and coworking cannot match the café price.

10. What this project demonstrates

• Problem identification: a real two-sided gap (workers gamble on cafés, owners waste off-peak seats) that neither coworking nor map apps solve.
• Trade-off reasoning: manual verification over self-attestation, café price over membership, geofence friction in service of trust, two surfaces over one.
• Technical fluency: a full marketplace stack (Stripe Connect splits and payouts, RLS-scoped data, geofencing, Mapbox) scoped and shipped as a working prototype.
• Validation discipline: targets framed honestly as targets, real seeded supply rather than empty pins, bracketed placeholders for anything unobserved.
• Roadmap sense: a clear path from manual verification to an automated API, and from one city and pay-per-day to multi-city with a membership tier.
• Communication: capstone-grade clarity (Summa Cum Laude) from a 55-slide pitch to a browsable live product with a search-first, local voice.

---

Built and documented by Juliana Cardona Mejia, MBA '26, Columbia Business School

Kiya Tomlin: Luxury Resort Partnership Strategy

A go-to-market strategy putting a sustainable resort-wear brand into luxury wellness resorts

The 30-second version. A Columbia Business School brand-partnership engagement (co-prepared with Gale McFarlane) that built the go-to-market case for placing Kiya Tomlin, a sustainable bamboo resort-wear label, into luxury wellness resorts. The work delivered a competitive positioning memo and a ranked resort opportunity matrix, and recommended a concrete opening move: The Breakers, Palm Beach. This is strategy and market-research work, not a software build, and it demonstrates competitive analysis, customer segmentation, partnership structuring, and a defensible recommendation under a real deadline.

---

Engagement: Columbia Business School brand-partnership project, with Gale McFarlane

---

Timeline: Midterm deliverable, presentation March 3, 2026

---

1. The strategic question

Kiya Tomlin makes elevated, sustainable resort wear anchored by a signature sweatshirt dress: "polished ease," luxury comfort built on regenerated bamboo, fit-tested on real women. The brand sells direct but has limited presence where its ideal customer actually shops on vacation: the boutiques and gift shops of luxury wellness resorts. The question this engagement answered was where and how Kiya should enter resort retail to win the "daywear occasion" that no competitor currently owns.

2. The market and the gap

The customer is an affluent, wellness-conscious woman, 35 to 60, household income $250K and up, a frequent luxury-resort guest who values quality, sustainability, and understated elegance. The market is large: roughly $47B in global luxury wellness travel, with about 78% of resort guests buying in-stay retail. The gap is specific. Resort shops stock generic athleisure or formalwear, with nothing in the "polished ease" middle. No brand owns elevated bamboo resort sweatwear as a curated partner experience. Eberjey built a hotel business on sleepwear; the daywear occasion is wide open, and Kiya is positioned to own it.

3. Approach

The research was structured to mirror how resort partnerships are actually won, which is rarely on brand merit alone and usually on fit with what a resort already buys and how its boutique operates. The work covered:

• A competitive set of premium resort, wellness, and athleisure brands that already appear in luxury hospitality retail and spa partnerships, mapped on positioning and price.
• A shortlist of 10 to 12 luxury wellness resorts and resorts with high-activation spas and boutiques, scored as partnership targets.
• A view of partnership mechanics: curated shop operators, pop-ups, collaborations, and the path to a buy.

4. Findings and recommendation

The competitive positioning memo placed Kiya in the open "polished ease" quadrant, distinct from both technical athleisure and resort formalwear, with sustainability and fit as the durable differentiators. The resort opportunity matrix ranked targets by customer overlap, boutique activation, and partnership feasibility. The recommended opening move is The Breakers in Palm Beach: a flagship that concentrates the target customer, runs a high-activation boutique, and gives Kiya a credible reference account to open the next set of doors.

5. Deliverables

• Competitive Positioning Memo: where Kiya sits in the landscape and why the "polished ease" position is defensible.
• Resort Opportunity Matrix: 10 to 12 ranked targets with the scoring logic behind the ranking.
• Opening-move recommendation: The Breakers, Palm Beach, with the rationale for leading there.

6. What this project demonstrates

• Competitive analysis. Mapped a crowded category and found the open position a brand could credibly own.
• Customer segmentation. Defined a specific, high-value buyer and tied the recommendation to where she actually shops.
• Partnership and GTM strategy. Structured the path to a retail partnership around how resorts really buy, not just brand fit.
• Prioritization under constraint. Turned a broad market into a ranked, defensible shortlist and a single recommended first move, on a real deadline.
• Executive communication. Packaged the analysis into a positioning memo, a decision matrix, and a presentation-ready deck.

CBS Collective (CBS Job Aggregator)

Built for my Columbia Business School vibe coding class: one board for every non-traditional MBA job, posted by clubs, students and Career Management, with a personal pipeline to track each role.

The 30-second version. Non-traditional recruiting roles at Columbia Business School live in club WhatsApp groups, Slack, LinkedIn DMs, newsletters, club Airtables and word of mouth. Students told us they spend 3 to 5 hours a week stitching them together. CBS Collective centralizes those roles in a community job board that club AVPs, students and the Career Management Center (CMC) all post to, and lets every student save any role into a personal tracker in one click. Built as a team final project in Columbia's Prompt to Product course and shipped live.

---

Timeline: Spring 2026, Prompt to Product final project (team). MVP requirements written April 8, 2026.

Live: https://cbscollective.lovable.app

---

1. Problem statement

The jobs exist; finding them is a full-time job. Three things came up in every student conversation:

• The intel exists, the system does not. Students already spend 3 to 5 hours a week assembling roles from WhatsApp, LinkedIn, newsletters and word of mouth.
• You miss a job if you are not watching. Several students learned about roles only after they were filled. Speed and centralization are the same problem.
• A warm intro changes everything. Every respondent said referrals meaningfully improve interview rates. The bottleneck is not the posting, it is knowing who in your network is already at the company.

Club AVPs have the opposite problem: each club keeps its own Airtable or channel, with no standard way to share roles.

2. Goals and non-goals

Goals

• Centralize club-sourced and student-submitted roles in one searchable, filterable board.
• Give every student a personal tracker that fills itself from the board.
• Give club AVPs a standard, low-effort way to post, in bulk or one at a time.

Non-goals for the MVP

• Airtable auto-sync (replaced by CSV upload).
• Authentication and private visibility.
• Messaging, resume parsing, salary data and company ratings.

3. The product

Two layers, one flywheel: more contributors make discovery better, and every save and stage update passively informs the CMC.

4. User stories

• As a club AVP, I want to bulk upload our club's roles from a CSV, so that I stop maintaining a separate list nobody outside the club sees.
• As a student, I want to search every posted role by category and industry, so that I find roles I would never have searched for.
• As a student, I want to save a role in one click and track its stage, so that my pipeline lives in one place.
• As a student, I want a contact log per company, so that I can see my warm path.
• As the CMC, I want anonymized outcome data from accepted offers, so that I understand non-traditional recruiting without extra surveys.

5. Requirements and acceptance criteria

• CSV upload. Given a club AVP uploads a CSV with Job Title and Company columns, when they click Upload, then all valid rows are saved and appear in search.
• Flexible mapping. Given a CSV with headers such as "Position" or "Firm", then the system maps them to Job Title and Company.
• Manual post. Given a user enters Job Title and Company in the form, when they submit, then the role appears in search, with club name saved if they checked "I am a club member of".
• Filtering. Given a user selects the Tech category and Technology industry, then only roles matching both are shown.
• Tracker. Given a user opens the tracker, then they see every role they saved.
• Default visibility. All roles are public in the MVP; private visibility waits for authentication.

6. Key product decisions and trade-offs

CSV upload instead of Airtable sync. Syncing a dozen club Airtables with different schemas was the riskiest piece. A CSV upload with flexible column mapping delivered 90% of the value in a fraction of the build. Trade-off: data goes stale until the next upload.

Everything public in the MVP. Club-gated visibility matters to some AVPs, but it requires authentication. Shipping public-only first proved the board and tracker loop. Trade-off: some club-exclusive roles will wait for V2.

Provenance on every role. Showing source and "posted by" builds trust in a community board and turns posts into warm-intro leads.

7. Success metrics

• Weekly active students and roles saved per student.
• Clubs contributing and roles posted per week.
• Hours per week students report spending on job discovery, against the 3 to 5 hour baseline.
• Share of tracked roles that reach an interview stage.

8. What this project demonstrates

• User research to product: student interviews turned directly into the problem framing and the two-layer design.
• Scoping: a clear MVP line (CSV over sync, public over gated) with acceptance criteria.
• Shipping: a live product built and demoed within the course.
• Teamwork: built with a Prompt to Product team.

Grüns Product Brief

1. Product Essence

Grüns turns daily vitamin-taking into a journey of self-transformation. Users create an AI-generated digital twin representing their ideal self, a playful vision of who they become through consistent health habits.

The twin evolves daily based on behavior, unlocking badges, milestones, and shareable moments. It's modern identity-based habit design, wrapped in Gen Z aesthetics and social mechanics.

Unlike generic habit trackers, Grüns makes your health visible, social, and personally meaningful.

---

2. Who Is the Customer

Primary: Current users of Grüns

Secondary: Friends of current users of Grüns

---

3. Core Customer Problem

People struggle to stay consistent with health habits because motivation alone isn't enough.

Three Layers to This Problem

Lack of Intrinsic Consistency Systems

Users want to be healthier, but they don't have reliable systems or routines to make vitamin-taking automatic. Motivation fluctuates, so behavior breaks.

Low Engagement / Habit Friction

Taking vitamins is boring, solitary, and easy to forget. There's no built-in reward loop or emotional pull to keep users engaged daily.

Weak Accountability Structures

Users are more consistent when someone is watching or doing it with them, but they lack:

• Social reinforcement (friends doing it too)
• External accountability (being seen or tracked)

---

4. User Stories

Consistency / Self-Optimization

As a Gen Zer taking Grüns vitamins, I want a simple and consistent routine so that I can reliably become the best version of myself.

Social Reinforcement

As a Grüns vitamin taker, I want to build healthy habits with my friends so that staying consistent feels social, fun, and easier to maintain.

Accountability / Visibility

As a person taking Grüns vitamins, I want to share my health journey publicly so that I feel accountable and motivated to stay committed.

---

5. Product: Grüns

Grüns turns healthy habits into social, AI-powered digital identities that users share to make wellness visible, engaging, and self-expressive.

How It Works (Product Essence)

• Users create an AI-generated "digital twin" of their ideal self, a playful version of who they become when they consistently take their vitamins, like a modern-day Popeye transformation.
• The twin evolves based on daily behavior (taking Grüns or skipping it), tracking progress and unlocking shareable badges and milestones.
• Users can share progress updates, twin evolution, and how they are feeling.
• Social accountability is built through "twin packs" or squads, where friends track goals together. Staying consistent unlocks rewards like discounts.
• When users invite friends, those friends receive a free sample to start, join the same journey if they accept, and can see each other's progress. Users can give and receive kudos within their squad, and stronger consistency within a tribe unlocks additional rewards.

---

6. User Journey

Phase 1: Onboarding

• User signs up via mobile web (email, phone, or social login)
• Creates a one-sentence ideal self description: e.g., 'Fit, strong, kind, centered, fearless person ready to run a triathlon on 24 hours notice'
• Selects traits from guided options (fit, kind, disciplined, focused, fearless, resilient, etc.)
• AI generates a visual or conceptual twin representation
• Shares twin on social media (Instagram, TikTok, etc.)
• Given option to download app or engage via SMS for lightweight experience

Phase 2: Daily Engagement

• User receives daily check-in prompt: 'Did you take your Grüns today?'
• System responds dynamically (celebration for yes, light nudge for no)
• User sees real-time streak counter and progress dashboard
• Twin evolves visually or narratively based on consistency
• Badges unlock at milestones (3 days, 7 days, 30 days, etc.)

Phase 3: Social & Sharing

• User shares progress, twin evolution, or mood updates to social platforms
• System auto-generates shareable content optimized for each platform
• Friends and followers can tap through to join the journey

Phase 4: Squad & Accountability

• User invites friends to join their 'Grüns tribe' (squad)
• Invited friends receive a free sample offer to start
• Shared progress visibility across the tribe builds mutual accountability
• Users give and receive 'kudos' within their squad
• Stronger tribe consistency unlocks additional rewards and perks

---

7. User Personas

Persona 1: Maya (The Identity-Seeker)

Age: 21, college student, aspiring health influencer

Motivation: Wants to be visibly healthy and disciplined; craves public recognition

Pain Point: Gets bored with routines; needs external validation to stay consistent

Grüns Value: She loves that her digital twin is proof of her commitment. Sharing it on Instagram makes her feel seen.

Persona 2: Darius (The Accountability Buddy)

Age: 19, college student, values community

Motivation: Thrives when doing things with friends; dislikes going solo

Pain Point: Quits habits when friends aren't invested

Grüns Value: He joined because his roommate invited him. Now they check in daily and celebrate together.

Persona 3: Zara (The Optimizer)

Age: 23, works in tech, self-improvement obsessed

Motivation: Loves data, badges, and visible progress

Pain Point: Vitamin-taking feels like a dead habit with no feedback loop

Grüns Value: The daily check-in, streak counter, and evolving twin give her tangible proof of progress. She tracks it obsessively.

---

8. MVP Requirements (Ordered by Priority)

Tier 1: Must-Have Core Features

1.1 Account Access & Signup

• Mobile web sign-up (email, phone, or social login)
• SMS engagement option for lightweight access

1.2 Digital Twin Creation

• One-sentence ideal self input with guided examples
• Trait selection from curated Gen Z options
• AI-generated twin preview

1.3 Daily Check-In

• Yes/No vitamin intake prompt
• Dynamic responses (celebration or nudge)
• Real-time streak counter
• Simple progress dashboard

1.4 Twin Evolution & Badges

• Visual/narrative twin change based on consistency
• Streak-based badge unlocks (3, 7, 14, 30, 60, 90 days)

Tier 2: Social & Squad

2.1 Social Sharing

• Share twin creation to Instagram, TikTok, Twitter
• Share progress updates and badges
• Auto-generated social copy optimized per platform

2.2 Friend Invitations

• Shareable squad invite link
• Track accepted/pending invites
• Associate free sample offer to invites

2.3 Squad Dashboard

• View squad members and their streaks
• Send/receive kudos within squad
• Track squad-level consistency milestones

Tier 3: Rewards & Retention

3.1 Rewards Dashboard

• Streak-based reward unlocks (discounts on Grüns, exclusive offers)
• Referral rewards (friend joins and starts)
• Squad milestone bonuses

3.2 Engagement Mechanics

• Restock reminders (when supply is low)
• Streak break re-engagement nudges
• Push notifications and SMS for opt-in users

---

9. Campaign Success Metrics

Primary Metric: 30-Day Retention

Target: 50% of activated users maintain a streak and re-engage by day 30. This signals habit stickiness.

Secondary Metrics

• Daily Active Users (DAU) / Monthly Active Users (MAU)
• Average Streak Length (target: 15+ days for active users)
• Squad Growth Rate (invites sent, friends converted)
• Social Shares (shares per activated user)
• Repeat Purchase Rate (tied to app engagement)
• Referral Conversion Rate (friend invites that lead to purchase)

---

10. Channels & Acquisition Strategy

Channel 1: Organic

Description: Word-of-mouth, social shares, viral loops

Timeline: Week 1+

How It Works: Users share twins on Instagram and TikTok. Friends click. Friends join.

CAC: $0

Target: 20-30% of acquisition by Month 3

Metrics to Track: Viral coefficient, share rate, organic user signup source

Channel 2: Influencer

Description: Gen Z micro-influencers (50K-500K followers)

Timeline: Week 5-8

How It Works: Partner with 10 micro-influencers. Gifted Grüns + early app access. Organic content.

CAC: $0.50-1.00 per user (gift value / acquired users)

Target: 40-50% of early adopters

Metrics to Track: Influencer reach, engagement rate, conversion to signup, cost per acquisition

Channel 3: Paid Social

Description: TikTok & Instagram Reels (Gen Z targeting)

Timeline: Week 9+

How It Works: Ads showing twin transformations and squad moments. CPC to app or web.

CAC: $2-3

Target: 30-40% of acquisition (scale phase)

Metrics to Track: ROAS (return on ad spend), CPC, conversion rate, cohort retention

Channel 4: Referral

Description: In-app invite + free sample offer

Timeline: Week 1+ (built-in from launch)

How It Works: User invites friend. Friend gets free sample offer. Friend joins squad.

Viral Coefficient: 1.2-1.5 (each user brings 1.2-1.5 friends)

CAC: $0 (internally funded)

Target: Compounding growth engine

Metrics to Track: Invite send rate, acceptance rate, viral coefficient, referral conversion to purchase

Channel Blend Strategy

Phase 1: Soft Launch (Weeks 1-4)

• Primary channels: Organic + Referral
• Goal: Validate product, optimize retention
• Success metric: 50% D30 retention, 30% social share rate

Phase 2: Influencer Launch (Weeks 5-8)

• Primary channels: Organic + Influencer
• Goal: Expand reach, prove product-market fit
• Success metric: 5K+ installs, 40%+ engagement rate
• Expected CAC: <$1

Phase 3: Full Public Launch & Scale (Weeks 9+)

• Primary channels: Paid Social + Organic + Referral
• Influencer: Ongoing partnerships + ambassadors
• Goal: Scale to 50K+ MAU
• CAC target: $2-3 with <8 week payback

Key Insights by Channel

• Organic is strongest: Users want to share because it's identity-based. Viral loop compounds.
• Influencer accelerates: Authentic Gen Z creators drive early adoption at low CAC.
• Paid scales efficiently: Once retention is proven, paid social becomes profitable.
• Referral runs forever: Friend invites create continuous, compounding growth.

---

11. Go-to-Market Strategy

Phase 1: Soft Launch (Week 1-4)

• Beta test with 200-500 existing Grüns customers
• Focus on squad building and referral loops
• Gather feedback on twin concept and social features

Phase 2: Gen Z Influencer Launch (Week 5-8)

• Partner with 5-10 Gen Z fitness/wellness micro-influencers
• Gifted Grüns + early app access in exchange for organic content
• Focus on dual consumption (vitamins + app)

Phase 3: Full Public Launch (Week 9+)

• Paid social (TikTok, Instagram Reels) targeting Gen Z
• Content: User-generated twin reveals, squad milestones, transformation stories
• Press & earned media around identity-based habit design

Ongoing: Retention & Engagement

• Squad challenges (monthly themes: '30-day transformation', 'Summer strength', etc.)
• Leaderboards and seasonal rewards
• Content collaborations with users' friends (squad-based UGC)

---

12. Key Risks & Mitigation

Risk 1: Twin Concept Resonance

Problem: Some users may find the twin concept gimmicky or off-brand.

Mitigation: Extensive beta testing with Gen Z. Iterate on tone and visual language. Option to customize or hide twin if preferred.

Risk 2: Social Pressure Backlash

Problem: Users may feel anxiety over public streak breaks or squad pressure.

Mitigation: Design friendly nudges, not shame-based messaging. Highlight that streaks can restart. Privacy controls for visibility.

Risk 3: Churn After Initial Spike

Problem: Novelty wears off; habit breaks; user disengages.

Mitigation: Continuous reward cycles, seasonal challenges, evolving twin mechanics, squad re-engagement loops.

---

13. Appendix: Supporting Materials

Sample Twin Descriptions (from onboarding)

• "Fit, strong, kind, centered, fearless person ready to run a triathlon on 24 hours notice"
• "Morning person who crushes her goals and takes care of herself"
• "Glowing, radiant, energized person who feels amazing in my body"
• "Leader who inspires others through consistency and discipline"

Trait Options for Twin Selection

Fit, Strong, Kind, Disciplined, Focused, Fearless, Resilient, Radiant, Energized, Confident, Centered, Grounded, Inspired, Leader, Visionary, Calm, Playful, Adventurous

Sample Social Copy (Auto-Generated)

• "Just created my digital twin on Grüns. This is who I'm becoming, one vitamin at a time. Join me? [link]"
• "7-day streak! My twin is evolving and so am I. Consistency pays off. Wanna build habits together? [link]"
• "Me vs. my digital twin: who's winning? Find out on Grüns [link]"

Street Collectiv: Product Requirements Document

---

1. Overview

Street Collectiv is a community-driven marketplace that connects local small businesses with values-driven consumers. It combines three product surfaces that today exist in separate apps: a local shopping directory (think Yelp), a subscription platform (think Patreon), and a social network for ethical commerce (think Nextdoor meets Etsy).

The platform's wedge is the subscription model for local shops, which converts unpredictable foot traffic into recurring revenue while giving shoppers exclusive access, deals, and events at the places they already love. Around that wedge, Street Collectiv layers value-based discovery (BIPOC-owned, low-carbon, neighborhood-local), direct shop-to-shopper messaging, and a cross-promotion engine that lets non-competing neighborhood shops co-market.

The strategic bet: in a market dominated by transactional, extractive platforms (Amazon, Instacart, DoorDash), there is room for a relationship-based commerce layer where shop financial health and consumer values are explicitly aligned.

---

2. Problem statement

For small businesses

Local independent shops operate on thin margins with highly seasonal, unpredictable revenue. They lack the digital infrastructure to compete with big-box retailers on discoverability, loyalty programs, email marketing, and delivery. Existing platforms (Yelp, Google, DoorDash) extract value through ads or commissions without giving shops a meaningful tool to lock in recurring customers.

For conscious consumers

Shoppers who want to align purchases with their values (local, sustainable, equitable) face high friction. Information is scattered, claims are unverifiable, and convenience platforms like Amazon optimize for price and speed at the expense of ethics. There is no single place to discover, filter, and reliably buy from values-aligned local businesses.

For neighborhoods

Local commerce ecosystems are increasingly hollowed out. The social fabric that historically connected shops, owners, and residents has eroded, and there is no digital product that explicitly reinforces it.

---

3. Goals and non-goals

Goals

1. Give local shops a recurring revenue stream through consumer subscriptions.
2. Give consumers a trustworthy, low-friction way to discover and buy from values-aligned local businesses.
3. Build social infrastructure that makes local commerce feel like a community rather than a transaction.
4. Enable small shops to cross-promote and act collectively at a scale that approaches what large retailers do solo.

Non-goals (v1)

• Becoming a fulfillment or logistics provider. Delivery is integrated via third parties, not operated in-house.
• Competing with Amazon on price or selection for commodity goods.
• National rollout. v1 focuses on a single pilot city or neighborhood cluster.
• Replacing point-of-sale systems for shops.

---

4. Target users

Primary persona 1: The Conscious Consumer ("Maya")

• 28 to 45, urban, college-educated, household income $75K+.
• Already shops local when convenient but defaults to Amazon under time pressure.
• Cares about climate impact, BIPOC and women-owned businesses, and supporting her neighborhood.
• Pain point: aligning values with shopping requires research she does not have time for.

Primary persona 2: The Small Shop Owner ("Marcus")

• Owner-operator of a 1 to 10 person retail, food, or service business.
• Revenue between $100K and $2M annually, with significant seasonal swings.
• Spends evenings doing marketing, social, inventory, and admin after a full operational day.
• Pain point: cannot predict next month's revenue and has no infrastructure to build loyalty programs or email marketing the way chains do.

Secondary persona: The Community Organizer ("Renee")

• Neighborhood association leader, BID member, or local activist.
• Wants tools to organize local events, drive foot traffic to small businesses, and reinforce neighborhood identity.

---

5. User stories

Consumer side

• As a shopper, I want to discover shops in my neighborhood filtered by ownership, sustainability, and category, so I can quickly find places that match my values.
• As a shopper, I want to subscribe to a favorite shop for a monthly fee and receive perks (a free coffee weekly, 15% off, early access to drops), so I get ongoing value and the shop gets stable revenue.
• As a shopper, I want to message a shop owner directly with questions about a product, so I get the kind of personal service I would get in person.
• As a shopper, I want to attend in-person events with other members, so I can meet like-minded people and deepen my connection to the neighborhood.
• As a shopper, I want carbon impact and equity data on every purchase, so I can track and reduce my footprint.

Shop side

• As a shop owner, I want to create subscription tiers with custom perks, so I can convert one-time customers into recurring revenue.
• As a shop owner, I want to see which subscribers are active, lapsing, or churned, so I can intervene.
• As a shop owner, I want to chat with customers and post updates, so I can build a following without managing five social media platforms.
• As a shop owner, I want to partner with a neighboring non-competing shop on a joint promotion, so we can both reach new customers.
• As a shop owner, I want to see how my shop ranks on values-based filters (carbon, equity, local), so I can improve and market that.

---

6. Features and requirements

6.1 Subscription engine (P0)

The flagship feature. Enables shops to publish subscription tiers and consumers to subscribe.

Functional requirements

• Shops can create up to 5 subscription tiers with custom price, billing cycle (weekly, monthly, quarterly), perk description, and inventory caps.
• Consumers can browse, subscribe, pause, or cancel from a single dashboard.
• Stripe (or equivalent) integration for recurring billing and payouts.
• Shops can view subscriber list, MRR, churn, and lifetime value in a basic dashboard.
• Perks can be physical (free item monthly), digital (early access codes), or experiential (member-only events).

6.2 Values-based discovery (P0)

Lets consumers filter and browse by ethical and logistical criteria.

Filters required at launch

• Location: neighborhood, walk time, or radius.
• Ownership: BIPOC-owned, women-owned, LGBTQ-owned, immigrant-owned (self-attested at signup, with verification path).
• Carbon score ("Carbon Calories"): per-shop and per-product where data exists.
• Wage equity: shops that opt in and disclose wage ratio data.
• Category: food, retail, services, etc.
• Delivery available: yes or no, plus delivery window.

Open question: how is ownership verification handled? Self-attestation vs. third-party certification (B Corp, NMSDC, etc.).

6.3 Direct messaging and shop profiles (P1)

Each shop has a profile that functions like a hybrid Instagram and storefront.

Functional requirements

• Shop profile: photos, story, hours, subscription tiers, products, follower count, carbon and equity badges.
• Consumers can follow shops without subscribing.
• 1:1 messaging between consumer and shop, with response time SLAs visible.
• Shops can post updates (text, photos, short video) to followers.

6.4 Member events (P1)

Subscription tiers can unlock access to in-person events.

Functional requirements

• Shops or groups of shops can create events with location, capacity, RSVP rules.
• Subscribers see member-only events in a unified calendar.
• Consumers can RSVP, see attendee count, and (optionally) see who else is going.

6.5 Cross-promotion engine (P2)

Lets non-competing neighborhood shops co-market.

Functional requirements

• Shops can opt in to a cross-promotion pool with category and neighborhood tags.
• System suggests potential partners (e.g., coffee shop + bookstore in the same zip code).
• Shops can launch joint email campaigns through Street Collectiv's email tool to each other's subscribers (with consumer opt-in respected).
• Revenue or referral attribution is tracked, so shops can see whether the partnership worked.

6.6 Integrated delivery (P2)

Consumers can choose pickup or delivery at checkout.

Functional requirements

• Integration with at least one third-party local courier service (e.g., Roadie, local couriers, or platform-specific options).
• Shops can set delivery zones and fees.
• Delivery is optional. Shops can opt out entirely if they want pickup-only.

6.7 Carbon and equity scoring (P2)

The data layer that powers values-based filters.

Functional requirements

• Shops complete a structured onboarding survey covering sourcing, energy, packaging, wages, and ownership.
• Score is computed by a transparent rubric (published publicly) and displayed as a badge.
• Shops can improve scores over time and see what levers move them.
• Consumers can see a per-purchase "Carbon Calorie" estimate on receipts.

Open question: how rigorous does scoring need to be at launch to avoid greenwashing accusations? Likely needs a transparent methodology page and an external advisor before scaling.

---

7. Non-functional requirements

---

8. Success metrics

North star

Monthly recurring revenue (MRR) flowing to local shops through Street Collectiv subscriptions.

This metric captures the core thesis: are we actually stabilizing small business cash flow?

Supporting metrics

Marketplace health

• Active subscriptions per consumer (target: 2+ by month 6 of consumer lifecycle).
• Subscriber churn rate (target: under 8% monthly by month 12).
• GMV (gross merchandise volume) through the platform.

Shop health

• Average MRR per shop.
• Shop retention at 6 and 12 months (target: 80% at 6 months).
• Net promoter score from shop owners.

Consumer engagement

• WAU / MAU (target: 0.5+).
• Average filters used per session (signal for whether values-based discovery is working).
• Messages sent between consumers and shops.
• Event attendance among subscribers.

Community and network effects

• Cross-promotion campaigns launched per month (post-v2).
• Referrals: consumers acquired through other consumers' shares.

---

9. Risks, assumptions, and dependencies

Key assumptions to validate

1. Consumers will pay subscriptions to local shops. Validate with a pilot cohort of 10 shops and 200 consumers before scaling features.
2. Shops will invest the time to onboard and maintain a profile. This is non-trivial; many small shop owners do not have time for another platform.
3. Values-based filters drive purchase decisions. Some evidence in adjacent markets (e.g., B Corp, Aspiration), but unproven at the local commerce level.
4. A pilot city has enough density of both shops and conscious consumers to create marketplace liquidity.

Risks

Dependencies

• Payments infrastructure: Stripe or similar.
• Delivery infrastructure: at least one third-party courier integration.
• Mapping and location services: Google Maps or Mapbox.
• Email infrastructure: SendGrid or equivalent.
• Initial pilot partnerships: 1 to 2 neighborhoods with high density of indie shops and a values-aligned consumer base (candidates: Brooklyn, Oakland, Philadelphia, Asheville).

---

10. Out of scope for v1

• Native mobile apps (iOS, Android).
• B2B marketplace (shop-to-shop wholesale).
• International expansion.
• Branded payment card or financial product for shops.
• AI-driven personalized recommendations.
• Influencer or affiliate program.

---

11. Open questions

1. Pricing model: does Street Collectiv take a percentage of subscription GMV, charge shops a SaaS fee, charge consumers a membership fee, or some mix? Likely a small percentage of subscription revenue plus optional consumer membership.
2. Geographic launch strategy: one neighborhood within one city, or one city end-to-end?
3. Verification standard: self-attestation vs. third-party certification for ownership and sustainability claims?
4. Shop onboarding model: self-serve, sales-led, or community-led (recruit via local BIDs and chambers of commerce)?
5. Defensibility: what is the moat once a competitor (Shopify, Square, even Amazon) copies the subscription feature? Likely the community and trust layer, but this needs to be sharpened.

---

12. Appendix: design principles

These should guide every product decision.

1. Relationship over transaction. Every feature should reinforce the relationship between shopper and shop. If it makes the experience feel more like Amazon, reconsider it.
2. Shops first. This is a B2B2C product where the shop is the hardest side of the marketplace to acquire. When in doubt, optimize for shop experience.
3. Trust through transparency. Values-based claims must be backed by published methodology. No black boxes.
4. Convenience without compromise. Conscious shoppers will not trade convenience for ethics indefinitely. The product must be as easy as Amazon for the ethical choice to win.
5. Community is a feature, not a vibe. Member events, direct messaging, and cross-promotion are concrete features, not marketing language.

Talent Hive (V1 and V2)

A peer skills marketplace where members trade help priced in reputation, not cash, so expertise circulates inside a community of people who have earned their place.

The 30-second version. Talent Hive lets members post projects and trade skills with each other using Karma Coin, an in-app reputation currency, instead of money. A member posts a project with a Karma bid, contributors apply, counter, or pass, work gets done, and both sides review each other before any Karma is released. The headline asset is reputation: a dual-blind five-axis review system, a reliability score, and a ranking formula deliberately built so that a new high-quality contributor is not buried under sheer volume. The PM work here is the trust machinery of a marketplace, the escrow logic, the anti-collusion rules, and the edge cases for when someone ghosts.

---

Timeline: Solo build prototype, in testing. V1 of the Talent Hive line.

---

1. Problem statement

Skilled people help each other all the time (a designer reviews a friend's deck, a developer unblocks someone's bug), but that exchange has no structure and no memory. Favors are informal, hard to ask for without feeling like an imposition, and they leave no record of who is actually reliable. The moment money enters, the dynamic changes: cash marketplaces like Upwork and Fiverr turn collaboration into a transactional gig economy where price competition, client-freelancer power imbalance, and recruiter spam crowd out the goodwill that makes peer help feel good in the first place.

The result is a gap. There is no trusted place to trade help among peers where the currency is contribution and the asset that accrues is reputation. Existing platforms optimize for the wrong thing: Upwork and Fiverr optimize for the lowest bidder, LinkedIn optimizes for connections and recruiter reach, and informal favor networks do not scale or remember. Talent Hive replaces cash with Karma and makes a member's track record (completed projects, peer-validated skills, a five-axis review history) the thing they build and carry. Reputation, not price, decides who gets the work.

2. Goals and non-goals

Goals

• Let members trade real help without money, so collaboration feels like community, not a gig.
• Make reputation the headline asset, so reliable, high-quality contributors are visibly rewarded over time.
• Protect both sides with escrow and dual-blind reviews, so neither party can be left burned.
• Keep the exchange spam-free and human, so the place feels closer to a creative community than a job board.

Non-goals

• No cash or Stripe at v1. Premium money features are Phase 2, because the whole thesis is reputation-as-currency.
• No public Karma leaderboards. Out of scope, because ranking people publicly turns collaboration competitive and gameable.
• No AI matching at v1. Phase 3, because trust and the manual application flow come first.
• No DMs outside a project context. Messaging is project-scoped to prevent recruiter spam and cold outreach.
• No badges, streaks, XP, or levels. Reputation is earned through real reviewed work, not gamified vanity.

3. The product

A member posts a project with a Karma bid; the bid is escrowed immediately. Contributors apply at the posted bid, counter-offer with a justification, or pass. The owner accepts one contributor, work happens, the owner marks complete, and both parties review each other before Karma releases.

Reputation has two formulas. Reliability = completion rate x 0.4 + on-time rate x 0.3 + review average x 0.3. Ranking (used to order applicants) = review average x log(completed count + 1), deliberately logarithmic so a new contributor with a few excellent reviews is not crushed by someone with high volume and mediocre work.

4. User stories

Project owner

• As an owner, I want to post a project and see applicants ranked by reputation, so that I can pick the person whose track record fits the job.
• As an owner, I want my Karma escrowed and released only after we both review, so that I never pay for work that was not delivered.
• As an owner whose contributor ghosts past the timeline, I want a one-tap dispute to reclaim my Karma, so that a no-show does not cost me.

Contributor

• As a contributor, I want to apply with the posted bid or counter with a justification, so that I can take fair work on fair terms.
• As a high-quality newcomer, I want the ranking to weight review quality, not just volume, so that I am not buried by people who have simply done more.
• As a contributor whose owner ghosts after accepting, I want Karma to auto-release to me after a wait, so that I am paid for work I did.

Edge and trust states

• As a member with too little Karma to post, I want an inline error and a link to browse projects to earn, so that I am guided, not blocked.
• As the system, I want two all-5-star reviews submitted within five minutes of each other flagged for moderation, so that collusion is caught (no auto-action at MVP, just a flag).
• As either party, I want a project unreviewed for 14 days to auto-resolve with neutral 3-star reviews, so that Karma never gets stuck in limbo.

5. Requirements

Must-have (P0)

• Auth and 3-step onboarding granting 100 starter Karma. Given a new user, when they finish onboarding, then they receive 100 Karma and land on Discover.
• Project posting with immediate escrow. Given an owner with enough Karma, when they post, then the bid is escrowed at once.
• Application flow (apply / counter / pass) with one counter per applicant.
• Owner application list ranked by reputation, accept exactly one. Given multiple applicants, when the owner views them, then they are ordered by the reputation rank formula.
• Dual-blind review gating Karma release. Given a completed project, when both parties submit reviews, then and only then does Karma release and reputation recompute; neither rating is visible until both submit.
• Project-scoped messaging only.
• Correct cancellation refunds. Given a cancellation, when it is pre-acceptance, then 100% refunds; when post-acceptance, then 95% refunds with a 5% platform sink.

Nice-to-have (P1)

• Reputation profile: Karma earned, review average, completed count, reliability bar, peer-validated vs self-attested skills, portfolio grid, last 5 reviews with per-axis bars.
• Karma dashboard: balance, escrow, lifetime earned/spent, transaction history, 30-day sparkline.
• Ghost-handling auto-releases (owner ghosts 7 days, contributor ghosts 14 days, unreviewed 14 days).

Future (P2)

• Cash and premium features (Phase 2).
• Multi-contributor team projects (Phase 2).
• AI matching (Phase 3).

6. Key product decisions and trade-offs

Decision: Reputation currency (Karma), no cash at v1.

Alternatives considered: real money like Upwork/Fiverr (rejected, that recreates the gig-economy dynamics the product exists to escape: lowest-bidder competition, power imbalance, spam). Why this won: making the currency reputation aligns incentives toward quality and goodwill. The cost, openly, is that Karma has no external value yet, so the early loop depends on intrinsic motivation; cash is a deliberate Phase 2 layer once the trust loop is proven.

Decision: Dual-blind reviews that gate Karma release.

Alternatives considered: one-directional reviews or reviews visible immediately (rejected, both invite retaliation and inflation, "I'll give you 5 if you give me 5"). Why this won: blind reviews where neither party sees the other's rating until both submit produce honest scores, and gating release on both submissions forces closure. It is the single most important trust mechanism in the product.

Decision: Logarithmic ranking formula (review average x log(completed + 1)).

Alternatives considered: rank by raw completed count (rejected, entrenches incumbents and buries good newcomers) or by review average alone (rejected, a single 5-star review would outrank a proven contributor). Why this won: the log term rewards experience with diminishing returns, so quality newcomers compete while volume still counts. This is the most considered piece of PM math in the build.

Decision: Project-scoped messaging only, no open DMs.

Alternatives considered: open messaging (rejected, instantly becomes a recruiter-spam and cold-pitch channel, the exact thing that makes LinkedIn exhausting). Why this won: tying every conversation to a project keeps the community focused and spam-free. The trade-off is less serendipitous connection, accepted on purpose.

Decision: Flag collusion, do not auto-punish, at MVP.

This is the honest, imperfect call. Two all-5-star reviews within five minutes get flagged for moderation but trigger no automatic penalty. Auto-action was rejected because false positives (two people who genuinely had a great, fast project) would punish exactly the behavior the product wants. The trade-off is that some collusion slips through at MVP; the bet is that a human-in-the-loop flag is safer than an aggressive rule until there is enough volume to tune it.

7. UX

The mood is warm, collaborative, and optimistic, closer to Are.na or Read.cv than Upwork, and deliberately not Fiverr, LinkedIn, gig apps, or crypto exchanges. A serif display face (Fraunces or Lora) carries titles and names so people feel like people, Inter handles the UI, and Karma values render in gold with tabular numerals. Motion is subtle (200 to 300ms fades, a small "+/-" float when Karma transfers, no spring physics) so the interface feels calm rather than playful-to-a-fault. The Discover feed reads like a creative-community digest: recommended projects, trending skills, and "community wins" (recently completed work with the Karma earned and a review snippet). The reputation profile is the most important screen and treats a member's track record as the hero: three stat blocks, a reliability bar, peer-validated vs self-attested skill markers, a portfolio grid, and recent reviews with per-axis mini-bars. Empty states encourage and never blame the user ("No reviews yet, every project is a first").

8. Success metrics and validation

Leading indicators

• Onboarding completion. Target [X%] of signups finishing the 3-step onboarding and claiming 100 Karma.
• First project posted. Target [X%] of new members posting or applying within their first session.
• Application-to-acceptance rate. Target a healthy [X%] of projects receiving and accepting an application, the signal that the loop closes.

Lagging indicators

• Loop completion rate. Target [X%] of accepted projects reaching dual review and Karma release (the true North Star, since value only exists when the loop closes).
• Repeat collaboration. Target [X%] of members completing a second project within 30 days.
• Reputation integrity. Target a low, monitored rate of collusion flags and ghost auto-resolutions, signaling the trust machinery is holding.

What didn't work, and what I'd change. Every figure above is a target on an unvalidated prototype, not an observed result. The honest hard problem is cold-start liquidity: a reputation marketplace is worth nothing until enough members and projects exist to make the feed feel alive, and 100 starter Karma plus a seeded set of demo projects is a thin answer to that. The collusion rule is intentionally soft (flag, no auto-action), which means V1 tolerates some gaming in exchange for not punishing genuine fast collaborations, a trade-off I would revisit with real volume. I would also pressure-test whether reputation alone is motivating enough to sustain participation without any cash on-ramp; that assumption is the load-bearing bet of the entire model, and it is exactly what V2 exists to refine.

9. Open questions and roadmap

• Is reputation-only motivating enough to sustain a marketplace, or is a cash on-ramp needed sooner than Phase 2? (user, data)
• How do we solve cold-start liquidity beyond starter Karma and seeded projects? (growth, data)
• When does the soft collusion flag need to become an automated rule, and at what volume? (data, trust and safety)
• Are the reliability and ranking weights right once real outcomes exist? (data)

v2 scope: refine matching and reputation (the focus of Talent Hive V2), then layer cash premium features, team projects, and eventually AI matching.

GTM hypothesis: seed tight communities (a cohort, a creative scene) where reputation already has social value, prove the loop, then widen. Why defensible: reputation is portable trust that compounds and cannot be bought, a moat that lowest-bidder cash marketplaces structurally cannot build.

10. What changed in V2

Talent Hive V2 is the second pass at a reputation-currency marketplace where members trade skills using Karma instead of cash. V1 proved the core loop (post, apply, dual-blind review, Karma release) but exposed where it strained: discovery was a busy feed, matching was manual, and reputation was rich but hard to read at a glance. V2 starts from a deliberate planning discipline ("tell me exactly what you plan to build before you build it") and rebuilds the experience as a cleaner wireframe, sharpening how the right contributor surfaces for a project and how reputation is presented so trust is legible in seconds. The PM work here is iteration: deciding what to keep, what to cut, and what to simplify after a first build taught its lessons.

V2 keeps the V1 loop and refines two layers on top of it: how matches surface, and how reputation reads.

The underlying mechanics are inherited: a project bid is escrowed on posting, contributors apply or counter, both parties review blind, and Karma releases only when both reviews are in. Reputation still rests on the V1 formulas (reliability = completion rate x 0.4 + on-time rate x 0.3 + review average x 0.3; ranking = review average x log(completed count + 1)). What changes is the surface, not the engine.

V2 decisions and trade-offs

Decision: Plan explicitly before building ("tell me exactly what you plan to build before you build it").

Alternatives considered: iterate directly in code as in V1 (rejected for V2, because the lesson from V1 was that an unplanned surface accretes friction). Why this won: forcing a written plan before the build is how you cut scope deliberately instead of adding features reflexively. The entire V2 framing is an act of restraint, and the planning step is what makes that restraint possible.

Decision: Ship a wireframe, not a polished build.

Alternatives considered: a full high-fidelity V2 (rejected, polishing the wrong structure wastes the iteration). Why this won: the V1 lessons were structural (discovery, matching, reputation legibility), so V2 should prove the new structure first and polish later. The unflattering truth is that a wireframe looks less impressive than V1's finished surface, and shipping it anyway is the disciplined choice: validate the flow before investing in fidelity.

Decision: Keep the V1 trust machinery untouched.

Alternatives considered: re-examine escrow and review logic (rejected, those were the parts V1 validated). Why this won: iteration means changing what underperformed and protecting what worked. Re-litigating proven mechanics would risk regressing the product's core asset.

Decision: Refine matching surfacing now, defer learned matching to later.

Alternatives considered: jump straight to AI/ML matching (rejected, same reason as V1: not enough outcome data, and a black box undercuts the legibility V2 is chasing). Why this won: better surfacing and clearer signal solve most of the matching friction without a model, and they generate the very data a future model would need. Sequencing over flash.

11. What this project demonstrates

• Problem identification: named what cash marketplaces break (goodwill, peer trust) and built the currency around the thing that actually accrues, reputation.
• Trade-off reasoning: Karma over cash, blind over open reviews, logarithmic over raw-volume ranking, project-scoped over open messaging, flag over auto-punish.
• Systems thinking: complete escrow and refund logic, ghost-handling timeouts, anti-collusion flags, and two distinct reputation formulas with a clear rationale for each.
• Validation discipline: loop completion framed as the North Star, every metric a labeled target, cold-start named as the central unvalidated risk.
• Roadmap sense: a deliberate sequence (prove the reputation loop, then add cash, teams, and AI matching) rather than building everything at once.
• Communication: a warm, anti-gig product voice and an interface language chosen to feel like a community, not a job board.

DealFlow

A deal OS for solo and small SMB brokers that turns scattered buyer lists into scored intros and a pipeline that moves to close.

The 30-second version. DealFlow helps small business brokers find the right buyer for a deal and move it through diligence to close in one workflow. The core is a rules-based matching engine that scores every buyer against every deal on industry, size, geography, prior closings, speed, and response rate, then surfaces the top 10 with a one-click intro. It is built desktop-first for the broker who is the whole firm: a Kanban pipeline, a CSV buyer importer, intro tracking with open and reply status, and an insights view that benchmarks the broker against the firm average. Subscription priced at $299 per seat per month.

---

Timeline: Solo build prototype, in testing.

---

1. Problem statement

A solo or small SMB broker runs a real business out of a spreadsheet. Deals live in one file, buyers in another, and the matching between them lives in the broker's head. The work that actually closes deals (knowing which of 200 buyers fits this specific manufacturing business in Ohio at this EBITDA band) is invisible, slow, and impossible to scale past the broker's memory. When a broker is the entire firm, every hour spent re-deriving who to call is an hour not spent closing.

Existing tools fail this user in opposite directions. A general CRM (HubSpot, Salesforce) is built for high-volume sales motions, not the low-volume, high-stakes, relationship-heavy world of buying companies, and it does nothing to match buyers to deals. A VDR or data room handles documents but not the pipeline or the intro. Brokers end up stitching together a CRM, a spreadsheet, and an email client, with the most valuable step (the scored intro) done entirely by gut. DealFlow puts the deal, the buyer list, the scoring, the intro, and the pipeline in one product, so the broker's judgment is amplified rather than re-typed.

2. Goals and non-goals

Goals

• Cut the time from a new deal to a sent intro from hours of manual cross-referencing to minutes.
• Surface the buyers most likely to close, so the broker spends outreach on the top of a ranked list, not the whole list.
• Give the broker a single pipeline view that always reflects deal reality, from listing to close or dead.
• Make broker performance legible (intro-to-LOI conversion, time to first intro) so the broker can improve, not just operate.

Non-goals

• Not a public marketplace or listing site. DealFlow is a private broker tool, not a place buyers browse, to keep deal confidentiality intact.
• Not a buyer-side workflow product. Phase 2, because the wedge is the broker.
• Not a data room. We integrate with VDRs rather than build one, since that is a solved and regulated space.
• Not deal closing or escrow. Out of scope; DealFlow gets a deal to the table, it does not move money.
• Not AI-generated outreach at MVP. Deterministic templates only, because a broker's voice and accuracy matter more than novelty.

3. The product

The broker works left to right across six surfaces: Pipeline, Deals, Buyers, Intros, Insights, Settings.

The match score is a transparent weighted formula: 30% industry fit, 20% size fit, 15% geography fit, 15% prior-closing match, 10% normalized speed score, 10% normalized response rate. Each component is 0 to 100, cached per deal-buyer pair, and recomputed only when an attribute changes.

4. User stories

Solo / small broker

• As a broker who is the whole firm, I want every buyer scored against a new deal automatically, so that I start outreach with a ranked top 10 instead of re-reading my whole list.
• As a broker, I want to send an intro from a template and have its opens and replies tracked, so that I know who is engaged without living in my inbox.
• As a broker, I want a Kanban pipeline that persists when I drag a deal, so that my pipeline always reflects reality at a glance.
• As a broker importing my book, I want to bulk-upload 100 buyers from a CSV in under a minute, so that I can start matching the day I sign up.

Broker measuring performance

• As a broker, I want to see my intro-to-LOI conversion against the firm average, so that I can tell whether my matching is actually working.

Edge and multi-tenant states

• As a broker, I want a clear empty state when I have no deals or buyers, so that I know exactly what to do first.
• As one of two brokers in the same firm, I want to see only my own deals and buyers, so that confidential pipelines stay separate (RLS-enforced).

5. Requirements

Must-have (P0)

• Deal CRUD with teaser upload. Given a broker, when they create a deal and upload a teaser, then it persists and is RLS-scoped to their firm.
• Buyer model with bulk CSV import. Given a 100-row CSV, when imported, then all buyers load in under 60 seconds.
• Rules-based scoring engine. Given a new deal, when matches are computed, then the top 10 scored buyers appear in under 3 seconds.
• Intro flow with send and status tracking. Given a chosen deal and buyer, when the broker sends an intro, then the email lands and a buyer reply updates the status automatically.
• Kanban pipeline with persistent drag-drop. Given a deal card, when dragged to a new stage, then the stage persists on reload.
• RLS isolation. Given two brokers in one firm, when each logs in, then each sees only their own deals and buyers.

Nice-to-have (P1)

• Insights view: intro-to-LOI conversion vs firm average, median time to first intro, response-rate cohorts.
• Buyer intent signals log.
• Stripe subscription at $299 per seat per month.

Future (P2)

• A model trained on outcome data (intro to LOI to closed) to replace the deterministic rules.
• Team members and firm-level roles.
• VDR integrations and cross-firm buyer sharing with explicit consent.

6. Key product decisions and trade-offs

Decision: Rules-based scoring at v1, an ML model only later.

Alternatives considered: an ML matching model from day one (rejected, there is no outcome data to train on yet, and a black box the broker cannot trust is worse than a transparent formula). Why this won: a broker will only act on a score they understand. A weighted, inspectable formula (with visible score components) earns trust and produces the very outcome data a future model would need. This is the disciplined sequencing, not the flashy one.

Decision: Broker-side only at MVP, no buyer-side tooling.

Alternatives considered: build both sides at once (rejected, doubles scope and dilutes the wedge). Why this won: the broker is the buyer of the software and the daily user. Nail the side that pays first.

Decision: Deterministic templates, no AI-generated outreach at MVP.

This is the unflattering trade-off, because AI copy is the obvious demo. Rejected anyway: an intro that misstates a deal detail or sounds off in the broker's voice can cost a relationship that took years to build. In a low-volume, high-trust market, accuracy and the broker's own voice beat generated polish. AI copy stays a later option, not a launch feature.

Decision: Integrate VDRs, do not build a data room.

Alternatives considered: build a native data room (rejected, it is a mature, security-sensitive, regulated category). Why this won: DealFlow's value is the pipeline and the match, not document hosting. Building a VDR would burn the roadmap on a solved problem.

Decision: Recompute scores only on attribute change, with per-pair caching.

Alternatives considered: recompute on every page load (rejected, wasteful and slow at scale). Why this won: scores only change when a deal or buyer attribute changes, so caching per pair keeps the top-10 fast (under 3 seconds) without redundant work.

8. Success metrics and validation

Leading indicators

• Time to first intro. Target median under [X minutes] from deal creation to first sent intro, measured from deal listed_at to first intros.sent_at.
• Match panel action rate. Target [X%] of computed top-10 matches that result in a sent intro.
• CSV import completion. Target [90%] of new brokers importing a buyer list in their first session.

Lagging indicators

• Intro-to-LOI conversion. Target [X%], benchmarked broker vs firm average in Insights.
• Pipeline velocity. Target reduction in median days-per-stage versus the broker's pre-DealFlow baseline [to be populated after validation].
• Subscription retention. Target [X%] monthly retention at $299 per seat.

What didn't work, and what I'd change. Every metric here is a target, not an observed result; this is a prototype in testing and the matching engine has not yet been validated against real closed-deal outcomes. The honest weakness of a rules-based score is that the six weights (30/20/15/15/10/10) are reasoned, not learned, so they are almost certainly miscalibrated until real outcome data corrects them. That is by design (you cannot train a model with no data), but it means the score's job at v1 is to be transparent and directionally useful, not precise. The single biggest validation risk is reply-status parsing: automatic status updates depend on reliably matching buyer replies to intros, and that is the piece I would harden and instrument first, because a pipeline that silently goes stale is worse than no pipeline.

9. What this project demonstrates

• Problem identification: a real, underserved user (the broker who is the whole firm) and a specific high-value task (the scored intro) that no incumbent owns.
• Trade-off reasoning: transparent rules over an untrained black box, broker-side over both sides, deterministic templates over AI copy in a trust-critical market, integrate over build.
• Technical fluency: a weighted scoring engine with per-pair caching, RLS multi-tenancy, CSV import at scale, and email tracking, scoped with concrete performance acceptance criteria.
• Validation discipline: weights and metrics framed honestly as reasoned-not-learned and as targets, with the reply-parsing risk called out as the thing to instrument first.
• Roadmap sense: a clear path from rules to an outcome-trained model, exactly when the data to train it exists.
• Communication: a terse, professional product voice matched to a finance-adjacent user, no filler, no emoji.

Street Investors Exchange

An investor education and matchmaking platform that lets aspiring investors without wealth build a real track record, so early-stage capital is decided by a more diverse group of people.

The 30-second version. Street Investors Exchange (SIEX) was a Delaware public benefit corporation I co-founded in 2018 as a partner to the Street Entrepreneurs accelerator. The thesis: venture capital is homogeneous because you have to be rich to start investing, so diversifying who funds startups means giving unaccredited investors a way to earn a track record. The product combined gamified due diligence and investment education ("Coursera for Shark Tank"), a performance-tracked path to managing real capital through a donor-advised training fund, and a matchmaking layer between founders and investors. I conceived the platform, led the beta, wrote the PRDs, and ran the A/B tests behind a 2018 U.S. provisional patent application.

---

Timeline: Incorporated July 2018. Beta, PRDs and A/B tests in 2018. I stepped back in 2019.

Role: Co-Founder and COO, alongside co-founder and CEO Bethany Quinn.

---

1. Problem statement

Early-stage investing has a gatekeeping problem that starts before any pitch. Accredited investor rules mean you essentially have to be wealthy already to get into early-stage investment, and most accredited investors are white men. In 2016 there were about 54 women and roughly 15 African Americans in decision-making roles at US venture capital firms. Homophily and homogeneity in who invests limit funding for companies founded by women and people of color.

The problem showed up inside the Street Entrepreneurs accelerator. Alumni wanted to invest in current program participants, which sounds simple but runs straight into the accredited investor wall. Founders, meanwhile, struggle to find investors whose criteria they actually meet, while early-stage investors review around 10,000 companies a year, most of which never fit their thesis.

Existing options fell short. Matchmaking platforms such as Gust, FundingSage and EnrichHer connected founders and investors but did nothing to grow the investor pool. Investor education programs were small, in-person cohorts, and most only admitted accredited investors.

2. Goals and non-goals

Goals

• Grow the number of women and people of color working in early-stage investment: double the women and quadruple the African Americans in the first cohort.
• Give unaccredited, aspiring investors a compliant way to build a real, portable investment track record.
• Shorten fundraising for founders and screening for investors by matching on investment criteria.
• Fund the Street Entrepreneurs accelerator over time through the platform's donor-advised funds.

Non-goals

• Not a crowdfunding portal. Aspiring investors trained and invested through a managed training fund, not by pooling retail money directly into deals.
• Not a broker-dealer. The donor-advised fund structure kept activity within FINRA rules.
• Not a generic startup database. Matching existed to serve the education and track-record thesis.

3. The product

The long-term model was a fund of funds run by the platform's best performers. The math from the plan: with 10,000 members and the top 0.5% selected, 50 managers per cohort could each run a $10M fund, a $500M fund of funds large enough for pension funds to invest in.

4. User stories

• As an aspiring investor without wealth, I want to learn and practice due diligence on real companies, so that I can earn a track record no accreditation rule blocks.
• As a high-performing aspiring investor, I want my results tracked in a profile, so that employers and limited partners can see what I can do.
• As a founder, I want to see which investors' criteria I meet, so that I stop pitching people who will never invest.
• As an investor, I want alerts for companies that fit my thesis and access to diligence reports, so that I screen faster.
• As a Street Entrepreneurs alum, I want to invest in current program founders, so that the community funds itself.

5. Requirements

Must-have (P0)

• Gamified education modules with a points system (SIEX points) tied to activity and diligence quality.
• Due diligence report creation and an investor-facing library of reports.
• Investor profiles with tracked performance.
• Founder intake form and investor criteria alerts for matchmaking.
• Qualification gate from points to the donor-advised training fund.

Nice-to-have (P1)

• Employer and LP-facing profile export.
• Investor Circle oversight and feedback workflow for aspiring investors.

Future (P2)

• Graduate-run fund of funds sized for institutional investors.

6. Key product decisions and trade-offs

Donor-advised training fund instead of direct retail investing. Letting unaccredited users invest directly would have run into securities regulation. Routing qualified users through a donor-advised fund managed by Impact Assets let them build a real record while staying compliant. Trade-off: a slower, more structured path to real capital.

Start as a consulting business before building the full platform. The plan began with investor research and pitch support for founders and diligence support for investors, with aspiring investors as independent contractors. This tested demand and digitized the knowledge base before heavy engineering. Trade-off: services revenue and manual work early on.

B2B2C acquisition. Investors through angel circles and professional associations, founders through coworking spaces and accelerators, aspiring investors through MBA programs. Trade-off: partnership-driven growth is slower than paid acquisition but builds trust in a credibility-sensitive market.

Gamification as the core engine. Points made learning measurable and created a ranking signal for who earns access to real capital. Risk: gaming the points. Mitigation: points tied to the quality of diligence, not just volume.

7. Success metrics

• Total users by type, and daily and monthly active users.
• Diligence reports created; investments recorded on the platform and made through the training fund, in dollars and count.
• Return on investments; SIEX points as the activity metric.
• Aspiring investors trained, profiles sent to employers, and job placements.
• Diversity outcome: share of women and people of color among qualified investors.

8. What happened, and what I would do differently

I led the beta, wrote the PRDs and ran the A/B tests, and that work formed the basis of a 2018 U.S. provisional patent application. I stepped back from the company in 2019. With hindsight, I would narrow the first version to one loop, education plus diligence reports sold to investors, and prove investors would pay for that output before building matchmaking and the fund path in parallel. Three products in one platform stretched a two-founder team.

9. What this project demonstrates

• Problem framing: turned a structural market failure (who gets to invest) into a concrete product thesis.
• Regulatory judgment: designed around accreditation and FINRA rules instead of ignoring them.
• Sequencing: consulting first, platform second, fund of funds last.
• Founder execution: incorporation, co-founder partnership, beta, A/B tests and a provisional patent application.

Quiet Gate

A friction layer for intentional Instagram use

The 30-second version. I built a product that reduces compulsive Instagram opens by inserting escalating friction between the user and the app. Built solo in a weekend, validated with 14 days of self-use, designed for commercial expansion via browser extension in v2. The PM work spans problem framing, competitive analysis, design decisions under technical constraints, data-driven validation, and a defensible roadmap.

---

Timeline: Weekend prototype, 14-day validation, v2 in design

---

1. The opportunity

Smartphone users open Instagram a median of 8 to 14 times per day. Internal research from Meta (leaked in 2021) confirmed that the majority of these opens are not driven by specific intent. They are reflexive, triggered by boredom, anxiety, or habit. This produces measurable harm to attention, sleep, and self-reported wellbeing, and the harm scales with use.

The digital wellness category has responded with two dominant product archetypes, both of which fail in predictable ways:

• Hard blockers (Opal, Brick, ScreenZen): make Instagram inaccessible for fixed windows. High initial uptake; high churn. Users uninstall within two weeks because the blocker fires during a legitimate use case (responding to a real message, posting an event), produces resentment, and gets removed.
• Soft nudges (Instagram's own time reminders, weekly screen time summaries): easily dismissed. No behavior change observed in any published study.

The product gap: a tool that scales friction with usage, while keeping the app fully accessible. The bet is that most compulsive opens will not survive even mild friction, while intentional opens will pass through. No tool in market currently implements this approach.

2. The product

Quiet Gate is a web app the user installs on their phone home screen as a Progressive Web App, replacing the Instagram icon. Tapping it routes the user through a friction layer before opening instagram.com.

The friction is a five-stage state machine where each stage is more demanding than the last:

The counter resets at midnight in the user's anchor timezone. The to-do list is built once per day and persists through all subsequent opens. Every interaction is logged for personal review.

3. Key product decisions and trade-offs

This section is where PM thinking lives. For each decision below, I'll state the choice, the alternatives I considered, and why I chose what I chose.

Decision 1: Escalating friction, not flat barriers

Choice: Friction scales with opens (none, then visual, then written, then constructive).

Alternatives considered:

• Flat prompt at every open. Rejected because users adapt within days, typing "k" to bypass. Loses signal value.
• Fixed daily limit, then hard block. Rejected because the post-limit open is sometimes the most important one. Forces lockouts that produce uninstalls.
• Time-based gating. Rejected because compulsive and legitimate opens occur in the same hours. Cannot distinguish.

Why this won: Escalation preserves the signal value of friction. The 5th-open prompt feels meaningful because the first four didn't require one. This is the central design hypothesis of the product, and the success metric.

Decision 2: To-do list as the redirect, instead of meditation or exercise

Choice: At open 6, the user builds a to-do list. At opens 7+, they're invited to pick from it.

Alternatives considered:

• Generic redirects (meditate, exercise, journal). Rejected because they treat the user as someone with abstract wellness goals rather than concrete tasks. Most "I'm bored, opening Instagram" moments are avoidance of a specific thing, not absence of wellness practice.
• AI-generated suggestions. Rejected because the moment of compulsive opening is the wrong moment to introduce a third party (an LLM) into the loop. The user knows what they're avoiding better than any model does.

Why this won: A self-built to-do list at the moment of urge surfaces what the user is actually avoiding. The list is not enforced (no completion tracking). Visibility is the intervention.

Decision 3: An always-available escape hatch

Choice: "Open Instagram anyway" is reachable from every friction state, in 14px gray underlined text below the primary friction action.

Alternatives considered:

• No escape hatch. Rejected because it produces uninstalls when users have legitimate emergencies.
• Time-delayed escape (wait 60 seconds to bypass). Rejected because it adds friction in a direction that conflicts with the user's goal. The escape should be available; the bypass should be logged.

Why this won: The asymmetric visual design (friction is prominent, bypass is small) creates default behavior toward the constructive path while preserving user agency. Bypass rate becomes data: if a user bypasses 80% of the time, the friction is calibrated wrong and the product should adjust.

Decision 4: Anchored timezone for daily reset

Choice: The "daily" reset is locked to the user's anchor timezone (America/New_York for me), not the device's current timezone.

Alternatives considered:

• Device timezone. Rejected because traveling east effectively grants extra opens, creating an exploitable boundary.
• UTC reset. Rejected because midnight UTC is the middle of the user's day in most timezones; the reset would feel arbitrary.

Why this won: The anchor timezone keeps the day stable across travel and prevents micro-gaming. This is a small detail with disproportionate behavioral impact.

Decision 5: Single-tenant v1, multi-tenant in v2

Choice: v1 has no auth, no signup, no accounts. Single user, anon Supabase access.

Alternatives considered:

• Multi-tenant from day one. Rejected because auth, accounts, RLS policies, and password recovery flows would have tripled the build time without adding learning value at the prototype stage.

Why this won: Single-tenant v1 ships in a weekend and validates the core hypothesis. If the hypothesis fails, the multi-tenant work was avoided. If it succeeds, multi-tenant is a v2 unlock, not a v1 dependency. Classic build-measure-learn sequencing.

4. UX

The visual language is deliberately austere. Black on white. One typeface. No icons, illustrations, or animations beyond a 100ms fade on modal screens. This is a contrarian choice in a category dominated by warm, encouraging wellness aesthetics, and the reasoning is in section 3, decision 6 below.

Decision 6: Brutalist aesthetic in a warm-aesthetic category

Choice: Black and white, system sans, no decoration.

Why: Most wellness apps use warm colors and encouraging copy because their marketing positions them as friends. But the moment of compulsive opening is the wrong moment for friendliness; the user needs a stop sign, not a coach. The austere visual language matches the tonal need of the user state.

This is also a competitive differentiator. The product looks different in screenshots, communicates different intent, and signals seriousness in a category that often signals softness.

5. Validation and results

What didn't work, and what I'd change

• The 8-character minimum on the prompt was gamed within 3 days. Users (me) typed "asdfasdf" to bypass. A v2 version should evaluate semantic content, not just length, or use a delay-and-prompt rather than a character minimum.
• The to-do list reset at midnight was the wrong choice. Items added at open 6 yesterday were often still relevant today. A 48-hour rolling window or manual archive would have served the user better.
• The analytics view should have been in v1. Reviewing data weekly via Supabase's raw table editor added friction that almost prevented the weekly review from happening. The product should have shown its own data.
• Mobile-only is a real limitation. v1 cannot block content inside Instagram, only gate access. For users whose problem is "once I'm in, I scroll for 45 minutes," v1 alone is insufficient. v2 addresses this.

6. Roadmap: v2 commercialization

The v1 prototype validates the friction-layer hypothesis. v2 expands the product into a defensible commercial offering.

v2 scope expansion

Browser extension for desktop. A Chrome and Safari extension that runs on instagram.com and hides the feed, stories carousel, Reels, and Explore tab, while leaving DMs, posting, and profile views fully functional. Where v1 reduces opens, v2 reduces in-session time by removing the highest-dopamine surfaces.

Multi-user platform. Account creation, personal dashboards, configurable thresholds, configurable redirect options, optional weekly summary email.

Cross-app expansion. The friction-layer pattern is platform-agnostic. v2.5 extends the same model to TikTok, X, and Reddit. The underlying behavioral logic is identical.

7. What this project demonstrates

For the hiring manager evaluating fit for a PM role, this project demonstrates:

• Problem identification. Spotted a market gap (escalating friction without lockouts) that established competitors have not addressed.
• Trade-off reasoning. Six explicit design decisions with stated alternatives and rationale, including unflattering self-critique.
• Technical fluency. Built the product, made architectural decisions, identified and worked within platform constraints (iOS Safari sandboxing, popup-blocker rules).
• Validation discipline. Shipped a single-tenant prototype to test the hypothesis before building the multi-tenant version. Used myself as user zero. Captured quantitative and qualitative data.
• Roadmap sense. Articulated a defensible v2 commercialization path with competitive analysis, pricing hypothesis, and a thesis on what creates long-term moat.
• Communication. Produced a PRD that scales from 30-second skim to 10-minute deep read, structured for the audience.

Luna Health

A cycle and fertility tracking app that turns daily inputs into clear predictions and a readiness picture, so users can understand and plan around their bodies.

The 30-second version. Luna Health is a femtech product line that tracks the menstrual cycle and translates logged data (periods, symptoms, bloodwork) into plain predictions and an at-a-glance readiness score, with a particular focus on the egg-freezing and fertility-planning journey. I built it solo across two versions: V1, a focused companion that nailed the cycle-prediction and readiness loop, and V2, a fuller studio that deepened lab tracking, trends over time, and clinician-ready exports. It demonstrates working with real clinical reference ranges (AMH, FSH, E2, AFC), age-adjusted interpretation, a transparent scoring model, and the discipline of a wellness product that stays firmly on the right side of the not-medical-advice line while still being genuinely useful.

---

Timeline: Built as a two-version line (V1 companion, then V2 studio), in self-use testing.

---

1. Problem statement

People who menstruate, and especially those weighing egg freezing or fertility planning, are asked to make consequential, time-sensitive decisions with scattered information. Cycle data lives in one app, bloodwork lives in a clinic portal or a PDF, and the interpretation that connects them ("is my AMH good for my age, and what does that mean for my timeline?") lives only in a rushed appointment. The window for fertility decisions is genuinely time-sensitive, which makes the cost of fragmented, hard-to-interpret data high. Mainstream cycle trackers predict periods well but stop short of the fertility-readiness picture; clinical tools are not built for daily personal use. Luna's hypothesis is that a calm, single place that turns daily inputs and lab values into clear predictions and an honest readiness signal helps users understand their bodies and arrive at clinical conversations prepared, without ever pretending to be a doctor.

2. Goals and non-goals

Goals

• Turn logged cycles into clear, glanceable predictions (next period, fertile window, ovulation) (user outcome).
• Give fertility-minded users an honest, transparent readiness picture from the markers that matter (user outcome).
• Help users arrive at clinical appointments prepared, with their own data organized and exportable (user outcome).
• Stay clearly and consistently on the wellness side of the medical line, building trust through honesty about limits (trust outcome).

Non-goals

• Diagnosis or treatment recommendations. Out of scope and out of bounds; the app interprets and organizes, it does not prescribe.
• Replacing a reproductive endocrinologist. Out of scope; the app's job is to get users to that conversation better prepared.
• Selling supplements or fertility services. Out of scope; the checklist educates, it does not monetize through recommendations.
• Cloud accounts at MVP. Out of scope; sensitive health data stays local until a privacy and security model is properly designed.
• Social or community features. Out of scope; this is a private, personal tool.

3. The product

Luna is organized into a small set of tabs, each turning input into interpretation.

The readiness score is transparent and rules-based, not a black box. It weights AMH most heavily (40 of 100 points, as the strongest reserve indicator), then FSH (20), cycle regularity (20), and BMI (20), and shows every factor with its status (good, fair, low, or missing) and a plain-language note. Lab values are interpreted against approximate age-adjusted clinical medians (for example, AMH read relative to the median for the user's age band) rather than a single universal cutoff, which is more honest about what a number means for a specific person. A persistent disclaimer states clearly that Luna is a personal wellness tracker, not medical advice.

4. User stories

As someone tracking my cycle, I want next period, fertile window, and ovulation predicted from my logs, so that I can plan around my body.

As someone considering egg freezing, I want an honest readiness picture from the markers that actually predict reserve, so that I know roughly where I stand before a consult.

As a patient preparing for an appointment, I want my bloodwork organized over time and exportable, so that I can have a productive conversation with my reproductive endocrinologist.

As someone whose AMH number means little to me, I want it interpreted relative to my age, so that I understand whether it is normal for me rather than against a generic cutoff.

As a privacy-conscious user, I want my health data stored on my device, so that I control something this sensitive.

Edge/empty state. As a brand-new user with no cycles or labs logged, I want clear empty states ("Log your first period to see predictions," "Log at least 2 results to see your trends") rather than blank charts, so that I know exactly what to do next.

5. Requirements

Must-have (P0)

• Cycle logging (start, end, flow, symptoms) with persistence. Given a logged period, then it appears in history and feeds predictions.
• Cycle predictions. Given at least one logged cycle, then next period, fertile window, ovulation, and current phase are shown.
• Readiness score with transparent factor breakdown. Given available data, then a 0 to 100 score and per-factor status (good/fair/low/missing) are displayed, with missing factors named.
• Lab logging for AMH, FSH, E2, AFC plus notes, with age-adjusted AMH interpretation.
• A persistent, prominent not-medical-advice disclaimer.
• Local persistence of all health data.

Nice-to-have (P1, delivered or deepened in V2)

• Lab trends over time with charts and clinical reference lines.
• A reference guide for each marker and a Day 2 to 3 testing-timing helper.
• A clinician-ready text export of lab history and prep.
• The daily egg-quality checklist with educational annotations.

Future (P2)

• Secure cloud sync with a proper health-data security model.
• Symptom-to-prediction refinement as data accumulates.
• Optional integrations (lab-result import, calendar).

6. Key product decisions and trade-offs

Two versions: a focused companion (V1), then a fuller studio (V2).

V1 deliberately proved the core loop first: log a cycle, get clear predictions, see an honest readiness score. V2 then deepened the parts users could not get elsewhere: lab trends over time, a reference guide, testing-timing guidance, the clinician-ready export, and the daily wellness checklist. Alternatives considered: build the full studio in one pass (rejected, it risks over-investing in lab features before the prediction loop is validated). Why this won: shipping V1 narrow let me confirm the prediction-and-readiness loop was the hook, then expand toward the higher-effort, higher-value lab tooling in V2 with that signal in hand.

A transparent rules-based readiness score, not a model.

Alternatives considered: a learned or proprietary fertility score (rejected, no data, and a black box is exactly wrong for a health decision); a single readiness number with no breakdown (rejected, opaque and untrustworthy). Why this won: a documented points system, with every factor shown and missing data flagged honestly, is explainable and grounded in which markers actually predict reserve (AMH weighted highest). Hard trade-off: a simple points model is a rough approximation of a clinically complex picture; I mitigated it with prominent disclaimers and by routing users toward a reproductive endocrinologist rather than implying the score is diagnostic.

Age-adjusted interpretation instead of universal cutoffs.

Alternatives considered: a single AMH threshold for everyone (rejected, misleading across ages). Why this won: reading a value against the median for the user's age band is more honest and more useful, and it teaches the user something a flat cutoff cannot.

Wellness framing and a hard disclaimer line.

Alternatives considered: more assertive, quasi-clinical guidance for "usefulness" (rejected, it would cross into medical claims). Why this won: staying clearly on the wellness side protects users and the product, and honesty about limits is itself trust-building.

Local-only storage for sensitive data at MVP.

Alternatives considered: cloud sync from day one (rejected, sensitive reproductive-health data demands a security and privacy model I would not rush). Why this won: keep the most sensitive data on-device until sync can be done properly. Trade-off owned: no multi-device continuity yet.

7. UX

The aesthetic is warm and reassuring rather than clinical: a soft cream background, a deep plum-to-mauve header, a Cormorant Garamond serif for headings paired with DM Sans for body, rounded cards, and gentle color-coded status badges. The intent is to make a charged subject feel calm and in the user's control.

Core screens:

• Cycle-window predictions, the readiness score with its factor breakdown, and dismissible insight cards.
• A prediction banner with the current phase pill, a period-logging form (flow, symptom chips), and recent history.
• A grouped egg-quality checklist with a progress bar and a "why it matters" note on each item.
• Sub-tabs for log, trends, timing, and prep, with AMH and FSH trend charts, reference lines, age-adjusted interpretation, and the export button.

8. Success metrics and validation

Leading indicators

• Activation: target [X%] of new users logging a first cycle within the first session. Measured locally.
• Lab adoption: target [X%] of fertility-minded users logging at least one bloodwork result.
• Repeat logging: target [X%] of users logging two or more cycles (the threshold for regularity insights).

Lagging indicators

• Preparedness outcome: target [X%] of users reporting they felt more prepared for a clinical appointment. Measured via an optional prompt.
• Retention: target [X%] of users still logging at 60 days (a meaningful interval for cycle data).
• Trust: zero instances of the product being mistaken for medical advice, tracked through user feedback and the disclaimer's visibility.

All actuals are bracketed; both versions are self-use prototypes and no broad validation has occurred.

What didn't work, and what I'd change. Three honest reflections. First, the readiness score is a clinically rough approximation rendered as a confident number, and a confident number about fertility carries real emotional weight; I would pressure-test the model and its copy with a reproductive endocrinologist before putting it in front of strangers, and consider showing ranges rather than a single figure. Second, predictions assume a roughly 28-day cycle in the early logic, which is exactly wrong for the irregular cycles that often matter most in a fertility context; I would make the prediction engine learn each user's actual cycle length rather than defaulting to a textbook number. Third, maintaining two live versions (V1 and V2) is a portfolio asset but a maintenance and clarity liability: users could land on the older companion and miss the studio's lab tooling, so I would converge on V2 as the canonical product and redirect V1, keeping V1 only as a documented snapshot of the build progression.

9. What this project demonstrates

• Problem identification: locating the gap as fragmented, hard-to-interpret data at a time-sensitive decision point.
• Trade-off reasoning: a transparent rules-based score over a black box, and a deliberate V1-then-V2 sequencing.
• Technical fluency: clinical reference ranges, age-adjusted interpretation, trend charts, and a usable export specified and built.
• Domain and ethical judgment: staying firmly on the wellness side of the medical line, with honesty about the score's limits.
• Validation discipline: bracketed metrics and a stated need for clinician review before exposing the score widely.
• Communication and iteration: a single PRD that covers a real product line and is candid about what V2 improved and what still needs work.

Ritual: Product Requirements Document v2

Status: Draft for review

Date: May 2026

Version: 2.0 (rewrite of v1)

---

1. Problem Statement

Self-improvement apps have a retention crisis, and the existing playbook for fixing it is not working.

The benchmarks:

• Health and fitness apps average 6.3% Day 30 retention. Headspace sits at 7.65%, Calm at 8.34%. Insight Timer is the outlier at 16%, owing primarily to its free library and community model (Apptopia, StriveCloud 2026).
• In randomized controlled trials of mindfulness apps, attrition averages 38.7% in studies with 100+ participants per group; Calm-specific RCT dropout is 28.4% (Linardon et al., 2023).
• Across app categories, Day 7 retention averages 10 to 15%. Wellness apps with strong motivation design sit at the high end (Enable3, 2026).
• The habit formation literature finds median time to behavioral automaticity is 66 days, range 18 to 254 (Lally et al., 2010, European Journal of Social Psychology). The "21 days to a habit" and "30 days to a habit" claims that dominate consumer wellness apps have no empirical basis.

The diagnosis: current wellness apps optimize for content consumption (library models, autoplay, daily picks) rather than behavioral execution. Users feel busy without progressing. They open the app, complete a session, and have no scaffold for what comes tomorrow or what they are building toward.

Three structural failure modes:

1. Library overwhelm. Calm and Headspace each offer thousands of sessions. Beginners do not know which session, in what order, toward what outcome.
2. No defined endpoint. Subscriptions are designed for indefinite use. There is no "I finished it" moment that produces identity reinforcement or a shareable accomplishment.
3. Streaks as a brittle proxy. Daily streaks measure activity, not progression. Breaking a streak is demotivating; maintaining one rewards opening the app, not doing the work.

Couch to 5K, Duolingo, and Noom each succeeded by inverting these patterns: finite curriculum, structured progression, daily prescribed action.

---

2. Strategic Decision: Curated Product, Not Marketplace (Yet)

PRD v1 waffles between a creator marketplace (Substack, MasterClass model) and a curated wellness product (Calm, Future model). These are different companies with different unit economics, different defensibility, and different teams.

Decision: launch as a curated product. Defer marketplace to Phase 3 (post-seed validation).

Rationale:

• Marketplace dynamics require liquidity on both sides. At launch we have neither creators nor users. Two-sided cold starts are graveyards.
• Quality and trust are existential in wellness. Open creator submission introduces medical-claim risk, content moderation load, and App Store guideline exposure we cannot afford pre-PMF.
• The product hypothesis ("curriculum beats library") is testable with a single house-produced system. We do not need creators to falsify it.
• Once we prove that one 20-day system retains and converts, we can stand up a vetted creator program with quality controls. Until then, creators are a distraction from the core bet.

---

3. Target User and ICP

Primary ICP: "The Restarter."

Demographics: 28 to 45, urban, knowledge worker, household income $75K+. Female-skewed (60/40), consistent with meditation app DAU composition.

Psychographics:

• Has downloaded Calm or Headspace, used it inconsistently, and feels guilty about it
• Has tried 3+ wellness apps in the last two years
• Reads Atomic Habits, listens to podcasts about routines and rituals
• Self-identifies as "someone who knows what to do but cannot get themselves to do it"
• Will pay for measurable results; will not pay for inspiration

The key insight: this user does not need more content. They need a smaller, finishable thing they can actually complete.

Anti-ICP:

• Experienced meditators (already have a practice; the product is not for them)
• Users seeking clinical-grade mental health intervention (regulatory minefield, wrong product)
• Users who already love Calm or Headspace (we are not winning that switch)

---

4. MVP Wedge: 20-Day Meditation Reset

PRD v1 lists seven launch systems across fitness, yoga, meditation, emotional wellness, nutrition, music, and vocal training. That is not an MVP. It is a content company.

Pick one. Ship it. Prove the thesis.

Recommended wedge: 20-Day Meditation Reset

Why this one:

1. Lowest content production cost. Audio only, no video, no instructor coordination. One voice talent, one studio week, roughly 6 hours of finished audio.
2. Best fit for the "ritual" brand. Opening and closing audio reads native for meditation, awkward for triathlon training.
3. Strongest evidence base. Headspace RCTs show measurable stress reduction at 8 weeks; we can credibly claim measurable change at 20 days (e.g., the Headspace observational study showed a 23.5% reduction in PSS-10 scores among moderate-stress members).
4. Strongest market signal. Calm did $210M revenue in 2025, Headspace is comparable. TAM is proven. The opportunity is share capture, not category creation.
5. Cleanest competitive wedge. Calm and Headspace are libraries. We are a course.

---

5. Why 20 Days (Honest Version)

PRD v1 claims 20 days is optimal for "behavioral momentum." This is not supported by the habit literature.

Honest framing:

• 20 days is not enough to form a habit by Lally et al.'s 66-day median. We will not claim it is.
• 20 days is enough to (a) complete a defined curriculum, (b) experience measurable mood and stress change in line with published 4-week RCT data, and (c) generate a sharable completion moment.
• 20 days is short enough to feel finishable to a user with prior wellness-app drop-off history.

Positioning: "Your first 20 days. The start of a practice, not the end of one."

Phase 2 follow-on: a 40-day "Practice" system for graduates, framed as the next step. This handles the habit-formation gap honestly, reinforces the curriculum-over-library model, and creates a natural retention and upsell path.

---

6. Competitive Landscape

The whitespace: no product combines Calm-quality production, Waking Up-quality curriculum, and Duolingo-quality progression mechanics, marketed to the Restarter persona.

---

7. Differentiation Thesis

Three things, ranked by importance:

1. Finite curriculum over infinite library. Every user lands on a single 20-day program. No browsing. No autoplay. One next action, every day.
2. Practice mechanics over content mechanics. Timers, breath pacing, journal prompts, and reflection beats are integrated into each session, not separate features. The user is doing, not just listening.
3. Completion as the core unit of value. The product is designed around the "I finished it" moment: completion certificate, pre/post stress score, optional share card, invite to graduate program.

Explicitly not differentiating on at MVP: AI personalization, social feed, gamification badges, video, hardware integrations, live cohorts.

---

8. Success Metrics (with Targets)

Activation

• Day 1 session completion: 65% (industry top quartile for wellness onboarding is ~70%)
• Day 3 session completion: 45%

Retention

• Day 7 retention: 35% (vs. 10 to 15% industry average)
• Day 20 retention: 20%

Completion (the headline metric)

• Full 20-day completion rate among paid users: 25%
• Adherence (days completed / 20): 60% average

If completion lands above 25%, the thesis is validated and we raise seed on it. If it lands below 10%, the thesis is wrong and we either shorten the program (test a 10-day variant) or reposition.

Monetization

• Free-to-paid conversion (Day 7 paywall): 8% (Calm reports 3 to 5%, Duolingo Super 5 to 8%)
• Annual plan share of paid: 60%
• Month 3 paid retention: 70%

Outcomes (validation, not commitment)

• Pre/post PSS-10 score reduction among completers: 15% target (Headspace real-world study: 23.5%)

---

9. Risks and Dependencies

Product risks

• 20 days is still too long. Mitigation: A/B test a 10-day "Starter" variant in parallel; instrument every session for dropoff analysis.
• Audio fatigue from one voice. Mitigation: contract two voices; user can switch.
• Curriculum quality is the entire product. Mitigation: hire a senior teacher (Tara Brach lineage, Insight Meditation Society, or comparable) as Head of Curriculum on staff, not as a contractor.

Business risks

• CAC. Wellness paid acquisition on Meta runs $40 to $80 per install in 2026. Mitigation: lead with organic (TikTok, Substack, founder-led content) for first 6 months; treat paid as a Q4 lever.
• Subscription fatigue. The Restarter already holds 4+ wellness subscriptions. Mitigation: position as a 20-day program with an optional graduate plan, not "yet another monthly."
• Competitive response from Calm or Headspace. Medium risk. Both have launched course features and largely failed to make them sticky. Bet: they cannot reorient a library-first product without cannibalizing existing users.

Regulatory and platform risks

• App Store wellness claims. Cannot claim treatment of depression, anxiety, or any clinical condition. All marketing copy and in-product language reviewed by counsel.
• HIPAA. Not triggered unless we integrate with healthcare providers. Out of scope for MVP.
• Apple in-app purchase 30% fee. Plan for it. Consider web-to-app paid onboarding flow to capture annual subscriptions outside the IAP fee at launch.

Content and brand risks

• Cultural appropriation. Meditation traditions have lineage and sensitivity. Mitigation: use secular, evidence-based framing for MVP. Do not market a tradition we have not licensed instruction from.
• Trademark. Ritual Vitamins owns significant mindshare in adjacent wellness. Run a USPTO and common-law search before finalizing the name.

Cozy Diary, Product Requirements Document

Version: v4 (Final)

Status: Approved for build

Last updated: 2026-04-21

Document owner: Product

Tagline: Sign in and we'll take you back to your diary.

---

This is a condensed edition. The full 23-section technical PRD (data model, backend, state machines, test plan) is available on request.

1. Vision & Positioning

Cozy Diary is a calm, private, voice-friendly journaling web app. Each diary lives at its own URL, protected by a per-device PIN, with optional AI-powered mood insights. The experience aims to feel like paper but work like software: claim a private URL, write or speak entries, and watch your emotional landscape emerge over time.

Privacy is the default. Entries are owned by the writer, accessed via password and per-device PIN, and recoverable through a memorable phrase. The product is positioned against three categories it deliberately is not: clinical mental-health apps (too medical), mass-market note apps (too utilitarian), and social journaling platforms (not private). Cozy Diary sits in a quiet corner of its own: solitary, warm, reflective, and low-friction.

The product succeeds when a user opens the app, writes for three minutes, and closes it without noticing the interface. The interface is furniture; the writing is the point.

---

2. Target Users

All four personas share one trait: they want a journal, not a product. The app should feel like a tool they own, not a service they subscribe to.

---

3. Assumptions & Constraints

Platform. Responsive web only (mobile-first layout). No native mobile app in v1. No desktop installer.

Auth provider. Supabase Auth with email and password. No OAuth, no magic-link-only flows, no anonymous sessions in v1.

Backend runtime. Supabase Edge Functions (Deno, TypeScript). PostgreSQL with RLS. No custom backend services.

AI features. Mood analysis and weekly summary run on demand, not in real time. Transcription runs per-recording, synchronously from the user's point of view.

Account shape. One diary slug per account in v1. No multi-diary, no shared diary, no team accounts.

Browser support. Latest two stable versions of Chrome, Safari, Firefox, and Edge. iOS Safari 16 and newer. Android Chrome 110 and newer. Graceful degradation on older browsers (sign-in works, voice may not).

Internationalization. English copy only in v1. Timezone is the browser's local zone for display; dates stored in UTC.

Connectivity. The app assumes online operation. An offline mode is in scope for a future version.

---

4. Feature Inventory

4.1 Authentication & Access

Email-plus-password accounts are the only identity path. Passwords require 8 or more characters with at least one number or symbol. A 4-digit PIN is registered per device, hashed with PBKDF2 (200,000 iterations, SHA-256, per-device salt). Device identity is a browser fingerprint scoped to the browser-and-device pair; the fingerprint is stable across visits but resets when site data is cleared.

Recovery uses a 12-word BIP39 phrase (at least 128 bits of entropy), stored as a bcrypt hash (cost 12). The prior 4-word-from-24 scheme is rejected as cryptographically weak (19 bits, brute-forceable). Recovery invalidates all other device PIN rows for the user.

Lockout escalates on the server. After 5 failed PIN attempts on a device, a 30-second cooldown applies. Subsequent failure rounds double the cooldown (30s, 60s, 120s, 240s) up to a cap of 30 minutes. Cooldown state is server-enforced and not bypassable by clearing localStorage.

Unlock state has two timers: a 30-minute TTL in localStorage for navigation within a session, and a 5-minute idle auto-lock measured by user-input events. The idle lock is a stricter constraint and overrides the TTL.

Password reset flows through an emailed link and renders at /reset-password. Tokens expire in 1 hour.

4.2 Diary URLs & Slug System

Each account owns exactly one slug. Slugs are 3 to 40 characters, lowercase alphanumeric with hyphens ([a-z0-9-]), no leading or trailing hyphens, no consecutive hyphens. Slugs are immutable in v1 (rename is listed as future work).

Reserved slugs cannot be claimed: admin, api, signin, signup, reset-password, insights, settings, about, help, privacy, terms, d, static, healthz, www, mail, root.

The slug-status edge function returns { status, hint? } where status is available, claimed, reserved, or invalid. Visiting a claimed slug while signed out renders the sign-in prompt, not the Claim screen. Visiting an unclaimed slug while signed in offers to claim it or switch to the user's existing slug.

4.3 Writing (Editor)

The Editor has an optional title field (plain text, 120-character limit) and a rich-text body (no hard limit; a soft warning appears past 10,000 characters). Autosave fires every 10 seconds and on blur or route change. The Cmd+S or Ctrl+S shortcut triggers a manual save.

Voice recording opens a modal with a single record button, waveform visualization, a 5-minute timer, and a submit action. Audio is sent to transcribe and the returned text is inserted at the cursor position. The audio itself is not persisted server-side.

Spell check runs automatically after 3 seconds of typing inactivity and can be triggered manually. Suggestions with confidence at or above 0.9 are auto-applied when the user has enabled that setting; others are shown as inline underlines with a dropdown.

Draft recovery: if the user navigates away with unsaved content, a "Restore unsaved draft?" banner appears on the next entry open.

4.4 Insights

Insights is gated until at least three entries have been analyzed (not merely written). The mood chart shows one dot per analyzed entry across a rolling 90-day window, with valence on the Y-axis (0 to 1, where 1 is most positive) and date on the X-axis. Dots are colored by dominant emotion and shaped distinctly so color is not the sole differentiator.

The emotion bars show the aggregate share of each Atlas of Emotions category across analyzed entries in the window. The weekly summary card generates a narrative paragraph from weekly-summary, scoped to the last seven days. If fewer than two entries exist in that window, the card shows a "Not enough data yet" state.

A Re-analyze button re-scores all entries (useful after edits). It is throttled to one invocation per 10 minutes per user.

4.5 Settings

Settings include:

• auto_apply_high_confidence toggle for spell-check
• Slug display (read-only)
• Email display (read-only; linked to password reset)
• Forget this device (removes the current device's row in pin_devices)
• Delete account (destructive; requires password confirm; hard-deletes all entries, settings, device rows, and mood scores)

---

5. Information Architecture

The complete route map:

/                              Landing (slug picker + sign-in link)
/signin                        Centralized sign-in
/reset-password                Password reset landing (from email link)
/d/:slug                       Diary shell
  → ClaimDiaryScreen           (slug unclaimed)
  → SignInPromptScreen         (slug claimed, signed out)
  → SetDevicePinScreen         (signed in, no device PIN, skippable)
  → LockScreen                 (signed in, device PIN set, not unlocked)
  → HomeScreen                 (unlocked: default tab)
  → EditorScreen               (unlocked: new or existing entry)
/d/:slug/insights              Insights (mood chart + summary)
/d/:slug/settings              Settings (toggle + device mgmt + danger zone)
*                              NotFound

The diary shell at /d/:slug routes to one of six sub-screens based on auth and device state.

---

6. Security & Privacy

6.1 Controls

• RLS on every user-owned table; policies scoped to auth.uid().
• PINs never leave the device in plaintext; only PBKDF2 hashes are stored.
• Recovery phrases stored as bcrypt hashes (cost 12). Never logged. Never returned after initial reveal.
• Device-scoped PINs prevent a leaked PIN from unlocking other devices.
• Server-enforced lockout with exponential backoff; not bypassable client-side.
• 5-minute idle auto-lock; 30-minute unlock TTL covers intentional navigation only.
• Recovery invalidates all other device PIN rows.
• All edge function responses include Cache-Control: no-store.
• body_plain (used for mood scoring) is stored separately and never included in entry-list responses.
• TLS required on all origins. HSTS enabled with a 1-year max-age.
• Supabase JWTs are short-lived (1 hour) with refresh tokens.

6.2 STRIDE Threat Model

6.3 Data Privacy & Compliance

Data residency. The Supabase region is documented on the privacy page. Users can see where their data is stored before claiming a diary.

Retention. Entries are retained until the user deletes them individually or deletes their account. Account deletion is a hard delete; there is no soft-delete or grace period in v1.

Right to erasure (GDPR Art. 17, CCPA). Satisfied by the "Delete account" flow in Settings. Deletion cascades through all related tables. Confirmation is via password re-entry; a second email confirmation is under consideration for v2.

Right to access (GDPR Art. 15). Not yet satisfied in v1; export is listed as future work. A manual data-request email workflow is documented in the internal operations handbook.

AI processing disclosure. Mood analysis sends body_plain to the LLM endpoint. This is disclosed in plain language on the privacy page. Entry content is not used for model training; the vendor contract prohibits training use.

Analytics. No third-party analytics in v1. Error monitoring (Sentry) has a strict payload allowlist: no entry content, no email addresses, no PII beyond user ID.

Cookie policy. Session cookies only; no advertising or marketing cookies. Local storage is used for the unlock TTL and nothing else.

---

7. Design Language

Typography. Serif headings for a paper feel (for example, Fraunces or Lora). Sans-serif body for readability (for example, Inter-substitute or Söhne). No system-font stack.

Surfaces. A paper utility class renders a warm off-white card on a subtle background tint. Borders are 1px solid at low opacity; no drop shadows on cards.

Motion. animate-fade-in for entry transitions. transition-gentle (250ms, ease-out) for hover and state changes. All motion respects prefers-reduced-motion. No spring physics, no bounce, no parallax.

Iconography. Lucide icons at strokeWidth={1.5}, 20px sizing.

Tone. Quiet, encouraging, never clinical. The product speaks in first-person plural ("we'll take you back to your diary") and refers to the user's content as "yours". Error messages are warm and specific. Avoid: diagnostic framing, streak language, nudging.

Density. Low. Generous line height (1.6 for body, 1.2 for headings). No data tables shown to users. Entry list uses calendar-style grouping with labels between groups.

Color. A warm neutral palette: off-white paper, deep slate text, a single muted accent (dusk blue or sage). Emotion-category colors for the chart and bars; these are chosen from a color-blind-safe palette.

---

8. Non-Goals (v1)

• Social or sharing features. Diaries are single-user.
• Native mobile apps.
• Entry export or import.
• Multiple diaries per account.
• Team or family accounts.
• Reminders, streaks, or gamification.
• Slug rename.
• End-to-end encryption of entry bodies.
• OAuth or social sign-in.
• Offline mode.
• Rich media attachments.
• Search across entries.
• Tags or custom prompts.

---

9. Open Questions & Future Work

---

10. Success Metrics

Affirmations (Daily Bloom) - PRD

One-line summary: A daily affirmations app that helps people ground themselves and build a positive mindset through swipeable cards, themed categories, and streak-based habit reinforcement.

Problem

People who want to build a more grounded, resilient mindset struggle to make affirmations a consistent habit. Generic content feels impersonal, existing apps bury the core experience under paywalls and clutter, and there is no lightweight loop that makes returning daily feel rewarding. The result is high install-to-abandon rates and little real behavior change.

Target users

• Primary: Adults 18 to 40 who already practice or are curious about mindfulness, journaling, or self-improvement and want a low-effort daily ritual.
• Secondary: People in transition (new job, breakup, recovery, big move) seeking emotional grounding during a stressful stretch.
• Tertiary: Wellness-curious users who follow affirmation content on social media and want a dedicated home for it.

Goals and Non-goals

Goals

• Make the daily affirmation ritual feel effortless and emotionally resonant.
• Drive a sticky daily-return habit through streaks and gentle reminders.
• Let users tailor content to where they are in life via categories.

Non-goals

• We are not building a full meditation or therapy platform.
• We are not adding social feeds, comments, or follower mechanics at launch.
• We are not offering clinical mental-health claims or crisis support.

Key features

P0 (launch)

• Swipeable affirmation cards with one affirmation per card and smooth gesture navigation.
• Category selection (for example Confidence, Calm, Self-Love, Growth, Gratitude) that filters the daily set.
• Daily streak counter with a visible flame or bloom that grows with consecutive days.
• Daily push reminder at a user-chosen time.
• Favorite or save an affirmation to a personal collection.

P1 (fast follow)

• Theming and typography options so cards feel personal (light, dark, seasonal palettes).
• Shareable card images for social posts.
• Widget for home screen showing the affirmation of the day.
• Streak recovery (one grace day) to reduce churn from a single missed day.

P2 (later)

• Personalized affirmation suggestions based on saved cards and categories.
• Audio narration with ambient backgrounds.
• Custom affirmations written by the user.

Success metrics

North-star metric: Weekly active users who complete at least one daily affirmation session on 4 or more days per week (Engaged Weekly Actives).

Supporting metrics

• Day-7 and Day-30 retention.
• Median streak length and percentage of users with a 7-plus day streak.
• Reminder opt-in rate and session conversion from reminder.
• Saves per active user and share rate.

Key risks and mitigations

• Novelty churn: affirmations can feel repetitive. Mitigate with a large, rotating content library, category variety, and a freshness rule that avoids repeating recent cards.
• Reminder fatigue: push notifications can feel naggy. Mitigate with a single daily reminder, easy time customization, and smart suppression when the user already opened the app.
• Content tone mismatch: affirmations can feel hollow or off. Mitigate with editorial review, tone-tested copy, and category-level personalization.
• Monetization friction: aggressive paywalls drive abandonment. Mitigate by keeping the core daily ritual free and reserving premium for themes, audio, and custom content.

Phased rollout

• Phase 1 (Weeks 1 to 4): Closed beta: core card swipe, categories, streaks, and reminders with a curated content library. Ship to 200 to 500 testers and instrument the engagement loop.
• Phase 2 (Weeks 5 to 8): Public launch: add favorites, sharing, and the home-screen widget. Open app store availability and begin lightweight organic growth.
• Phase 3 (Weeks 9 to 16): Personalization and monetization: introduce theming, streak recovery, premium tier (audio, custom affirmations, advanced themes), and personalized suggestions, optimizing against the north-star.

Path

A calm, journey-based life-balance app that helps the user act from a grounded place instead of reaching from empty.

The 30-second version. Path is a private, journey-based app built around a single behavioral insight: the user's central pattern is reaching from empty and chasing a goal in a way that defeats it, across friendships, romance, and her relationship with her own body. So Path is state-aware, not a streak tracker. Before any reaching or practicing action, it asks whether the user is acting from full or from empty, present or chasing, and offers a grounding ritual when the honest answer is empty. I built it solo on Lovable, inspired by Fabulous, with one calm thing at a time, a maximum of two active habits per journey, and progress that pauses without shame. It demonstrates designing for a real person with real constraints, encoding a psychological model into product mechanics, and the restraint to build something gentle rather than gamified.

---

Timeline: Weekend prototype, built as a private single-user app, in personal use.

---

1. Problem statement

This is a personal build for a single, specific user, and the problem is stated plainly in the brief. The user's central pattern is reaching from empty and chasing a goal in a way that undermines it. When lonely or dysregulated, she reaches for friends who do not reciprocate and partners who are unavailable; when frustrated about her body, she chases an outcome in a way that blocks it. The reaching and chasing make things worse, which depletes her, which drives more reaching. The cost is a self-reinforcing loop across three areas of life. Streak-based habit apps would make this worse, because they reward compulsive doing and punish the missed days that already trigger shame. What is missing is not more tracking; it is a moment of honest self-check before action: are you full or empty, present or chasing. That check is the spine of the product.

2. Goals and non-goals

Goals

• Help the user notice and interrupt reaching-from-empty before she acts, across friends, romance, and the body (user outcome).
• Build a small number of grounding habits that compound, one calm thing at a time (user outcome).
• Make progress feel like a path that grows, where a missed day pauses growth but never breaks it with shame (user outcome).
• Keep the most sensitive area private and safe, so the app feels like a steadying hand rather than another source of pressure (trust outcome).

Non-goals

• Streaks, badges, or guilt mechanics. Out of scope; they reinforce the exact compulsive pattern the app exists to interrupt.
• Long daily to-do lists or a dense multi-journey dashboard. Out of scope; one focus at a time is the design.
• More than two active habits per journey. Out of scope; new ones unlock only after sustained engagement.
• Social, sharing, or multi-user. Out of scope; this is a private tool for one person.
• Surfacing the heaviest personal context on the home screen. Out of scope; that context lives one layer down, by choice.

3. The product

Three preloaded journeys, each with stages, a small set of habits, and a gate that precedes action.

The daily loop is Fabulous-style and calm. A morning check-in ("How full are you today?") sets a fullness rating and slept/ate/moved toggles; low fullness shifts the day toward grounding. Active habits then surface one at a time as single cards (done / not today), never as a list of all three journeys. When a reaching action is triggered, the full/empty gate runs first; when a Body session is triggered, the chasing-check gate runs first; if the honest answer is empty or chasing, the app offers the grounding ritual or a gentle movement track instead. An optional evening reflection offers one rotating prompt from the journey the user engaged with.

The signature mechanics are the gates. The Friends and Romance full/empty gate asks, before reaching out, whether the user genuinely wants to connect or is reaching to fill loneliness; if loneliness, it steers her to breathe and ground first. The Romance availability check is five plain questions (have they told you in words what they want; does it match what you want; are they consistent; do they reciprocate; are they actually available) plus a reflection on whether she is hoping someone changes. The persistent grounding ritual (cold water, three breaths, an affirmation, and "what do you actually need right now, not who, what") is always one tap away.

4. User stories

As someone who reaches out from loneliness, I want a gentle check before I message a friend, so that I act from a grounded place instead of from empty.

As someone drawn to unavailable partners, I want a short availability check before I invest, so that I catch the pattern before I attach.

As someone who tends to chase outcomes, I want a presence-first, timed practice with no goal, so that I can build a calmer relationship with my own body.

As someone who has been shamed by streak apps, I want a missed day to pause my growth, not break it, so that the app stays a steadying hand.

As a private user, I want an optional passcode and local-only data, with sensitive context one layer down, so that I trust the app with something personal.

Edge/empty state. As a user on a depleted morning, I want low fullness to gently reshape the day toward grounding rather than presenting the usual habits, so that the app meets me where I am instead of adding pressure.

5. Requirements

Must-have (P0)

• Local persistence and an optional passcode lock on open, required for the Body journey. Given the passcode is enabled, when the app opens, then it is required before the Body journey is accessible.
• Three preloaded journeys with stages and a capped set of habits (max two active per journey, new ones unlock after the threshold of check-ins).
• The daily ritual loop: morning fullness check-in, one-at-a-time habit cards, optional evening reflection.
• The two gate types: the full/empty gate before reaching actions (Friends, Romance) and the chasing-check gate before Body sessions.
• The persistent grounding ritual reachable at any time.
• The Romance availability check (five questions plus the change-hope reflection).
• Progress that grows with completion and pauses, never shames, on a missed day.

Nice-to-have (P1)

• Self-recorded guided audio in the user's own voice for sessions and the grounding ritual.
• Body journey timed, paced tracks (movement and sensation practice) with a rotating per-session focus.
• Private context held "one layer down" with the option to keep it hidden.

Future (P2)

• Gentle longitudinal reflections on which gates fire most and what grounds her best.
• A second pass on stage unlocks and teachings as the journeys are lived.

6. Key product decisions and trade-offs

State before action: gate every reaching or practicing action. Alternatives considered: a conventional habit tracker that just logs completions (rejected, it rewards doing regardless of why, which is the exact loop to interrupt); reminders and nudges (rejected, more pressure). Why this won: the full/empty and chasing-check gates are the behavioral crux, asking "from full or from empty" before the action is what makes the app therapeutic rather than performative. Hard trade-off: gates add friction to the very actions the user wants to take, and on some days that friction may feel like an obstacle; that friction is the point, but it must stay gentle, never preachy, or the user will route around it.

No streaks, ever; a missed day pauses growth. Alternatives considered: streaks for motivation (rejected outright, they punish the bad days that already trigger shame and reinforce compulsive doing). Why this won: progress that pauses without breaking keeps the app a steadying hand and refuses to weaponize guilt. This is non-negotiable for this user.

One thing at a time, two active habits per journey. Alternatives considered: a full multi-journey dashboard (rejected, dense dashboards recreate overwhelm and the chase). Why this won: calm pacing and a single focus per screen match the user's need; new habits unlock only after sustained engagement, so the app never front-loads pressure.

Privacy by design: passcode, local data, sensitive context one layer down. Alternatives considered: surfacing the full personal context on the home screen for "richness" (rejected, the heaviest material does not belong on a daily home screen); cloud sync (rejected for a single-user private tool with sensitive content). Why this won: a private, gentle, locally-stored app, with the Body journey gated behind an optional passcode, is what makes the product safe to use.

The Body journey never measures the outcome it is about. Alternatives considered: tracking outcomes for "feedback" (rejected, it would re-introduce the chasing the journey exists to undo). Why this won: the app asks only "what felt good" and "did you stay relaxed," never the goal question, with a timer that ends each session, so the mechanics enforce presence over pursuit. This is an evidence-informed design choice, not a guess.

7. UX

The aesthetic is warm, editorial, and grounded, like opening a beautiful journal rather than a SaaS dashboard: a cream background, near-black ink, a warm serif (Fraunces) for headings and teachings, a clean sans for body, and a distinct color per journey (moss for Friends, plum for Romance, warm clay for the Body). Motion is gentle; a path or garden grows with completion and pauses, never shames, on a missed day. The voice is wise-older-sister: warm and direct, never girlboss, never clinical, no emojis unless the user adds them.

Core screens:

• A calm journal-like surface with the morning fullness check-in and a single active-habit card.
• The full/empty check before a reach-out, with grounding offered when the answer is empty.
• The five-question Romance vetting flow plus the change-hope reflection.
• A session that opens with the no-goal frame, a timer, and the chasing-check gate.
• The persistent calm button: cold water, three breaths, an affirmation, and "what do you actually need."

8. Success metrics and validation

Because Path is a private single-user app, validation is about whether it changes the user's behavior and feeling, not adoption metrics.

Leading indicators

• Gate engagement: [X%] of reaching actions where the user runs the full/empty gate first. Measured locally.
• Grounding use: how often the grounding ritual is chosen when the gate surfaces "empty." Measured via state-checks.
• Calm pacing held: the app never shows more than the intended one-at-a-time focus (a design invariant, verified by inspection).

Lagging indicators

• Pattern interruption: a self-reported reduction in reaching-from-empty episodes over time, captured through reflections.
• Felt outcome: a trend toward acting from full and feeling from presence across the three journeys, in the user's own words.
• Sustained, unpressured use: continued engagement without the app ever becoming a source of guilt.

All actuals are bracketed; this is a private prototype in personal use and is not measured as a multi-user product.

What didn't work, and what I'd change. Three honest reflections. First, gates are friction, and friction placed in front of the actions someone most wants to take can quietly train avoidance of the app itself; I would watch for whether the user starts skipping the app to skip the gate, and soften or shorten the gate copy if so, because a gate that gets routed around does nothing. Second, the app encodes a specific psychological model (reaching from empty, chasing defeats the goal) that fits this user well but is not clinically validated and is not a substitute for therapy; I built in pointers to outside resources and sliding-scale support, and I would keep that boundary explicit rather than letting the app feel like treatment. Third, building for a single known user is a strength (deep fit) and a risk (no external signal), so I have no idea whether the gate mechanic generalizes; if I ever wanted Path to serve more than one person, I would need to test whether the full/empty check resonates beyond the person it was designed for, and I would not assume it does.

9. Open questions and roadmap

• Do the gates stay gentle enough to interrupt the pattern without training avoidance of the app? (user, design)
• Where exactly is the line between a supportive ritual and something that implies treatment, and how do we hold it? (clinical, user)
• Does the full/empty mechanic generalize beyond a single user, or is its power in the personal fit? (user, product)
• Is self-recorded audio in the user's own voice the right intimacy, and does it hold up over time? (user)

v2 scope: self-recorded guided audio, the fuller Body journey tracks with rotating focus, and gentle longitudinal reflections on which gates fire most.

Market positioning: against streak-driven habit apps and against calm-but-generic wellness apps, Path's distinctive move is the state-before-action gate. Even kept private, it demonstrates a design philosophy: refuse gamification, design for the why behind the action, and treat restraint as the feature. The public-facing artifact is a walkthrough of the design, not an invitation to a shared product.

10. What this project demonstrates

• Problem identification: translating a precise behavioral insight (reaching from empty) into the product's core mechanic.
• Trade-off reasoning: choosing gates and friction over engagement loops, and owning the avoidance risk that creates.
• Design for a real user with real constraints: privacy, gentleness, and a hard refusal of shame mechanics, built for one specific person.
• Domain and ethical judgment: an evidence-informed Body journey that never measures the outcome it is about, with clear outside-resource boundaries.
• Restraint: capping habits, journeys, and home-screen density on purpose.
• Communication: a spec that conveys a calm, grounded product philosophy as clearly as its features.

Lull

A focused sleep app that does one thing: help you wind down and put the phone down at a consistent time.

The 30-second version. Lull is a deliberately small sleep app with exactly three features: an automatic Wind Down that activates 45 minutes before your target sleep time, a Wrap It Up button with 4-7-8 breathing for any moment you need it, and a Morning Payoff that logs how you slept and feels and surfaces one honest insight. No accounts, no streaks, no social, no clutter. I built it solo on Lovable, dark-mode only, optimized for one-handed use, with everything stored locally so a user can start in seconds. It demonstrates the discipline of ruthless scoping: shipping three features that compound rather than ten that distract.

---

Timeline: Weekend prototype, in self-use testing.

---

1. Problem statement

A large share of people do not sleep poorly because they lack information; they sleep poorly because the hour before bed is unstructured and full of a glowing phone. The gap between "I should wind down" and actually putting the phone down is where consistent sleep dies. Most sleep apps make this worse: they pile on libraries of sounds, sleep-stage analytics, paywalls, accounts, and streaks that turn rest into another performance to optimize. The cost of the status quo is a nightly drift past the intended bedtime, compounding into chronic short sleep. Lull's hypothesis is that the highest-leverage intervention is not more data, it is a calm, near-zero-friction ritual that nudges a single behavior: be asleep by a consistent time.

2. Goals and non-goals

Goals

• Help the user fall asleep at a consistent time by structuring the 45 minutes before it (user outcome).
• Make winding down feel calm and effortless, not like another task to manage (user outcome).
• Give the user one honest, motivating insight that connects bedtime to how they feel (user outcome).
• Prove that a three-feature sleep app can change behavior without accounts, streaks, or upsells (product outcome).

Non-goals

• Sleep-stage tracking or wearable integration. Out of scope; the bet is behavior change, not measurement.
• Accounts or login for the MVP. Out of scope to keep time-to-first-use near zero.
• Streaks, badges, or gamification. Out of scope because pressure undermines rest.
• Social or sharing features. Out of scope; sleep is private and solitary by design.
• A large content library. Out of scope; four ambient options are enough, more is clutter.

3. The product

Three features, reachable in no more than three taps, on a single calm home screen showing tonight's target, the current time, one "Wrap it up" button, and a link to history.

1. Wind Down (automatic). Activates on its own 45 minutes before the saved sleep target. A full-screen breathing gradient, a chosen ambient track (Rain, Binaural Beats, Lo-fi, or Silence), and a live countdown ("Winding down, sleep in 32 min"). The app locks into a calm state with only two choices: "I'm ready to sleep" (logs actual sleep time, transitions to a blank dark screen with a single moon) or "Not yet" (dismisses for 15 minutes, then re-prompts gently).
2. Wrap It Up (on demand). A button for any moment. A calming transition screen, the user's chosen ambient audio, then a guided 4-7-8 breathing animation (inhale 4, hold 7, exhale 8) for three automatic cycles, ending with "Ready to put the phone down?" and a goodnight log or a few more minutes.
3. Morning Payoff. At wake time, one question: "How do you feel this morning?" on a five-emoji scale. Then a single insight card (last night's sleep time, mood score, and a one-line comparison to the recent average), plus a 14-night history chart with mood color-coded on each bar and one auto-generated pattern insight ("Your best mornings follow nights you're asleep by 11:15pm").

The data model is intentionally tiny: per night, the target sleep time, the actual sleep time, the morning mood score, and the date. Everything is local.

4. User stories

As someone who scrolls past my bedtime, I want the app to start winding me down automatically, so that I do not have to remember or decide to begin.

As someone wound up at night, I want a quick breathing exercise on demand, so that I can settle without hunting through menus.

As someone curious whether bedtime matters for me, I want one honest insight linking when I slept to how I feel, so that I am motivated by my own data rather than generic advice.

As a first-time user, I want to start with a single question and no sign-up, so that I am using the app within seconds.

Edge/empty state. As a user on my first morning with no history, I want a graceful single-night card instead of an empty chart, so that the app feels alive from day one rather than waiting for two weeks of data.

5. Requirements

Must-have (P0)

• First-launch setup capturing sleep target and wake time, no account. Given a first open, when the user picks the two times, then they are saved locally and setup is complete.
• Wind Down auto-activation 45 minutes before target. Given the saved target, when the clock reaches target minus 45, then the full-screen calm state activates with countdown and chosen audio.
• "I'm ready to sleep" logs actual sleep time; "Not yet" re-prompts after 15 minutes.
• Wrap It Up with the 4-7-8 breathing animation, three cycles, and a goodnight log.
• Ambient audio with four options and saved preference.
• Morning Payoff mood capture, insight card, and 14-night history chart with one auto-generated insight.
• Local persistence of target, actual sleep time, mood, and date per night.

Nice-to-have (P1)

• Optional account and cloud sync (for multi-device users).
• True OS notifications at wind-down and wake time (vs in-app reminders).
• A second ambient pack.

Future (P2)

• Gentle longitudinal nudges if bedtime is drifting later over weeks.
• Optional wearable import for users who want it, without making it central.

6. Key product decisions and trade-offs

Exactly three features, no more. Alternatives considered: a fuller sleep suite with analytics and a sound library (rejected, that is the cluttered product the user is escaping). Why this won: each feature targets a distinct moment (the scheduled wind-down, the on-demand reset, the morning reflection) and they compound. Hard trade-off: a thin feature set is easy to dismiss as simplistic and harder to differentiate on a feature-comparison chart; I accepted that because restraint is the entire value proposition.

No accounts, local-only storage. Alternatives considered: require sign-up for sync and retention hooks (rejected, friction at exactly the wrong moment, and it makes the app feel heavy). Why this won: time-to-first-use near zero matters more than cloud features at MVP. Trade-off owned: data is trapped on one device and lost if cleared; sync becomes a clear P1 once the core loop is proven.

Automatic Wind Down instead of a manual button. Alternatives considered: a "start wind down" button (rejected, it relies on the very willpower the user lacks at night). Why this won: the app initiates the ritual so the user does not have to, which is the behavioral crux. Wrap It Up still exists as the manual on-demand path.

No streaks or gamification. Alternatives considered: a streak counter for stickiness (rejected, it converts rest into performance and punishes the bad nights people already feel bad about). Why this won: the morning insight motivates through self-knowledge, not guilt.

7. UX

Dark-mode only, by design, because the product lives at night. Deep navy and warm amber, soft rounded corners, large readable type for tired eyes, one-handed reach. Every screen is meant to feel like it is already winding you down just by looking at it.

Core screens:

• A single question, a time picker, no account.
• Tonight's target large and centered, current time, one "Wrap it up" button, a history link.
• Full-screen breathing gradient, live countdown, and only two calm choices.
• The 4-7-8 breathing circle with clearly labeled phases.
• One mood question, a single insight card, and the 14-night chart.

8. Success metrics and validation

Leading indicators

• Wind-down engagement: target [X%] of nights where the user reaches the wind-down state. Measured locally.
• Goodnight logging: target [X%] of nights with a logged actual sleep time. Measured via the nightly record.
• Morning completion: target [X%] of mornings with a mood entry.

Lagging indicators

• Consistency: target a reduction of [X] minutes in the variance between target and actual sleep time over two weeks.
• Felt outcome: target an upward trend in average morning mood for users who hit their target. Measured from the history data.
• Retention: target [X%] of users still logging at 14 nights.

All actuals are bracketed; this is a self-use prototype and no broad usage has been validated.

What didn't work, and what I'd change. Three honest reflections. First, local-only storage means I cannot actually measure cohort retention or behavior change across users, which is the metric that matters most; without an account or anonymous telemetry, my success metrics are aspirational, and I would add privacy-respecting analytics before claiming the app changes behavior. Second, in-app reminders are weaker than true OS notifications, and a PWA that is not open cannot reliably trigger the automatic Wind Down, which undercuts the single most important feature; I would prioritize real notifications even though it adds platform complexity. Third, the auto-generated "best mornings follow nights you're asleep by 11:15pm" insight is only as good as the pattern logic behind it, and with sparse early data it risks asserting correlations that are noise; I would gate that insight behind a minimum number of nights and label confidence honestly.

9. Open questions and roadmap

• Can a PWA reliably trigger time-based wind-down and wake prompts, or does this need a native shell? (eng)
• How many nights of data are needed before the pattern insight is trustworthy? (data)
• Does sync improve retention enough to justify introducing accounts? (data, user)
• Is 45 minutes the right wind-down lead time, or should it adapt to the user? (user, data)

v2 scope: optional sync, true notifications, and a confidence-gated insight engine.

Market positioning: against feature-heavy sleep platforms, Lull competes on calm and immediacy. Its defensibility is taste and restraint rather than a content moat, and the bet is that a meaningful segment wants exactly less.

GTM hypothesis: the product is small enough to be its own pitch ("a sleep app with three features and no account"), well suited to word-of-mouth and a single strong landing page rather than paid acquisition.

10. What this project demonstrates

• Problem identification: isolating the pre-bed hour and a glowing phone as the real failure point, not a lack of data.
• Trade-off reasoning: defending a three-feature scope and local-only storage, and owning what each costs.
• Technical fluency: a minimal data model, an automatic time-triggered state machine, and a 14-night insight chart specified cleanly.
• Validation discipline: acknowledging that local-only storage limits what can be measured, with bracketed targets.
• Roadmap sense: a clear ordering (prove the loop, then add sync and notifications) rather than building everything at once.
• Communication: a spec that mirrors the product's own calm and clarity.

Morning

A morning routine app that turns the hardest part of the day, getting started, into a repeatable momentum ritual.

The 30-second version. Morning is a small app built to solve a specific, personal problem: getting out of bed and actually starting the day when you have a million things to do and none of them feel possible yet. Each morning you set three big things and five small ones, so you begin with clear direction instead of paralysis. I built it solo on Lovable, scoped tightly around the friction of the first hour rather than a full habit-tracker. It demonstrates starting from a real, observed user pain (my own), translating it into the smallest mechanic that relieves it, and resisting the urge to over-build.

---

Timeline: Weekend prototype, in self-use testing.

---

1. Problem statement

Plenty of capable people stall at the very start of the day. The problem is not a lack of things to do; it is the opposite. With a million tasks and a million wants competing at once, the morning offers no clear first move, and the cost of an undefined start is a slow, heavy beginning that bleeds momentum into the rest of the day. This is the stated problem in the founder's own words: "even though I have a million things to do and a million things that I wanna do, it's still really hard to just get started." General productivity apps make this worse by presenting an overwhelming backlog at exactly the moment the user needs less, not more. Morning's hypothesis is that a tiny, structured ritual (a few big intentions and a few easy wins) gives the day a clear direction and the first small completion that builds momentum.

2. Goals and non-goals

Goals

• Give the user a clear first move each morning, so starting is easier than staying in bed (user outcome).
• Reduce morning overwhelm by capping the day's focus to a few big and a few small things (user outcome).
• Generate early momentum through quick, achievable wins (user outcome).
• Prove that a single-purpose morning ritual changes how the day begins, without becoming a full task manager (product outcome).

Non-goals

• A full task manager or backlog. Out of scope; surfacing everything is the problem this app exists to avoid.
• Projects, due dates, or tags. Out of scope; complexity defeats the calm-start purpose.
• Streaks or guilt mechanics. Out of scope; a missed morning should not punish the user into avoidance.
• Social or sharing features. Out of scope; the morning ritual is personal.
• Evening or all-day planning. Out of scope at MVP; the bet is specifically on the first hour.

3. The product

The core mechanic is one screen, done once each morning.

1. Set three big things. The day's top priorities, capped at three, so the user picks what actually matters rather than listing everything.
2. Set five small things. Quick, easy wins (a glass of water, one email, a short walk) that produce immediate completions and momentum.
3. Check them off through the day. Each completion is a small, visible win; the three big and five small structure keeps the list short enough to feel possible.

The cap is the product. Three plus five is enough to give direction and early wins, and few enough to never feel like a backlog. Suggested additions from the original brainstorm (and natural P1s) include a single "first move" the user commits to before getting up, a brief why-it-matters line per big thing, and an end-of-day glance at what got done.

4. User stories

As someone who struggles to get out of bed, I want to name three big things and five small ones first, so that I start the day with direction instead of paralysis.

As someone overwhelmed by everything I could do, I want a hard cap on how much I plan, so that the morning feels possible rather than crushing.

As someone who needs momentum, I want a few easy wins I can check off quickly, so that early completions pull me into the day.

As a returning user, I want yesterday cleared and a fresh, empty morning, so that the app is about today, not an accumulating backlog.

Edge/empty state. As a user on a low-energy morning, I want it to be fine to fill in only one or two items and still feel I have started, so that the app never shames a small start.

5. Requirements

Must-have (P0)

• Set up to three big things and five small things for the day. Given a new morning, when the user adds items, then they are saved as today's list within the caps.
• Check off completion with a clear, satisfying state. Given an item, when the user marks it done, then it is visibly completed.
• A clean daily reset. Given a new day, then the list starts fresh without yesterday's clutter.
• Local persistence of the day's items and completion state.

Nice-to-have (P1)

• A single "first move before you get up" commitment.
• An optional one-line "why this matters" per big thing.
• A gentle end-of-day summary of what got done.
• An optional morning reminder.

Future (P2)

• Light reflection on which mornings felt best and why.
• Optional sync and an account for multi-device users.

6. Key product decisions and trade-offs

Cap the list at three big and five small. Alternatives considered: an unlimited to-do list (rejected, it recreates the overwhelm that is the actual problem); a single MIT-style "most important task" (rejected, too thin to give the day shape or generate quick wins). Why this won: three big items force prioritization while five small ones manufacture early momentum, and the cap keeps the screen from ever feeling like a backlog. Hard trade-off: real life sometimes has more than three priorities, and a hard cap can feel restrictive; I accepted that because the restriction is precisely the therapeutic mechanism.

A morning-only ritual, not an all-day planner. Alternatives considered: a full-day or evening planning surface (rejected, it dilutes the focus on the specific friction point, the first hour). Why this won: solving one moment well beats solving the whole day poorly. Trade-off owned: users wanting an all-day system will need another tool; that is a deliberate boundary.

No streaks or guilt mechanics. Alternatives considered: a streak counter for stickiness (rejected, it punishes the exact bad mornings the user already struggles with and can drive avoidance). Why this won: momentum should come from today's wins, not yesterday's debt.

Local-only and account-free at MVP. Alternatives considered: accounts and sync from the start (rejected, friction at the wrong moment for a fast morning ritual). Why this won: open and start in seconds. Trade-off owned: no cross-device continuity yet, a clear P2.

7. UX

The interaction language is calm and minimal: a short morning screen, generous spacing, large readable type, and a satisfying check-off. The aim is for the act of planning to take under a minute and to feel like a gentle nudge into the day rather than a chore.

Core screens:

• Three big-thing fields and five small-thing fields, capped and uncluttered.
• The day's items with clear, tappable completion states and a sense of progress as wins accumulate.
• A forgiving start that accepts a single item without penalty.

8. Success metrics and validation

Leading indicators

• Morning completion of the ritual: target [X%] of days where the user sets at least one big and one small thing. Measured locally.
• Quick-win rate: target [X%] of small things checked off by midday.
• Repeat use: target [X%] of users returning the next morning.

Lagging indicators

• Felt outcome: target an upward trend in a simple "how did the day start" rating on days the ritual is used. Measured via an optional prompt.
• Retention: target [X%] of users still using the ritual at 14 days.
• Time-to-start: target a self-reported reduction in how long it takes to get going in the morning.

All actuals are bracketed; this is a self-use prototype built from a personal pain point and has not been validated more broadly.

What didn't work, and what I'd change. Three honest reflections. First, the app helps you plan the morning but does almost nothing to get you out of bed, which is the literal first obstacle the founder described; the "first move before you get up" idea is the missing piece, and I would build that pre-bed commitment as a P0 rather than a P1. Second, with local-only storage I cannot measure whether the ritual actually shortens time-to-start across days, so my core claim is currently a hypothesis; I would add privacy-respecting logging of ritual-used versus not and a one-tap morning rating to test it. Third, the three-plus-five cap is an untested intuition, not a validated number; it may be too many on a heavy day or too few on a light one, and I would experiment with a smaller default (one big, three small) to see whether an even lower bar improves the rate of actually starting.

9. Open questions and roadmap

• Is three-plus-five the right cap, or does an even smaller default get more people started? (user, data)
• What is the highest-leverage way to bridge from "I'm awake" to "I'm up," beyond planning? (design, user)
• Does a gentle reminder help or does it add pressure that backfires? (user)
• Is sync worth the friction of accounts for this kind of quick ritual? (data)

v2 scope: the pre-bed "first move" commitment, an optional why-line per priority, a gentle end-of-day glance, and instrumentation to test the core claim.

Market positioning: against full task managers and habit trackers, Morning competes on doing one thing (the first hour) and doing it with the least possible friction. Its defensibility is focus and restraint rather than feature breadth.

GTM hypothesis: the product is its own pitch ("an app for people who can't get started in the morning"), well suited to a single resonant landing page and word-of-mouth among people who recognize the exact problem.

10. What this project demonstrates

• Problem identification: starting from a real, specifically articulated user pain (the founder's own morning paralysis).
• Trade-off reasoning: capping scope to the first hour and a fixed list size, and owning what that excludes.
• Technical fluency: a deliberately minimal data model and a one-screen daily ritual, built to be fast.
• Validation discipline: naming the core claim as an untested hypothesis and what instrumentation would prove it.
• Self-critique: recognizing that the app does not yet solve the literal first obstacle (getting up) and reprioritizing accordingly.
• Communication: a tight spec that matches the product's one-minute, one-screen ambition.

Care Circle

A consent-first support app that gives people a single button to tell a chosen circle how they are doing, on their own terms.

The 30-second version. Care Circle lets a person pick a small circle of three to eight trusted people and send check-in signals at four levels, from "I'm okay" to "Not okay," with friends responding through pre-composed, low-pressure messages. The hardest design constraint is the safety architecture: the app never infers mental state, never auto-dials emergency services, and always shows crisis resources before any notification goes out. I built it solo with a strict consent-first model, wrote a non-diagnostic copy library, and specified a clinical-advisor sign-off gate. It demonstrates product judgment in a high-stakes, ethically loaded space where the right answer is often to build less.

---

Timeline: Weekend prototype, pending clinical-advisor review before any real-world use.

---

1. Problem statement

The people who love someone going through a hard time often want to help but do not know when they are needed. The person struggling frequently cannot, in the moment, compose a vulnerable "I need you" message to several people at once. The result is a gap: support exists in the network but does not reach the person, because the activation energy is too high exactly when capacity is lowest. Existing approaches fail on both ends. Generic mental-health apps lean on mood inference, behavioral surveillance, or clinical framing that many people find alienating or invasive. Group chats put the burden of explanation back on the person who is already depleted. The cost of the gap is isolation that compounds. Care Circle's hypothesis is that the missing piece is not detection or diagnosis, it is a low-effort, consent-based signal: a button.

2. Goals and non-goals

Goals

• Make it nearly effortless to tell a chosen circle how you are doing, at a chosen level of urgency (user outcome).
• Keep the person in full control of who knows and when, with no surveillance and no automated escalation to services (user outcome, trust).
• Make it easy for a friend to respond well, lowering the bar to a meaningful reply (user outcome).
• Build something a clinician would sign off on, so it can be used responsibly in a sensitive space (business and ethical outcome).

Non-goals

• Inferring mood or risk from social media or behavior. Permanently off-limits because surveillance violates the trust the product depends on.
• Auto-dialing emergency services. Out of scope because the user must retain agency; the app routes to resources, it does not act for the user.
• Group chat inside circles. Out of scope to avoid recreating the burden-of-explanation problem.
• Gamification (streaks, badges). Out of scope because pressure is the opposite of what this user needs.
• Public profiles, discovery, or friend recommendations. Out of scope; circles are private and self-chosen.

3. The product

The core mechanic is four signals plus a strict notification policy that always puts the user in control.

The "Not okay" surface is the heart of the safety design. Before any notification option appears, the screen leads with resources: text a friend now, one-tap call to "my person," a pre-filled crisis line (US 988 first, localized by country), and a two-minute "Sit with me" breathing exercise as the lowest-effort first option. Notifying the circle is a deliberate, separate action the user takes, never automatic. Friends respond through a pre-composed editable message ("Hey {name}, thinking of you. What's going on?"), and a quiet "I can't respond right now" link logs seen-but-not-responded without shame. If a "could use" or "not okay" signal goes unanswered for six hours, the app escalates a single second push to the most responsive member, never to emergency services.

4. User stories

As someone having a hard day, I want to press one button instead of writing a vulnerable message to several people, so that I can ask for support when I have the least energy to.

As that same person on a "not okay" day, I want to see calming resources before I decide whether to tell anyone, so that I am met with help, not just a broadcast.

As a member of someone's circle, I want a pre-written message I can edit, so that I can respond warmly without freezing over what to say.

As a circle member who cannot help right now, I want to mark that quietly, so that the system knows without making me feel guilty.

As a privacy-conscious user, I want a transparency page reachable from sign-up and a one-tap full data deletion, so that I trust the app with something this personal.

Edge/empty state. As someone who has signaled "not okay" and no one has responded yet, I want honest, non-alarming copy ("No one's reached out yet. {N} of your circle have seen this.") rather than silence or a panic banner.

5. Requirements

Must-have (P0)

• Phone OTP auth, display name, and photo. Given a valid phone number, when a user verifies, then an account is created.
• Circle setup by phone with consent. Given a user adds three to eight people, when each is invited, then they get an SMS to accept or decline and status is tracked.
• Four signal buttons with persisted status. Given a user taps a signal, then the correct notification policy fires (okay notifies no one; could-use notifies within 15 minutes; not-okay notifies only after explicit confirmation).
• The "Not okay" safety rail. Given a user opens the not-okay surface, then resources appear before any notify option, and "Notify my circle" is a separate deliberate tap.
• Friend response surface with a pre-composed editor and a no-shame "can't respond" link.
• Six-hour no-response escalation to the most responsive member, and never to emergency services.
• Transparency page reachable from sign-up and irreversible account and data deletion.

Nice-to-have (P1)

• Self-reflection thresholds: the user sets personal triggers (quiet days in a row, missed routine) that prompt only the user, never the circle.
• "My person" one-tap crisis call configuration.
• Circle health view (responsive vs dormant members).

Future (P2)

• Localized crisis resources beyond the US.
• Optional check-in scheduling.
• Caregiver or family-mode patterns, only with the same consent guarantees.

6. Key product decisions and trade-offs

Resources before notification on every "not okay" surface.

Alternatives considered: notify the circle immediately on "not okay" (rejected, removes the user's agency at the most vulnerable moment and risks broadcasting a crisis the user is not ready to share); auto-escalate to 988 (rejected, paternalistic and potentially harmful). Why this won: the lowest-effort, most self-directed option (breathe, then choose) respects autonomy and is what a clinician would endorse. Hard trade-off: in a genuine emergency, an extra deliberate step could delay help; I accepted that because automated escalation breaks the trust the entire product runs on, and the app is explicit that it is not an emergency service.

Never infer mental state.

Alternatives considered: lightweight passive signals (rejected); opt-in behavioral nudges (rejected). Why this won: surveillance, even well-intentioned, is incompatible with a product built on consent. The promise "We don't read your messages. We don't watch your social media. We just give you a button." is a feature and a moat.

Non-diagnostic copy, clinician-reviewed.

Alternatives considered: clinical language (depression, anxiety, crisis) for clarity (rejected, alienating and risks implying diagnosis or treatment). Why this won: plain words (okay, not okay, need someone) lower the barrier and keep the app firmly out of medical-claim territory. Every line is gated on clinical-advisor sign-off before launch.

Consent-based circles, invite-and-accept.

Alternatives considered: auto-add from contacts (rejected, no consent from the friend); open discovery (rejected, privacy and safety). Why this won: both sides opt in, which protects the friend's capacity and the user's privacy.

A single, calm escalation rather than aggressive retries.

Alternatives considered: repeated pushes until answered (rejected, alarmist); no escalation (rejected, a real "not okay" should not vanish). Why this won: one second push to the most responsive member after six hours balances reach with restraint.

7. UX

The aesthetic is quiet, warm, and deliberately un-clinical: cream background, a Cormorant serif for headlines, generous spacing, and signal colors that are calm rather than emergency-red. No alarm icons, no exclamation marks, no "Are you okay???" copy. The visual restraint is itself a safety and trust decision.

Core screens:

• A three-screen promise centered on consent and privacy ("You choose who. You choose when.").
• Add three to eight people by phone, each with pending/active/declined status.
• A warm greeting and four large, color-banded signal buttons with a recent check-ins list.
• Resources at the top, "Notify my circle" as a distinct lower action, cancel always available.
• The signal in context, a pre-composed editable reply, and a no-shame "can't respond" link.
• A plain-language page on what the app does and does not do, reachable from sign-up.

8. Success metrics and validation

Leading indicators

• Circle completion: target [X%] of new users adding at least three accepted members. Measured in-app.
• Signal usage: target [X%] of active users sending a signal in their first week. Measured via the signals table.
• Response rate: target [X%] of "could use" and "not okay" signals receiving a friend response within the hour.

Lagging indicators

• Felt-support outcome: target [X] on a single "I felt less alone" rating after a responded signal. Measured by an optional one-tap follow-up.
• Retention of healthy circles: target [X%] of circles still active at 30 days.
• Safety: zero incidents of unwanted automated escalation. Measured by design (the path does not exist).

All actuals are bracketed; this is a prototype and has not been validated, and would not be put in front of real users before clinical sign-off.

What didn't work, and what I'd change. Three honest reflections. First, the six-hour escalation window is a guess; for a true "not okay," six hours may be far too long, and I have no data on what a humane interval is, so I would test shorter windows for the highest-urgency signal and consider configurable per-circle timing. Second, the product asks friends to carry real emotional weight, and I underspecified the friend's experience of burnout or being repeatedly tapped; I would add gentle load-balancing and a way for a member to set their own capacity without abandoning the circle. Third, the entire safety posture depends on a clinical advisor who is named in the spec but not yet engaged; until that review happens, the app is a careful prototype, not a tool I would ship, and I am treating that gate as non-negotiable rather than a nice-to-have.

9. Open questions and roadmap

• What is the humane escalation interval for "not okay," and should it be configurable? (clinical, user)
• How do we protect circle members from over-reliance without shaming the person reaching out? (clinical, design)
• What jurisdictions and crisis-line localizations are required before launch in each region? (legal, clinical)
• Is phone OTP plus contacts the right trust model, or does it create friend-spam risk? (eng, user)

v2 scope: self-reflection thresholds, localized resources, and configurable escalation, all behind the same consent guarantees.

Market positioning: unlike mood-tracking or clinical apps, Care Circle makes no diagnosis and runs no surveillance; its wedge is consent and restraint. The defensibility is trust: a product people are willing to use for something this personal precisely because of what it refuses to do.

GTM hypothesis: grow through the circles themselves. Every invited member experiences the product from the friend side, which is the most credible possible introduction, and seeds the next circle.

10. What this project demonstrates

• Problem identification: locating the real gap as activation energy and consent, not detection.
• Trade-off reasoning: choosing user agency over automated "safety," and owning the genuine risk that creates.
• Ethical product judgment: a clear "what NOT to build" and a clinical sign-off gate treated as a hard requirement.
• Technical fluency: a complete data model, a precise notification policy, and an escalation rule specified end to end.
• Validation discipline: bracketed metrics, a refusal to ship before clinical review, and honest interval uncertainty.
• Communication: a spec that reads as carefully as the subject deserves, with a copy library to match.

15 Minutes to Love

A compatibility-first dating app that replaces endless swiping with one real fifteen-minute conversation.

The 30-second version. 15 Minutes to Love is a dating app built on what relationship science actually shows predicts long-term success: attachment style, shared values, communication style, and intent, not photos. Users answer ten conversational questions, see up to five deeply-vetted matches a day, and meet on a hard fifteen-minute video call. Only after both people privately say yes are phone numbers revealed. I built it solo on Lovable as a deliberately capped 100-user closed beta, designed an eight-screen flow end to end, and specified a transparent rules-based compatibility engine. It demonstrates constraint-as-strategy thinking, a defensible cold-start plan, and a product where every limitation is the feature.

---

Timeline: Weekend prototype, in closed-beta design for a 100-user cohort.

---

1. Problem statement

Dating app fatigue is structural, not personal. The dominant apps optimize for endless swiping and open-ended text threads, which produce thin signal, slow time-to-meeting, and a steady drip of matches that go nowhere. Users burn weeks texting before they learn in five minutes of conversation that there is no spark. The science points the other way: the strongest predictors of relationship longevity are attachment style, shared values, communication and conflict style, and aligned intent, not the things a photo grid surfaces. The cost of the status quo is real time and real morale, paid by people who are genuinely trying to find a partner. Existing solutions fail because their business model rewards engagement (more swipes, more sessions) rather than conversion to a real relationship.

2. Goals and non-goals

Goals

• Help a user have one real conversation with someone genuinely compatible, fast (user outcome).
• Replace text limbo and ghosting with a forced, humane resolution after every call (user outcome).
• Prove that compatibility-first matching converts to real dates on a small vetted cohort before scaling (business outcome).
• Build a defensible cold-start story: a closed, invite-only community, not "yet another dating app" (business outcome).

Non-goals

• In-app chat or messaging. Out of scope because the whole thesis is to skip text and meet on video.
• Infinite swiping or large daily decks. Out of scope because volume is the problem, not the solution.
• Monetization, premium tiers, or boosts. Out of scope for a closed MVP focused on validating the core loop.
• Scaling infrastructure (sharding, queues, horizontal scale). Out of scope because 100 users is a feature, not a limit.
• Advanced filters beyond chat-captured dealbreakers. Out of scope to keep the compatibility model the differentiator.

3. The product

The core loop is five steps, each designed to raise signal and cut wasted time.

1. Onboarding chat. An AI interviewer asks ten research-anchored questions covering intent, attachment (two signals), conflict style, top values, kids stance, love languages, pace, dealbreakers, and a one-line "what matters most." The tone is warm and conversational; the underlying capture is structured.
2. The daily five. A nightly job scores every other active user, applies hard filters, ranks the rest, and surfaces up to five new matches, each with a compatibility percentage and a one-sentence reason.
3. Mutual like. If both like, a calm celebration screen routes straight to scheduling. A cap of three outstanding mutual matches prevents the swipe-and-never-meet pattern.
4. The fifteen. A scheduled in-app video call with a visible hard countdown, a three-minute warning, an auto-end at zero, and a single optional five-minute extension if both tap for it. No recording.
5. The decision. Each person privately answers "Do you want a real date with this person?" Both yes reveals phone numbers and a first note. Either no, or a non-response inside 24 hours, ends the match permanently. No ghosting, no limbo.

The compatibility score is transparent and rules-based, not a black box. Hard filters (age, distance, intent, kids stance, dealbreakers) gate eligibility; soft scoring out of 100 weights attachment compatibility most heavily (30 points), then shared values (25), communication and conflict style (20), pace (10), love-language overlap (10), and life stage (5).

4. User stories

As a dater tired of swiping, I want to answer questions about how I actually relate, so that I am matched on fit rather than photos.

As a busy professional, I want a fixed fifteen-minute video instead of a week of texting, so that I learn fast whether there is a spark.

As someone who has been ghosted, I want a forced private decision after the call, so that I always get resolution and never sit in limbo.

As a privacy-conscious user, I want my phone number revealed only after we both commit, so that I control my exposure.

As the founder/admin, I want invite-code gating and a dashboard of users, matches, and call stats, so that I can run a controlled beta and intervene when needed.

Edge/empty state. As a brand-new user with no matches yet, I want a clear "we are finding your five" empty state rather than a blank feed, so that I trust the system is working. As a user who hits three outstanding mutual matches, I want matching to pause with an explanation, so that I act before accumulating more.

5. Requirements

Must-have (P0)

• Invite-code gating and auth. Given a valid single-use 6-character code tied to an email, when a user signs up, then they gain access; codes cannot be reused.
• AI chat onboarding capturing all ten structured dimensions. Given a user completes the chat, then a complete compatibility profile is stored.
• Compatibility engine with hard filters plus 100-point soft scoring. Given two eligible users, when matches generate, then a transparent score and a cached one-sentence reason are produced.
• Nightly daily-five generation with symmetric exposure and the three-outstanding cap.
• Match card, like/pass, and mutual-match detection.
• Scheduling against both users' availability windows with confirmation and reminders.
• Fifteen-minute video with hard timer, three-minute warning, auto-end, optional single extension, no recording.
• Post-call private decision with the both-yes reveal and the either-no permanent removal, including the 24-hour soft-no rule.
• Admin dashboard: user list, match stats, pause/remove, report routing.

Nice-to-have (P1)

• Push and SMS reminders (vs in-app only).
• AMH of dating: richer "why you matched" explanations.
• Reschedule and propose-alternative flow.

Future (P2)

• Opening beyond the 100-user cohort with pool-health safeguards.
• Localized crisis and safety resources.
• Lightweight post-date feedback to tune the algorithm.

6. Key product decisions and trade-offs

Cap the cohort at 100 users. Alternatives considered: open sign-up (rejected, recreates the thin-pool and trust problems of incumbents); waitlist with slow rollout (rejected, still optimizes for growth over learning). Why this won: a small pool lets the algorithm do real work, makes every user a case study, keeps architecture boring, and gives a clean investor narrative. The constraint is the design.

No in-app chat at all. Alternatives considered: optional pre-call messaging (rejected, reintroduces the text limbo we are trying to kill); icebreaker prompts (rejected, same drift). Why this won: forcing the conversation onto a timed video is the entire thesis. Hard trade-off: some users will want to text first and may churn at the friction. I accepted that, because softening here would dissolve the product into another swipe app.

A transparent rules-based score, not ML. Alternatives considered: embeddings or a learned model (rejected, no data at MVP, and a black box undermines trust); pure human matchmaking (rejected, not self-serve). Why this won: a documented points system is explainable to users and investors, debuggable by me, and grounded in published research (attachment weighted highest). It can be replaced with ML later once there is outcome data.

Forced post-call resolution within 24 hours. Alternatives considered: open-ended decision (rejected, recreates ghosting); mutual reveal by default (rejected, removes consent). Why this won: a private, time-boxed yes/no eliminates limbo while protecting the person who says no. Unflattering trade-off: a hard "no, and you disappear" can feel abrupt; I chose clarity over a softer but more ambiguous experience.

Hard timer with a single capped extension. Alternatives considered: no timer (rejected, defeats the fifteen-minute frame); unlimited extensions (rejected, recreates the limbo). Why this won: the timer is the product; one mutual extension acknowledges that real conversations sometimes need a beat more without letting calls sprawl.

7. UX

The visual language is warm and editorial rather than neon-app: cream paper, a Fraunces serif italic for display type, muted gold and rose accents, and calm motion. The intent is for the product to feel like a considered choice, not a slot machine.

Core screens, drawn from the eight-screen wireframe:

• Logo, a one-line pitch ("Skip the small talk. Find someone actually compatible."), and four numbered principles that set expectations up front.
• A conversational thread with a progress counter (4/10), tappable options, and warm validations.
• One photo, a compatibility badge, substance-first fields, plus "What matters to them" and "Why you're a match" callouts.
• A calm celebration with an immediate "Schedule your fifteen" CTA.
• Day picker and time slots drawn from the intersection of both users' availability.
• Live video with a live countdown pill and the three-minute wrap-up toast.
• A private yes/no with micro-copy explaining the reveal rule.
• Name, number, and a first note, with the next step explicitly moved off-app.

8. Success metrics and validation

Leading indicators

• Onboarding completion: target [X%] of invited users finishing all ten questions. Measured in-app.
• Activation: target [X%] of users reaching their first mutual match within seven days.
• Call completion: target [X%] of scheduled calls actually held. Measured against scheduled_calls.

Lagging indicators

• Conversion to a real date: target the North Star, ten or more of the 100 users landing a real date they would not otherwise have found. Measured via contact reveals plus a short follow-up.
• Decision resolution rate: target [X%] of calls resolved inside 24 hours (vs the ghosting baseline of incumbents).
• Satisfaction: target an NPS or single-question rating of [X] post-call.

All actuals are bracketed; this is a prototype in closed-beta design and no usage has been validated yet.

What didn't work, and what I'd change. Three honest tensions. First, the hard timer plus no-chat rule is high-friction by design and will likely cost me users who want to warm up by text; I would A/B a single pre-call prompt to test how much friction is too much. Second, the rules-based score is defensible but untested against outcomes; with no data, my weights are research-informed guesses, and I would instrument every match-to-date outcome from day one to learn whether attachment really should carry 30 points here. Third, the 100-user cap that makes the algorithm work also makes the daily-five fragile when the pool is small or skewed; I underspecified what happens when a user has zero eligible matches for several days, and I would design that empty state and a graceful "pool is thin this week" message before launch.

9. Open questions and roadmap

• How abrupt is too abrupt for the "no" experience? (design, user)
• What is the right pool size and gender or preference balance to keep the daily five healthy? (data)
• Do we need identity verification or video safety tooling before opening up? (legal, eng)
• What is the minimum cohort that still produces enough mutual matches to feel alive? (data, user)

v2 scope: richer match explanations, reschedule flows, push/SMS reminders, and a careful expansion path with pool-health safeguards.

Market positioning: the wedge is conversion to a real relationship, not engagement. The defensibility is a vetted closed community plus a compatibility model grounded in research, paired with a ritual (the fifteen) that incumbents cannot copy without abandoning their ad-driven engagement model.

GTM hypothesis: seed a single trusted community (for example an alumni or professional network) with invite codes, prove the ten-dates thesis, then expand community by community rather than via paid acquisition.

10. What this project demonstrates

• Problem identification: naming dating fatigue as a structural incentive problem, not a UX one, and designing against the incentive.
• Trade-off reasoning: choosing friction (no chat, hard timer, forced resolution) on purpose, and owning who it costs.
• Technical fluency: a complete data model, a transparent scoring algorithm, a nightly match job, and a real video stack specified end to end.
• Validation discipline: a falsifiable North Star (ten real dates from 100 users) and bracketed, honest placeholders instead of invented metrics.
• Roadmap sense: a clear path from a deliberately constrained MVP to a community-by-community expansion.
• Communication: a wireframe-grounded spec that scales from a 30-second skim to a full read.

Vibe Check

A dating protocol with no small talk: an AI interview writes your profile, and every match is one 15-minute video call.

The 30-second version. Dating apps reward endless messaging that rarely turns into a real meeting. Vibe Check replaces messaging with a single rule: meet on video for fifteen minutes. An AI confidant interviews each user and writes their profile, the feed only shows people vetted against them, and every match becomes a 15-minute call with a hard timer. Afterward both people privately choose Keep or Toss. Built solo on Lovable.

Live: https://vibe-check-dating-club.lovable.app

Problem

Most app matches stall in chat. Users spend weeks texting people they would have ruled out in a few minutes face to face, and writing a good profile is hard.

Who it is for

Busy daters who want to know quickly whether there is chemistry, and who are tired of small talk.

How it works

Key decisions

• One rule, no messaging. Removing chat removes the main place matches go to die.
• A hard timer. Fifteen minutes is long enough to know and short enough to say yes to.
• Private, mutual decisions. No one is left guessing, and no one sees a rejection.
• AI writes the profile. The interview lowers the effort of joining and makes profiles more honest.

Success metrics

Match to call rate, calls completed, mutual Keep rate, and share of users who book a second call within a week.

What I would do next

Calendar sync for call windows, photo upload instead of photo links, and safety features such as reporting and identity checks before launch.

Kindred Spirits

A dating app that matches people on how they actually behave, not what they claim in a bio.

The 30-second version. Kindred Spirits is a live behavior-based dating app. Instead of asking users to write a bio that flatters them, it reads compatibility from a structured deck of relationship questions, organized into eight relationship levels from strangers to family, played live, async, or solo. The build is a polished card-based experience with a saved-question favorites layer and per-user persistence on Supabase. It demonstrates PM work in taxonomy design, scoping discipline (a tightly bounded change set that protected an already strong core), and reasoning about why behavioral signal beats self-reported profiles in a crowded category.

---

Timeline: Iteration on an existing build (Closer), favorites and metadata layer shipped May 2026, live

---

1. Problem statement

Dating profiles reward people who write well, not people who would be good partners. A user spends an evening swiping on curated photos and clever bios, matches, and then discovers within ten minutes of conversation that the person on the other side is nothing like the profile suggested. The cost is compounding: wasted time, dating fatigue, and a slow erosion of trust in the entire category. The market gap is that nearly every major app optimizes the same self-reported surface (Hinge prompts, Bumble bios, Tinder photos), so they compete on presentation rather than on signal. Kindred Spirits starts from a different hypothesis: how someone answers a real relationship question, and which questions they choose to revisit, reveals more about compatibility than any bio they would write about themselves.

2. Goals and non-goals

Goals

• Surface compatibility from behavior (how people engage with relationship prompts) rather than from self-description.
• Give the deck a clear emotional arc through eight named relationship levels, so the product works for strangers and long-married couples alike.
• Support three distinct modes of play (Live, Async, Solo) so the same content serves first dates, distance relationships, and self-reflection.
• (Business) Build a defensible content and taxonomy asset that competitors cannot trivially copy, because the value is in the curation and the level structure, not the mechanic.

Non-goals

• A traditional swipe-and-match feed. Out of scope because the entire thesis is that swiping on profiles is the broken part.
• AI-generated profile summaries. Out of scope to keep the signal human and behavioral rather than synthetic.
• Group or event-based features. Out of scope to keep the first version focused on the one-to-one (and solo) relationship.
• Heavy gamification (streaks, points). Out of scope because the tone is intimacy, not engagement-farming.

3. The product

At the core is a deck of relationship questions organized into a deliberate taxonomy of eight levels. The user picks a level and a mode, then pulls cards.

Core flow: pick a level, pick a mode, pull a card, answer or discuss, optionally favorite it, move to the next card. The favorites layer turns a one-time deck into a returnable, personal artifact.

4. User stories

As a dater meeting someone new, I want to pull from the Strangers and Acquaintances levels in Live mode, so that a first date moves past small talk fast and I learn how this person actually thinks.

As one half of a long-distance couple, I want Async mode, so that we can answer the same deeper questions on our own time and stay connected without scheduling a call.

As someone reflecting on my own patterns, I want Solo mode, so that I can use the deck as a private journaling prompt rather than a social tool.

As a returning user, I want to heart questions that resonated and find them again on a Favorites page, so that the deck becomes a personal keepsake rather than a single session.

As any user (privacy edge case), I want my favorites visible only to me, so that the questions I saved (which can be intimate) are never exposed to other users. (Enforced by row-level security: auth.uid() = user_id.)

5. Requirements

Must-have (P0)

• Eight-level taxonomy with curated questions per level.
  • Given a user selects any level, when they pull a card, then a question appropriate to that level's closeness is shown.
• Three-mode selector (Live / Async / Solo).
  • Given a user opens the deck, when they choose a mode, then the experience adapts to that mode of play.
• Per-user favorites with a heart toggle and a dedicated Favorites page.
  • Given a logged-in user taps the heart on a card, when they navigate to /favorites, then that card appears; when they untap it, then it disappears from /favorites.
• Row-level security so users see only their own favorites.
  • Given two different users, when each opens /favorites, then neither sees the other's saved questions.
• Correct metadata and favicon for shareability.
  • Given the live URL is shared, when a link preview renders, then the title and description describe the deck accurately.

Nice-to-have (P1)

• Journal alongside Favorites in the footer nav (a place to keep answers, not just questions).
• Shareable card images for social.
• Light onboarding that recommends a starting level based on relationship stage.

Future (P2)

• Compatibility read-out: infer signal from which questions a pair lingers on or saves.
• Pairing mechanic so two users can share a deck session.
• A small set of premium or themed decks.

6. Key product decisions and trade-offs

Decision: Behavior and curated prompts over self-written profiles. Alternatives considered: a Hinge-style prompt-and-photo profile (rejected because it competes on the exact surface that is broken); an AI interview that writes a profile for the user (rejected as a different product, and one that adds synthetic distance between two people). Why this won: the deck makes the user's actual thinking the unit of compatibility, which is the whole differentiating bet.

Decision: Eight named relationship levels as a fixed taxonomy. Alternatives considered: a flat deck with difficulty tags; an algorithmic feed that serves the "right" next question. Why this won: named levels give the product a legible emotional arc and let it serve both a first date and a 20-year marriage with the same architecture. The build spec explicitly protected this taxonomy from change, which is itself a product signal: the levels are the moat.

Decision: Ship favorites and metadata only, touch nothing else. This is the unflattering, disciplined trade-off. The existing app was already strong. Rather than redesign, the change set was deliberately narrowed to two additions (a favorites mechanism and meta tags) with an explicit do-not-touch list covering the level names, question content, mode selector, typography, and palette. Alternatives considered: a broader refresh of the deck while "in there anyway" (rejected as gold-plating that risked regressing a working core). Why this won: respecting a strong existing product and shipping a tight, verifiable change is better PM judgment than expanding scope for its own sake.

Decision: Per-user persistence with row-level security from day one. Alternatives considered: client-side or anonymous favorites (rejected because saved questions can be intimate and must be private and durable across devices). Why this won: favorites are only valuable if they persist and stay private, so the data model and RLS policy were treated as P0, not polish.

7. UX

The visual language is intimate and editorial, not transactional: a cream and maroon palette, a wordmark with a maroon period, and a single relationship question presented as a focused card rather than a feed. The deliberate restraint (one question at a time) is the point, it slows the interaction down to the pace of a real conversation.

8. Success metrics and validation

Leading indicators

• Activation: percentage of new users who pull at least three cards in their first session. Target: [60%+]. Measured by session event counts.
• Favorites adoption: percentage of active users who save at least one question. Target: [40%+]. Measured via the favorites table.
• Mode spread: distribution of sessions across Live / Async / Solo, to confirm all three modes earn their place. Measured by mode selection events.

Lagging indicators

• Return rate: percentage of users who come back within 14 days to revisit favorites. Target: [30%+]. Measured by returning-user sessions hitting /favorites.
• Qualitative compatibility signal: self-reported "I learned something real about this person" in a post-session prompt. Target: [to be populated after validation].

What didn't work, and what I'd change. The current build proves the experience but not the matching thesis. Today the app surfaces compatibility implicitly (through which questions resonate) rather than producing an explicit compatibility read, so the headline claim ("matches on behavior") is still a design intention more than a measured outcome. If I rebuilt, I would instrument the deck to capture lightweight behavioral signal (dwell time per card, save rate by level, which questions a pair both favorite) and turn that into an actual compatibility output, which is the difference between a beautiful deck and a dating product. I would also resist the temptation to add a swipe feed even under growth pressure, because reintroducing the broken surface would dissolve the differentiation.

9. Open questions and roadmap

• How do we generate an explicit compatibility signal from deck behavior without making the experience feel surveilled? (Owner: data + design.)
• Does the eight-level taxonomy hold up across cultures, or do some levels (Engaged, Married) need localization? (Owner: user research.)
• What is the right pairing mechanic for two users to share a session safely? (Owner: design + eng.)

v2 scope: a pairing mode, a compatibility read-out, and a Journal companion to Favorites.

Market positioning:

GTM hypothesis: lead with the relationship deck as a standalone, shareable object (it is genuinely useful for existing couples and friends, not only daters), and let that organic use seed the matching product. It is defensible because the value sits in the curated content and the eight-level taxonomy, which are slow to copy well and improve with use.

10. What this project demonstrates

• Problem identification: named the real failure of dating apps (they compete on self-reported surface) and built around behavioral signal instead.
• Trade-off reasoning: deliberately narrowed scope to protect a strong existing core, and chose a fixed taxonomy over an algorithmic feed for legibility and defensibility.
• Technical fluency: per-user persistence on Supabase with row-level security, a clean change set, and correct shareability metadata.
• Validation discipline: honest that the matching thesis is not yet measured, with a concrete instrumentation plan to prove or kill it.
• Roadmap sense: a credible path from a useful deck to a differentiated matching product.
• Communication: a spec that knows what not to touch is as valuable as one that says what to build.

Green Flag (The Sit)

A private dating counsel that reads the conversation, not the person

The 30-second version. Green Flag, presented in the product as "The Sit," is a private tool that reads screenshots of a dating conversation and returns an honest "read" on emotional intelligence, intent, and safety. The user picks what the conversation is for (vetting a real partner, or exploring pleasure), and the read is tuned to that goal. Built solo as an editorial, privacy-first prototype where nothing is stored. The PM work spans a sharp problem frame (decision support at the moment of doubt), a two-mode product model, a privacy-by-design stance, and a defensible content-quality roadmap.

---

Timeline: Prototype built, in concept testing

---

1. Problem statement

People in the early stage of dating spend enormous emotional energy interpreting ambiguous messages, and they do it alone or by forwarding screenshots to friends who are biased, busy, or unqualified. The cost is real: wasted months on someone who was never building toward anything, or dismissing a good partner over a misread text. The two dominant alternatives both fail. Friends give warm but inconsistent advice colored by their own history. Generic AI chatbots give confident, sycophantic answers that flatter the user rather than tell the truth. The gap is a tool that reads a real conversation, holds a clear point of view, and stays anchored to what the user actually wants rather than what the other person needs from them.

2. Goals and non-goals

Goals

• Give the user a clear, honest read on a specific conversation in under a minute.
• Tune the read to the user's stated goal, because "is he a real contender" and "is this safe and fun" are different questions.
• Keep the user anchored to their own wants (the product's "North Star"), not the other person's.
• Earn trust through a privacy-first stance: nothing is stored.

Non-goals

• Not a matchmaking or swiping app. It does not find people; it reads conversations the user already has.
• Not a therapist or a crisis service. It is decision support, with clear handoffs when safety is at risk.
• Not a manipulation coach. It will not write lines to extract a result from someone. The product reads, it does not script.
• Not a long-term relationship tracker in v1. One conversation, one read.

3. The product

The user lands on a calm, editorial interface ("The Sit, Vol. I"). The flow is deliberately short:

The contender lens reads for emotional intelligence, intent, and whether he is actually building toward something. The pleasure lens reads for safety, agency, and whether the dynamic keeps the user in her body. Nothing is stored, and each session ends with an invitation to start a new read.

4. User stories

• As a woman vetting a new match, I want an honest read on whether he is serious so that I do not invest months in someone who is not building toward partnership.
• As someone exploring casually, I want a read focused on safety and agency so that I can enjoy chemistry without losing myself in it.
• As a privacy-conscious user, I want assurance that my screenshots are not stored so that I can share intimate conversations without risk.
• As a user in a confusing exchange, I want to add context the screenshot cannot show so that the read accounts for history.
• As a first-time user (empty state), I want the North Star framing before I upload anything so that the read is grounded in my goals from the start.

5. Requirements

Must-have (P0)

• Two explicit lenses (contender, pleasure) that visibly change the read.
  • Given a user selects "For pleasure," when the read is generated, then it foregrounds safety and agency rather than long-term partnership signals.
• Multi-image upload with on-screen privacy assurance.
  • Given a user uploads screenshots, when the session ends, then no image or text is persisted server-side.
• A read that takes a clear position rather than hedging.

Nice-to-have (P1)

• Optional free-text context field feeding the read.
• A short "what to watch for next" follow-up rather than only a verdict.

Future (P2)

• Saved, opt-in conversation history for users who want to track a single person over time.
• Pattern view across multiple reads (recurring red and green flags for this user).

6. Key product decisions and trade-offs

Decision 1: Two lenses instead of one general read

Choice: Force the user to declare intent (contender vs pleasure) before the read.

Alternatives considered: A single all-purpose read (rejected: it averages two opposite goals into mush). Inferring intent from the conversation (rejected: the same words carry different weight depending on what the user wants, and guessing wrong erodes trust).

Why this won: Intent is the single biggest input to a correct read. Making it explicit is cheap and dramatically improves relevance.

Decision 2: Privacy by design, nothing stored

Choice: No persistence in v1. Screenshots are read and discarded.

Alternatives considered: Store conversations to enable history and personalization (rejected for v1: the content is among the most sensitive a user owns, and trust is the whole product).

Why this won: For an intimate-content product, a credible "nothing is stored" promise is a feature, not a limitation. History becomes an opt-in P2, never a default.

Decision 3: Editorial, non-clinical voice

Choice: Present as a private counsel ("Yours, Juliana. Vol. I") rather than a scoring app.

Alternatives considered: A red-flag checklist or a compatibility score (rejected: reduces a human situation to a number and invites gaming).

Why this won: The tone signals discretion and judgment, which is what a user wants from counsel. It also differentiates sharply from gamified dating tools.

7. UX

The visual language is intentionally analog and quiet: paper textures, ochre and plum accents, generous whitespace. This is a deliberate counter to the bright, transactional aesthetic of dating apps. The product should feel like a letter, not a dashboard.

8. Success metrics and validation

Leading indicators

• Read completion rate (uploaded a conversation and viewed the read): target [X%].
• Lens split (share choosing pleasure vs contender): informs which read quality to invest in first.
• Repeat reads per user in first week: target [X].

Lagging indicators

• Self-reported usefulness ("did this read match what happened?") at a 2-week follow-up: target [X%].
• Word-of-mouth referrals, the natural growth channel for a discreet product.

What didn't work, and what I'd change

• A read is only as good as its judgment, and an over-confident wrong read is worse than no read. v1 needs a calibrated humility ("here is what I see, here is what I cannot see from a screenshot").
• Screenshot quality varies wildly. The prototype assumes clean uploads; a real v1 needs OCR fallback and a graceful path when images are unreadable.
• "Nothing is stored" must be provably true, not just stated. A real build needs the architecture to back the claim, or the trust collapses on first doubt.

9. Open questions and roadmap

Open questions

• Safety handoff (design, legal): when a read surfaces signs of coercion or abuse, what is the responsible response and resource handoff?
• Scope of judgment (user research): how directive should the read be? Users may want a verdict, but the product should not tell people who to date.
• Monetization (business): one-time reads, a subscription, or a freemium model?

Roadmap

• v1: ship the two-lens read with provable no-storage and a safety handoff.
• v1.5: optional context, OCR robustness, "what to watch for next."
• v2: opt-in history and a personal pattern view, the first feature that benefits from (consented) memory.

10. What this project demonstrates

• Problem identification. Found a real, underserved moment (decision support at the point of doubt) that friends and generic chatbots both serve badly.
• Trade-off reasoning. Chose explicit intent over inference, and trust over personalization, with stated rationale.
• Principled design. Treated privacy as a core product promise, not a compliance afterthought.
• Voice and positioning. Differentiated through an editorial tone in a category defined by transactional design.
• Responsible scope. Built in safety handoffs and refused the manipulation use case.

Quill (Draft Companion) - PRD

One-line summary: Paste messy notes or bullet points and get a polished follow-up or thank-you message back in one of three selectable voices, ready to send.

Problem

Writing follow-ups and thank-you notes is high-friction emotional labor. People know they should send them after interviews, meetings, intros, and gifts, but staring at a blank message and finding the right tone causes delay and avoidance. The notes either never get sent or come out stiff and generic. There is no fast tool that turns rough thoughts into a sendable, appropriately toned draft.

Target users

• Primary: Job seekers and early-career professionals who need to send interview follow-ups and networking thank-yous and want them to land well.
• Secondary: Founders, salespeople, and consultants who send frequent relationship-building follow-ups.
• Tertiary: Anyone facing a socially required note (gifts, favors, introductions) who freezes on tone.

Goals and Non-goals

Goals

• Turn rough, unstructured notes into a polished draft in under 30 seconds.
• Give users meaningful control over tone through clear voice options.
• Produce drafts that feel personal and specific, not templated.

Non-goals

• We are not building a full email client or send-and-track CRM at launch.
• We are not generating long-form documents or cold outreach sequences.
• We are not fabricating facts the user did not provide.

Key features

P0 (launch)

• Paste-in box for messy notes, bullets, or context.
• Output type selector: follow-up or thank-you.
• Three selectable voices (for example Warm, Professional, Confident) that visibly change tone.
• One-tap copy of the generated draft.
• Quick regenerate to get an alternative within the same voice.

P1 (fast follow)

• Length control (short, standard, detailed).
• Inline edit and refine with a follow-up instruction (make it warmer, shorten the opener).
• Saved context fields (name, role, occasion) to personalize output.
• Recent drafts history.

P2 (later)

• Additional output types (apology, intro request, reschedule, congratulations).
• Email and LinkedIn integrations to send or paste directly.
• Voice learning from a user's past accepted drafts.

Success metrics

North-star metric: Drafts copied or sent per weekly active user (Useful Drafts per WAU).

Supporting metrics

• Paste-to-copy conversion rate per session.
• Regenerate rate (a proxy for first-draft quality, lower is better once stable).
• Voice selection distribution and switch rate.
• Day-30 retention and repeat-use frequency.

Key risks and mitigations

• Output feels generic: drafts that read as AI-written undermine trust. Mitigate by anchoring tightly to the user's pasted specifics, surfacing voices with distinct personalities, and tuning prompts against human-rated quality.
• Tone mismatch: the wrong register can embarrass the user. Mitigate with clear voice previews, easy regeneration, and conservative defaults.
• Accuracy and fabrication: the model could invent details. Mitigate with a strict rule to only use provided facts and a visible reminder to review before sending.
• Thin value perception: users may feel they could write it themselves. Mitigate by making the speed and tone-switching delightfully fast and by nailing the highest-anxiety use case (interview follow-ups).

Phased rollout

• Phase 1 (Weeks 1 to 3): MVP: paste box, follow-up and thank-you types, three voices, copy and regenerate. Launch to a small job-seeker community and measure paste-to-copy.
• Phase 2 (Weeks 4 to 7): Refinement: add length control, inline refine, saved context, and history. Tune voice quality against user ratings.
• Phase 3 (Weeks 8 to 14): Expansion: add more output types and the first send integration, and explore a premium tier for unlimited drafts and voice learning.

Swim Body

Made-to-order swimwear that fits each body, sold through a threshold drop that only produces what people actually pre-order.

The 30-second version. Swim Body (built as "Swim Drop Collective") is a pre-order swimwear experience built solo on Lovable. It solves two problems at once: swimwear fit anxiety (the category with some of the highest return rates in apparel) and inventory risk. Three styles with bounded customization and a size flow that includes custom measurements replace guesswork with fit; a 100-order threshold with Stripe authorization (not capture) means a drop only goes into production if demand is real, and cards are never charged otherwise. The PM work on display is tiered-pricing and threshold logic, a measurement-driven fit flow designed to cut returns, and disciplined drop-based scope (no always-on inventory).

---

Timeline: Weekend prototype, in testing.

---

1. Problem statement

Swimwear is one of the hardest apparel categories to buy online. Fit is intimate and unforgiving, bodies vary far more than standard sizing admits, and the result is some of the highest return rates in fashion plus the waste of producing inventory that comes back. Buyers face guesswork; brands face returns and dead stock. Swim Body's hypothesis is that pairing made-to-measure fit (custom measurements, not just S to XXL) with a threshold pre-order model attacks both failures at once: better fit lowers returns, and producing only against confirmed demand eliminates speculative inventory. The cost of not solving this is the category status quo, returns priced into every sale and landfill swimwear.

2. Goals and non-goals

Goals

• Reduce fit-driven returns by fitting suits to each body, including custom measurements (user and business outcome).
• Produce only what is genuinely wanted via a 100-order threshold (business outcome).
• Make pre-ordering feel safe by authorizing, never capturing, until the drop succeeds (trust outcome).
• Let a buyer customize and pre-order in under 4 minutes (user outcome).
• Create urgency and fairness with transparent tiered pricing and a live progress bar (business outcome).

Non-goals

• No always-on shop or inventory. Drops only; standing inventory reintroduces the waste we are avoiding.
• No wishlist or favoriting. It adds surface without moving the pre-order decision.
• No user accounts at MVP (guest checkout). A drop is a single decision, not a logged-in relationship yet.
• No reviews on pre-order items. There is nothing to review until delivery.
• No influencer or affiliate program. Paid amplification would distort the demand read.

3. The product

A single editorial landing page with a live progress bar, feeding a six-step customization flow that ends in an authorized pre-order.

Tiered pricing rewards early commitment: early supporters ($95, 30 slots), standard ($115, 50 slots), final ($135, 20 slots), up to the threshold of 100. A live progress bar ("63 / 100 orders. Production starts at 100.") makes the collective mechanic visible. Stripe authorizes at order time. When the 100th order lands, a cron captures all pending authorizations and emails everyone "we made it." If the drop misses by Day 30, all authorizations void within 24 hours and a "your card was never charged" email fires. Estimated shipping is 5 to 8 weeks from threshold.

4. User stories

The fit-anxious buyer

• As someone who dreads swimwear sizing, I want to enter custom measurements so that the suit is made to my body, not a generic size.
• As someone unsure of my size, I want a 30-second fit quiz so that I get a recommendation without measuring.

The values-driven buyer

• As someone who hates fashion waste, I want to know the suit is only produced if enough people order so that I am not contributing to dead stock.
• As an early buyer, I want a better price for committing first so that being decisive is rewarded.

The cautious buyer

• As a pre-order buyer, I want my card authorized but not charged until the drop succeeds so that I take no risk on a product that may not be made.

Edge and error states

• As a buyer when a drop fills to 100, I want to be told production is locked (or offered a waiting list) so that I am not left in limbo.
• As a buyer in a drop that misses, I want an automatic void and a clear email so that I never have to chase a refund.

5. Requirements

Must-have (P0)

• Six-step customization flow completable quickly.
  • Given a buyer starts from a style, when they complete all steps, then they reach confirm in under 4 minutes.
• Size step with standard, custom-measurement, and fit-quiz tabs.
  • Given a buyer chooses custom, when they enter chest, waist, and hips, then measurements are stored with size_type = custom.
• Stripe authorization at order, not capture.
  • Given a buyer confirms a pre-order, when payment succeeds, then the order is authorized (not captured) with status "authorized."
• Live progress bar toward 100.
  • Given a new order is placed, when it commits, then the progress bar updates in real time.
• Threshold capture and miss-void automation.
  • Given order count reaches 100, when the cron runs, then all authorizations capture within 10 minutes; given a miss by Day 30, then all authorizations void within 24 hours, each with the matching email.

Nice-to-have (P1)

• Tier and capacity tracking with remaining-slot counts per tier.
• Coverage and fit visual diffs.
• Waiting list when a drop fills at the final tier.

Future (P2)

• User accounts and order history.
• Post-delivery reviews.
• Repeat-drop cadence and notify-me for future drops.

6. Key product decisions and trade-offs

Decision 1: Made-to-order fit, not just standard sizes.

• Choice: Offer standard sizes, custom measurements, and a fit quiz in one step.
• Alternatives: Standard sizes only (rejected, leaves the core return driver unsolved); custom-only (rejected, too much friction for buyers who already know their size).
• Why this won: Three paths meet buyers where they are while making the made-to-measure promise real, which is the whole pitch against returns.

Decision 2: Drops with a threshold, not always-on inventory.

• Choice: Produce only when a drop hits 100 orders.
• Alternatives: Always-on shop (rejected, reintroduces speculative inventory and waste); unlimited pre-order with no threshold (rejected, no production-viability gate).
• Why this won: A threshold turns demand validation into the production trigger, so the brand never makes something nobody bought. The trade-off is real: a drop that stalls at 90 produces nothing, and good early buyers go home empty-handed. That is the unflattering cost of the model.

Decision 3: Tiered pricing tied to commitment order.

• Choice: Early ($95), standard ($115), final ($135) tiers up to 100.
• Alternatives: Flat pricing (rejected, no reward for early commitment, slower momentum); a deep early discount only (rejected, leaves margin on the table once momentum builds).
• Why this won: Tiers create honest urgency, reward the buyers who take the most risk by going first, and improve margin as confidence builds.

Decision 4: Guest checkout, no accounts at MVP.

• Choice: Order by email, no login.
• Alternatives: Require accounts (rejected, friction on a single-decision flow); full account system (rejected, premature before the model is proven).
• Why this won: A pre-order is one decision. Accounts are a v2 concern that only matters once drops repeat.

7. UX

Quiet-luxury swim direction, Skims meets Jacquemus: warm sand background (#F5EFE7), terracotta accent (#BF7E68), serif display, Inter for UI, editorial photography across three model body types in natural light, explicitly no white-background catalog shots. The hero leads with "Three swim styles. Made only if we bring them to life together." and a live progress bar . Each style scrolls into its own editorial section with a pre-order CTA that opens the flow pre-selected . The size step presents three clearly separated tabs with a size guide and measurement diagrams . The confirm step shows a visual summary, the current tier price, and remaining slots .

8. Success metrics and validation

Leading indicators

• Customization completion rate (target: [X%] of flow starts reach confirm), via per-step funnel events.
• Custom-measurement adoption rate (target: [X%] of orders use custom sizing), the lever expected to cut returns.
• Time to confirm (target: under 4 minutes), measured from flow start to confirm.

Lagging indicators

• Whether each drop reaches 100 (the binary production trigger).
• Return rate, segmented by size_type (hypothesis: custom-measurement orders return less). Target return rate below [X%].
• Repeat pre-order rate across drops (target: [X%]).

All actuals are bracketed placeholders. No order counts, return rates, or revenue have been validated.

What didn't work, and what I'd change. The model's weakness is the stalled drop: a drop that ends at 90 produces nothing and disappoints exactly the early, values-aligned buyers it most wants to keep. I would design a fallback for near-miss drops (extend the window, open the threshold slightly, or roll commitments into the next drop) rather than a hard void at Day 30. I would also pressure-test whether custom measurements actually reduce returns or just shift the error from sizing to mis-measurement; if buyers measure themselves wrong, returns do not drop. A measurement-confidence check and a fit-guarantee policy would need validation before I leaned on "fewer returns" as the core claim.

9. Open questions and roadmap

Open questions

• Is 100 the right threshold for production economics across styles? (finance)
• Do custom measurements actually lower returns, or does mis-measurement cancel the gain? (data, user)
• What is the right treatment for a near-miss drop (hard void vs rollover)? (design, finance)
• How are the three tiers and capacities tuned for momentum without leaving margin behind? (data)

Roadmap (v2)

• Near-miss rollover mechanic and notify-me for future drops.
• Accounts, order history, and post-delivery reviews.
• Repeat-drop cadence to build a returning audience.

Positioning

GTM hypothesis: launch drops to a values-aligned, fit-frustrated audience where "only made if we hit 100" is a feature, not a caveat. Defensible because the combination of made-to-measure fit and threshold production is operationally hard and on-brand in a way always-on competitors cannot easily copy.

10. What this project demonstrates

• Problem identification: targeted the two linked failures of online swimwear, fit returns and inventory waste, with one model.
• Trade-off reasoning: embraced threshold production and named its real cost (the stalled drop) rather than hiding it.
• Technical fluency: scoped tiered-pricing and capacity logic plus Stripe authorize-at-order, capture-at-threshold automation.
• Validation discipline: defined a binary production trigger and flagged the unproven returns claim as a risk to test.
• Roadmap sense: identified the near-miss experience as the first thing v2 must fix.
• Communication: transparent tier and refund copy and a clear "what NOT to build" boundary.

Atelier

Made-to-measure suiting with a color harmony assistant, so anyone can order a flattering custom suit without a tailor visit.

The 30-second version. Atelier is a custom suiting commerce experience built solo on Lovable. It pairs bounded customization (three signature designs, not infinite options) with two features most made-to-measure brands skip: a guided measurement flow that estimates fit without a tailor, and a Color Harmony Assistant that recommends flattering fabrics from undertone and contrast (computed client-side, never uploading a selfie). The PM work on display is scope discipline (three designs, not a configurator), an ethically careful recommendation system (undertone and contrast, explicitly not skin tone), and a privacy-by-design decision to keep image analysis on the device.

---

Timeline: Weekend prototype, in testing.

---

1. Problem statement

Buying a custom suit online forces a bad trade. Made-to-measure brands either overwhelm the buyer with endless configuration and measurement anxiety, or they flatten everything into generic sizes that defeat the point. Two questions stop most purchases cold: "Will it fit me without a tailor?" and "Will this fabric actually look good on me?" Existing players (Indochino and similar) answer the first with intimidating measurement forms and the second not at all, leaving fabric choice to guesswork that drives returns and regret. Atelier's hypothesis is that bounded choice plus two reassurance tools (fit estimation and color guidance) converts the hesitant first-time custom buyer.

2. Goals and non-goals

Goals

• Let a first-time buyer customize and order a suit in under 8 minutes without a tailor visit (user outcome).
• Remove fabric-choice anxiety with a recommendation that feels personal but never judgmental (user outcome).
• Earn measurement trust by being honest about fit confidence rather than promising perfection (trust outcome).
• Validate that bounded customization (3 designs) converts better than open configuration (business outcome).
• Keep image analysis private enough that privacy is a selling point, not a liability (trust and business outcome).

Non-goals

• No generic AI stylist chat. It invites scope creep and undercuts the curated, quiet brand voice.
• No skin-tone classification UI. Ethically fraught and not what drives fit; we analyze undertone and contrast only.
• No endless catalog (no shirts, coats, or accessories in v1). Three designs keeps production and decision load tight.
• No international shipping beyond US and Canada at v1. Production and returns logistics are not solved yet.
• No subscription or membership. This is a considered purchase, not a recurring one.

3. The product

A mobile-first commerce flow from editorial home to tracked order. The core mechanic is a six-step customization wizard with two optional confidence tools.

The measurement step offers three tabs with stated confidence: a visual quiz (around 85% fit success), manual entry with how-to guides (around 95%), and a size-up or size-down safe fallback. The Color Harmony Assistant maps undertone (warm, cool, neutral), contrast (low, medium, high), and depth (light, medium, deep) to a hand-authored 27-cell recommendation table, returning three fabrics shown on the design silhouette. After checkout, the account view tracks an order through Ordered, In production, QC in NYC, Shipped, Delivered, with photos from the QC stage.

4. User stories

The hesitant first-time custom buyer

• As someone who has never bought a custom suit, I want to customize and order in under 8 minutes so that the process feels approachable, not intimidating.
• As a buyer unsure about fit, I want an honest confidence estimate for my measurements so that I can decide whether to trust the quiz or measure manually.
• As a buyer unsure what looks good on me, I want fabric recommendations based on my coloring so that I stop second-guessing and commit.

The privacy-conscious buyer

• As someone wary of uploading my face, I want the color analysis to run on my device and never upload my selfie so that I can use it without giving up a photo.
• As a buyer who would rather not share an image at all, I want a guided question path that reaches the same recommendation so that the selfie is optional.

Edge and error states

• As a buyer who cannot measure accurately, I want a safe size-up or size-down fallback so that I am never blocked from ordering.
• As a buyer who dislikes the recommended fabric, I want a "Show me other options" action so that the assistant advises rather than dictates.

5. Requirements

Must-have (P0)

• Six-step customization wizard with progress bar and a visual review before add-to-bag.
  • Given a buyer starts on Design A, when they complete all steps, then they can add to bag in under 8 minutes with a correct price breakdown.
• Three-tab measurement step with a visible confidence indicator.
  • Given a buyer completes the quiz, when measurements compute, then a confidence score is shown and stored with source = quiz.
• Color Harmony guided fallback returning three fabrics.
  • Given a buyer answers the 5 guided questions, when they submit, then three recommended fabrics render on the silhouette in under 5 seconds.
• Stripe Checkout with order status initialized to "Ordered."
  • Given a buyer completes checkout, when payment succeeds, then an order is created with status "Ordered" and appears in the account.
• Order tracking timeline in the account view.
  • Given an order exists, when the buyer opens order detail, then the current stage is highlighted on the Ordered to Delivered timeline.

Nice-to-have (P1)

• On-device selfie path for Color Harmony (client-side analysis, no upload, verifiable in the network tab).
• QC-stage photos surfaced in order detail.
• "Request alteration" CTA when an order is marked delivered.

Future (P2)

• Internal ops tool for the Vietnam production partner.
• User reviews on product pages.
• Expanded catalog and international shipping.

6. Key product decisions and trade-offs

Decision 1: Three designs, not a configurator.

• Choice: Ship exactly three signature designs with bounded options per step.
• Alternatives: A full configurator (rejected, decision paralysis and production complexity); a single hero product (rejected, too little choice to feel "custom").
• Why this won: Three is enough to feel personal and few enough to keep production, photography, and the buyer's working memory manageable.

Decision 2: Honest fit confidence over a promise of perfection.

• Choice: Show explicit confidence (quiz around 85%, manual around 95%) and offer a safe fallback.
• Alternatives: Claim guaranteed fit (rejected, sets up returns and broken trust); hide the uncertainty (rejected, dishonest and worse for the buyer).
• Why this won: Naming the uncertainty builds trust and nudges high-stakes buyers toward manual measurement, which lowers return risk. This is the unflattering trade-off: it likely depresses top-of-funnel conversion slightly in exchange for fewer bad fits.

Decision 3: Undertone and contrast, never skin tone.

• Choice: A heuristic that classifies undertone, contrast, and depth, with copy that always says "tends to complement," never "you should never wear."
• Alternatives: ML skin-tone categorization (rejected, ethically fraught and brittle); no color guidance (rejected, leaves the biggest anxiety unaddressed).
• Why this won: It solves the real anxiety (what flatters me) without classifying people, and the advisory tone keeps the buyer in control.

Decision 4: On-device image analysis, no upload.

• Choice: Sample face-region pixels client-side, convert to LAB, compute undertone and contrast locally, never transmit the image.
• Alternatives: Server-side analysis (rejected, creates a sensitive-image liability and a privacy objection); no selfie path (rejected, the guided fallback alone is less magical).
• Why this won: Privacy becomes a feature. The guided path is the safe default; the selfie path is the delight, and it costs the brand nothing in stored personal data.

7. UX

Quiet-luxury direction: warm bone background (#F4F2EE), serif headlines (Italiana or Cormorant), Inter for UI, editorial imagery of models in environments rather than on white, motion limited to 200ms cross-fades. The home page leads with "Three designs. Made for you." and three product cards. The customization wizard is a single-column, progress-barred flow . The measurement step uses three tabs with a persistent confidence indicator . The Color Harmony Assistant opens with the disclaimer "We analyze undertone and contrast, not skin tone" and renders three fabrics on the silhouette . The account order detail shows a vertical production timeline with QC photos .

8. Success metrics and validation

Leading indicators

• Customization completion rate (target: [X%] of starts reach add-to-bag), measured by funnel events per wizard step.
• Color Harmony usage rate among buyers (target: [X%] opt in), and split of guided vs selfie path.
• Median time to add-to-bag (target: under 8 minutes), measured from wizard start to add-to-bag event.

Lagging indicators

• Order conversion rate from product page (target: [X%]).
• Return or alteration request rate, segmented by measurement source (hypothesis: manual measurers return less). Target: alteration request rate below [X%].
• Net repeat or referral rate (target: [X%]).

All actuals above are bracketed placeholders. No sales, conversion, or fit-success figures have been validated; the 85% and 95% confidence figures are design targets in the spec, not measured outcomes.

What didn't work, and what I'd change. The hardest open risk is that the heuristic color logic is hand-authored across 27 cells and unvalidated against real outcomes; if recommendations feel off, the assistant erodes trust instead of building it. I would A/B test recommendation acceptance ("Use this fabric" vs "Show me other options") before promoting the assistant in the funnel. I would also instrument the measurement tabs to see whether the honesty about confidence actually steers buyers to manual entry or just adds friction. If it adds friction without lowering returns, the confidence framing needs to be softer and later in the flow.

9. Open questions and roadmap

Open questions

• Does honest fit confidence reduce returns enough to justify any conversion drag? (data, user)
• Is the 27-cell color table accurate enough to recommend, or does it need a feedback loop? (data, design)
• What is the real first-alteration cost in NYC, and does the "first alteration on us, up to $80" guarantee hold margin? (legal, finance)
• Does the selfie path's privacy story actually lift opt-in, or do buyers prefer the guided path regardless? (user)

Roadmap (v2)

• Production ops tool and QC photo automation.
• Recommendation feedback loop to tune the color table from acceptance data.
• Reviews and an expanded but still bounded catalog.

Positioning

GTM hypothesis: reach style-conscious first-time custom buyers who have been scared off by configurators, leading with the color assistant as the differentiated hook. Defensible because the curation, the ethically careful recommendation system, and the privacy-by-design analysis are hard to copy without the same restraint.

10. What this project demonstrates

• Problem identification: named the two purchase-blocking anxieties (fit and fabric) and built directly against them.
• Trade-off reasoning: chose honesty about fit confidence over a conversion-friendly false promise, and accepted the downside.
• Technical fluency: scoped client-side LAB color analysis and a hand-authored recommendation table, with a verifiable no-upload privacy claim.
• Ethical product judgment: undertone and contrast, never skin-tone classification, with advisory (never prescriptive) copy.
• Validation discipline: separated design targets from measured outcomes and flagged the unvalidated recommendation logic as the top risk.
• Communication: a bounded scope, an explicit "what NOT to build" list, and clear acceptance criteria.

Folio

A leather carry brand validated the honest way: a refundable deposit that only charges if enough people actually want the bag.

The 30-second version. Folio (built as "Carryall") is a single-product validation landing page for a leather laptop messenger-backpack hybrid, built solo on Lovable. It does one thing well: it separates curiosity from commitment by offering two CTAs, a low-friction waitlist and a real $25 refundable deposit that authorizes a card without capturing it. Production only tools up at 150 reservations; if the threshold misses, every authorization voids automatically and no one is charged. The PM work on display is demand validation discipline (deposits over vanity signups), Stripe manual-capture authorization logic with auto-expiry handling, and ruthless single-product scope.

---

Timeline: Weekend prototype, in testing.

---

1. Problem statement

Most product launches validate demand with the weakest possible signal: an email signup. People will join a waitlist for almost anything, which tells a founder nothing about willingness to pay and leads to over-producing inventory nobody buys. For a single high-cost leather good, guessing wrong means tooling a production run against demand that does not exist. Folio's hypothesis is that a small, refundable, real-money commitment ($25 authorized, not captured) is a far truer demand signal than a free signup, and that buyers will give it precisely because the refund promise is unconditional. The cost of not solving this is the classic hardware-and-goods failure: a warehouse of unsold bags.

2. Goals and non-goals

Goals

• Measure genuine willingness to pay before committing a dollar to production (business outcome).
• Make committing feel safe enough that real-money validation does not kill conversion (user outcome).
• Reach a clear go or no-go threshold (150 reservations) with an automatic, trustworthy outcome either way (business and trust outcome).
• Let a curious visitor express interest in under 15 seconds and a serious one reserve in under 90 seconds (user outcome).

Non-goals

• No multi-SKU shop. One product keeps the validation signal clean and the build small.
• No color or size variants at MVP. Variants dilute the demand signal and multiply production complexity.
• No accounts or login. The flow is a single decision, not a relationship yet.
• No influencer or affiliate program. Paid amplification would contaminate the organic demand read.
• No international shipping at MVP. US-only keeps fulfillment assumptions honest.

3. The product

A single anchored landing page where the product photography carries most of the persuasion, ending in one of two commitment flows.

Two conversion flows:

1. Waitlist: email-only modal, one field, instant confirmation. Low friction, weak signal.
2. Deposit: name, email, shipping zip, then Stripe Checkout that authorizes $25 with capture_method = manual. Confirmation makes the mechanic explicit: "Your card is authorized. We capture nothing until production starts."

The threshold logic runs the validation. A cron job reauthorizes pending payment intents before their 7-day expiry so authorizations stay live until the campaign resolves. On hitting 150, all authorizations capture and a "we made it" email fires. On a miss at the deadline, all authorizations void within 24 hours and a "your card was never charged" email fires.

4. User stories

The curious visitor

• As someone mildly interested, I want to join a waitlist in seconds without commitment so that I can stay informed without deciding.

The serious buyer

• As someone who genuinely wants this bag, I want to reserve it with a small refundable deposit so that I help make it real and lock founder pricing ($299 vs $399 retail).
• As a deposit-payer, I want it made unmistakably clear that my card is only authorized, not charged, so that I commit without fear.

The cautious buyer

• As someone burned by crowdfunding before, I want an automatic, no-questions refund if the project does not hit its threshold so that I trust the founder's promise.

Edge and error states

• As a reserver whose authorization is about to expire mid-campaign, I want it silently re-authorized so that my reservation does not lapse before the go or no-go decision.
• As any visitor, I want the live supporter count to be real (shown only after the first 10 deposits) so that the social proof is honest, not fabricated.

5. Requirements

Must-have (P0)

• Single landing page, all sections, fast on mobile.
  • Given a mobile visitor, when the page loads, then it renders in under 2 seconds.
• Email-only waitlist writing to Supabase.
  • Given a visitor, when they submit the waitlist form, then it completes in under 15 seconds and shows confirmation.
• Deposit flow via Stripe manual_capture.
  • Given a buyer, when they complete the deposit, then $25 is authorized (not captured) in under 90 seconds and a reservation row is created with status "authorized."
• Threshold capture automation.
  • Given reservation count reaches 150, when the cron runs, then all pending authorizations capture within 10 minutes and the "we made it" email sends.
• Threshold-miss void automation.
  • Given count is below 150 at campaign end, when the cron runs, then all authorizations void within 24 hours and the refund email sends.

Nice-to-have (P1)

• Live reservation counter on the hero updating in real time.
• Authorization auto-reauthorize cron to extend past the 7-day expiry.
• All three lifecycle emails (confirmation, threshold-hit, threshold-miss).

Future (P2)

• Color or size variants once a single SKU validates.
• Accounts and reorder.
• International shipping.

6. Key product decisions and trade-offs

Decision 1: A refundable deposit, not just a waitlist.

• Choice: Offer both, but treat the $25 authorization as the real validation metric.
• Alternatives: Waitlist only (rejected, measures curiosity not willingness to pay); a full pre-purchase (rejected, too much friction before the product exists).
• Why this won: An authorized card is the cleanest demand signal short of a sale, and pairing it with a free waitlist captures both intent tiers without forcing everyone to commit.

Decision 2: Authorize, never capture, until the threshold.

• Choice: Use Stripe manual_capture so cards are only charged if production actually proceeds.
• Alternatives: Capture upfront and refund on failure (rejected, refunds are slower, feel worse, and create chargeback and trust risk); collect nothing (rejected, no real signal).
• Why this won: The buyer takes zero financial risk, which makes the refund promise credible and lifts deposit conversion. The cost is engineering complexity: authorizations expire in 7 days and must be re-authorized on a cron until the campaign resolves. This is the unflattering trade-off, real operational fragility in exchange for an honest, low-risk commitment.

Decision 3: One product, no variants.

• Choice: Validate exactly one bag with no color or size pickers.
• Alternatives: Launch a small range (rejected, splits demand across SKUs and muddies the read); offer variants (rejected, multiplies production complexity before demand is proven).
• Why this won: A single SKU gives one clean number to decide on. Variants are a v2 problem that only matters if the core demand exists.

Decision 4: Honest social proof, gated.

• Choice: Show the supporter count only after the first 10 real deposits.
• Alternatives: Fake or seed the count (rejected, dishonest and a trust risk if discovered); always show it (rejected, "1 supporter" is worse than no number).
• Why this won: Social proof that only appears once it is real protects credibility, which is the whole foundation of a deposit-based campaign.

7. UX

Quiet leather-goods direction closer to Cuyana than Bellroy: warm cream background (#F5F0E8), leather-brown accent (#6B4E2E), serif headline, Inter for UI, editorial on-body photography in both carry modes. The image carries roughly 80% of the conversion, so the hero is photography-first with two clearly ranked CTAs . The deposit modal foregrounds the authorize-not-capture promise in plain language . The plan section lays out the 150-threshold and the automatic refund as a numbered sequence so the go or no-go logic is unambiguous .

8. Success metrics and validation

Leading indicators

• Deposit conversion rate among visitors (target: [X%]), the headline validation number.
• Ratio of deposits to waitlist signups (hypothesis: a healthy ratio signals real willingness to pay), target ratio [X:Y].
• Time to reserve (target: under 90 seconds), measured from deposit-modal open to authorization success.

Lagging indicators

• Whether the campaign hits 150 reservations by the deadline (the binary go or no-go).
• Deposit-to-capture retention (target: under [X%] void requests before the threshold), measuring how many reservers stay committed.
• Post-capture fulfillment satisfaction (target: [X%]).

All actuals are bracketed placeholders. No reservation counts, conversion rates, or revenue have been validated.

What didn't work, and what I'd change. The authorization-expiry cron is the riskiest part of the build: if a re-authorization silently fails, a committed reserver drops out of the count through no fault of their own, which corrupts the exact metric the project exists to measure. I would add expiry-monitoring with alerting and a buyer-facing "we re-confirmed your reservation" email before shipping this for real. I would also question whether 150 is the right threshold; it was set in the spec without unit-economics backing, and the go or no-go decision is only as good as that number. Before launch I would back the threshold into the actual production minimum and margin.

9. Open questions and roadmap

Open questions

• Is 150 the true break-even production minimum, or a placeholder? (finance)
• What deposit-to-waitlist ratio counts as "validated enough" to tool production? (data)
• How do we handle re-authorization failures without losing committed reservers? (eng)
• Does the refund promise create any chargeback or regulatory exposure? (legal)

Roadmap (v2)

• Variants and a small range once one SKU validates.
• Reservation accounts and reorder.
• Repeat-drop mechanics if the model works.

Positioning

GTM hypothesis: launch to a warm audience (founder network, niche carry communities) where the founder story lands, and let the refund promise do the de-risking. Defensible because the honest-validation mechanic and the on-brand experience are hard to replicate on a generic crowdfunding platform.

10. What this project demonstrates

• Problem identification: recognized that waitlists measure curiosity, not willingness to pay, and designed for the latter.
• Trade-off reasoning: chose authorize-not-capture and accepted real operational fragility for a low-risk, honest commitment.
• Technical fluency: scoped Stripe manual_capture with authorization auto-expiry handling on a cron, the genuinely hard part.
• Validation discipline: defined a binary go or no-go threshold and separated it from unvalidated placeholders.
• Scope sense: a strict single-product, no-variant MVP with an explicit "what NOT to build" list.
• Communication: plain-language commitment copy that makes the financial mechanic impossible to misread.

In use: I built Splitcheck for my own dinners and trips, and members of the Columbia Business School community now use it to settle shared bills.

Splitcheck - PRD

One-line summary: Split bills fairly among friends with itemized assignment and smart fairness logic, then hand off to a payment app so everyone settles up cleanly.

Problem

Splitting a shared bill is socially awkward and error-prone. The person who paid is left chasing friends, "just split it evenly" feels unfair when people ordered very differently, and the mental math plus the payment requests create friction at exactly the moment everyone wants to relax. Existing tools are either clunky ledgers or even-split calculators that ignore who actually ordered what.

Target users

• Primary: Friend groups in their 20s and 30s who dine out, travel, and share expenses and want fairness without confrontation.
• Secondary: Roommates splitting recurring shared costs.
• Tertiary: The "designated organizer" in any group who always ends up fronting and reconciling the bill.

Goals and Non-goals

Goals

• Make fair, itemized splitting fast enough to do at the table.
• Remove the awkwardness of asking friends for money.
• Get every participant to settle up with minimal follow-up.

Non-goals

• We are not building our own payment rails or holding funds at launch.
• We are not a long-term group accounting or budgeting ledger.
• We are not handling currency conversion or international tax in v1.

Key features

P0 (launch)

• Create a split, add participants, and enter the bill total with tax and tip.
• Itemized splitting: assign line items to specific people, including shared items split among a subset.
• Fairness logic that proportionally allocates tax and tip based on each person's subtotal.
• Per-person owed amount summary with a clear breakdown.
• Payment handoff: deep-link each person's amount into Venmo, Cash App, or similar with a prefilled request.

P1 (fast follow)

• Receipt photo scan to auto-populate line items.
• Saved friends and groups for repeat splits.
• Settlement tracking (who has paid, gentle nudges to those who have not).
• Even-split and percentage-split modes for simple cases.

P2 (later)

• Recurring shared expenses for roommates.
• Group balance netting across multiple outings.
• In-app settle-up via an integrated payment partner.

Success metrics

North-star metric: Bills fully settled per active user per month (a split where every participant has paid).

Supporting metrics

• Split creation to settlement conversion rate.
• Median time from bill entry to first payment handoff.
• Participants per split who actually pay through the handoff.
• Repeat-organizer retention (Day-30 and Day-90).

Key risks and mitigations

• Payment friction: handoff to external apps can drop people. Mitigate with prefilled deep links, clear copy, and settlement nudges; later add native settle-up.
• Itemization effort: manual entry is tedious. Mitigate with receipt scanning and saved groups to cut repeat input.
• Trust and accuracy: a wrong split breaks trust instantly. Mitigate with a transparent, auditable breakdown every participant can see and verify.
• Cold-start network effects: value rises when friends use it. Mitigate by making the payer-side experience valuable even when others are not users, since participants just receive a request link.

Phased rollout

• Phase 1 (Weeks 1 to 5): MVP: manual itemized splitting, fairness logic for tax and tip, per-person summary, and payment deep-link handoff. Launch to friend-group beta testers.
• Phase 2 (Weeks 6 to 10): Reduce friction: add receipt scanning, saved friends and groups, and settlement tracking with nudges.
• Phase 3 (Weeks 11 to 18): Stickiness and depth: add recurring expenses, cross-outing balance netting, and an integrated settle-up partner, optimizing toward fully settled bills.

Deal Scout - PRD

One-line summary: A $9 per month membership that surfaces last-minute and standby flight deals on popular short-haul routes (NYC to Miami style), turning empty seats into member-only savings.

Problem

Airlines fly with empty seats and release discounted last-minute and standby inventory, but that inventory is scattered, time-sensitive, and hard for travelers to catch. Flexible travelers who could grab a cheap NYC-to-Miami flight this weekend have no single place that watches for these deals and alerts them in time. The deals expire in hours, and casual fare trackers are tuned for advance planning, not the last-minute window.

Target users

• Primary: Flexible urban travelers 22 to 45 on high-frequency leisure corridors (for example NYC, Miami, LA) who can move on short notice.
• Secondary: Remote workers and digital nomads who travel opportunistically.
• Tertiary: Budget-conscious frequent visitors (visiting family, second-home trips) on a fixed route pair.

Goals and Non-goals

Goals

• Reliably surface genuinely good last-minute and standby deals on supported routes.
• Alert members fast enough to act before inventory disappears.
• Make the $9 per month subscription pay for itself within a member's first deal.

Non-goals

• We are not a full OTA or booking engine at launch; we surface and hand off.
• We are not covering every global route initially; we focus on a few dense corridors.
• We are not guaranteeing seats on standby; we surface opportunities, not promises.

Key features

P0 (launch)

• Route subscription: members pick home corridors (origin and destination pairs).
• Deal feed of current last-minute and standby fares with price, departure window, and time remaining.
• Real-time push and email alerts when a qualifying deal appears on a watched route.
• Deal detail with a clear booking handoff to the airline or partner.
• $9 per month membership with simple subscribe and cancel.

P1 (fast follow)

• Price thresholds and flexibility filters (max price, acceptable departure windows, weekend only).
• Deal quality score versus typical fares on that route.
• Saved trips and one-tap re-alert for a specific date range.
• Member savings dashboard (total saved versus subscription cost).

P2 (later)

• Additional corridors and expansion to medium-haul routes.
• In-app or assisted booking to reduce handoff drop-off.
• Group or annual plans and referral incentives.

Success metrics

North-star metric: Net member months retained (active paying members times months retained), reflecting that members keep paying because deals deliver value.

Supporting metrics

• Trial-to-paid conversion and monthly churn.
• Alert-to-click and click-to-booking-handoff rates.
• Average member savings versus the $9 fee (value ratio).
• Deals surfaced per active route per week (supply health).

Key risks and mitigations

• Deal supply variability: thin inventory weeks erode value. Mitigate by concentrating on dense corridors with frequent releases and by setting expectations on cadence.
• Standby unpredictability: standby seats may not clear. Mitigate with clear labeling, confidence indicators, and emphasis on confirmed last-minute fares.
• Churn after a slow month: members cancel without a recent win. Mitigate with the savings dashboard, threshold alerts so users only hear about relevant deals, and proactive re-engagement.
• Booking handoff leakage: value is hard to attribute through external booking. Mitigate with handoff tracking and a later assisted-booking flow.

Phased rollout

• Phase 1 (Weeks 1 to 6): Single corridor pilot: launch one high-density route (for example NYC to Miami) with the deal feed, alerts, and membership. Validate supply and willingness to pay.
• Phase 2 (Weeks 7 to 12): Personalization: add filters, deal quality scores, and the savings dashboard. Expand to two or three more corridors.
• Phase 3 (Weeks 13 to 24): Scale and retention: broaden corridors, test assisted booking, and add annual and referral plans, optimizing for net member months retained.

Job Habit

A habit tracker that turns an overwhelming job search into three timed daily sessions, so seekers stay consistent through a long search.

The 30-second version. Job Habit is a daily job-search session tracker built solo on Lovable, with a companion application-pipeline dashboard. It reframes the job hunt from an anxious, formless slog into a repeatable 3.5-hour ritual: three timed sessions (Warm Outreach 90 min, Applying 60 min, Follow-Up 60 min), each with its own task list, circular timer, and a streak counter that rewards showing up. The PM work on display is behavior design (consistency over intensity, structure over willpower), a tight focus on the one variable a seeker controls (daily effort, not outcomes), and an interaction model built around momentum and small wins.

---

Timeline: Built in a focused session, in testing.

---

1. Problem statement

A job search is a long, demoralizing process with no fixed end date and almost no positive feedback along the way. Rejection is the norm, progress is invisible, and the work itself is formless: there is always more outreach to do, more applications to send, more follow-ups pending, and no signal that today was "enough." That shapelessness is what burns people out. They binge for a weekend, crash, then avoid the search for days. Job Habit's hypothesis, drawn from habit and behavior design, is that the seeker controls exactly one thing (daily effort, not the outcome) and that giving that effort a bounded, repeatable structure (a fixed 3.5-hour ritual with visible streaks) sustains the consistency that a long search actually requires. The cost of not solving this is the avoidance spiral: missed days, lost momentum, and a search that drags longer than it should.

2. Goals and non-goals

Goals

• Make daily job-search effort consistent by giving it a bounded, repeatable structure (user outcome).
• Shift the seeker's focus from uncontrollable outcomes to controllable daily action (user outcome).
• Reward showing up with streaks and visible progress so motivation survives a long search (user outcome).
• Reduce decision fatigue by pre-defining what each session contains (user outcome).

Non-goals

• Not a job board or aggregator. Finding roles is a different problem; this is about doing the work.
• Not an applicant tracking system in the main app (the companion dashboard covers pipeline). The tracker stays about today's effort.
• No gamified vanity metrics beyond streak and session completion. Vanity points would distract from real effort.
• No account or cloud sync required to start. Friction at the door defeats a daily-habit tool.

3. The product

A single-screen daily ritual built around three timed sessions and a streak.

The screen shows today's date, the title "Your 3 1/2 Hours," a streak pill and a sessions-done pill, and a full-width progress bar that fills across all 210 minutes. Each session is a card with a circular SVG progress ring, an MM:SS countdown, a task list that appears when the card is active, and an optional notes field. A controls bar (Start, Pause, Reset, Done) drives the active session; completing one triggers a pop-in animation, and finishing all three reveals a celebration banner. A rotating motivational quote anchors the footer. The companion HTML dashboard tracks the actual application pipeline (metrics row, status columns for active, their move, interviews, and rejected or closed) as a separate, outcomes-facing view.

4. User stories

The overwhelmed seeker

• As someone who does not know where to start each day, I want three pre-defined sessions so that I can just begin instead of deciding.
• As someone who burns out, I want a bounded 3.5-hour daily target so that I know when I have done enough and can stop guilt-free.

The motivation-starved seeker

• As someone facing constant rejection, I want a streak that rewards showing up so that my effort is acknowledged even when outcomes are not.
• As someone who needs momentum, I want a celebration when I complete all three sessions so that finishing feels like a win.

The organized seeker

• As someone juggling many applications, I want a separate pipeline view so that tracking outcomes does not clutter my daily-effort ritual.

Edge and error states

• As a user who gets interrupted, I want to pause and resume a session without losing my time so that real life does not break my streak.
• As a user who only finishes some sessions, I want partial progress reflected honestly so that the tool stays trustworthy rather than punishing.

5. Requirements

Must-have (P0)

• Three timed sessions with correct durations (90, 60, 60).
  • Given a user selects a session and presses Start, when time elapses, then the countdown and ring decrement accurately and mark the session done at zero.
• Start, Pause, Resume, Reset, and Done controls.
  • Given a running session, when the user pauses, then the timer holds and Start becomes Resume; when reset, the session returns to full duration.
• Streak and sessions-done counters that update dynamically.
  • Given a user completes sessions, when state changes, then the streak and "N/3 Sessions" pills update.
• Overall progress bar across all 210 minutes.
  • Given any session progresses, when time elapses, then the full-width bar fills proportionally.
• Completion and celebration states.
  • Given all three sessions are done, when the last completes, then the celebration banner appears.

Nice-to-have (P1)

• Per-session task lists and optional notes.
• Rotating motivational quotes.
• Companion pipeline dashboard for outcomes tracking.

Future (P2)

• Persistence and cross-device sync of streaks and notes.
• Customizable session durations and tasks.
• Light analytics on consistency over time.

6. Key product decisions and trade-offs

Decision 1: Consistency over intensity.

• Choice: A bounded daily ritual (3.5 hours, three sessions) with a streak, rather than open-ended productivity tracking.
• Alternatives: An unbounded to-do list (rejected, reproduces the formlessness that causes burnout); pure outcome tracking (rejected, rewards things the user cannot control).
• Why this won: Habit research says consistency beats sporadic intensity, and a bounded target gives the seeker permission to stop, which is what makes the habit sustainable.

Decision 2: Three fixed sessions with pre-defined tasks.

• Choice: Outreach, Applying, Follow-Up, each with a starter task list.
• Alternatives: Let users define their own structure (rejected, decision fatigue is the enemy); a single undifferentiated work block (rejected, hides that the three kinds of job-search work need different energy).
• Why this won: Pre-defined structure removes the daily "where do I start" friction and reflects that outreach, applying, and following up are genuinely different modes.

Decision 3: Effort tracking and outcome tracking, kept separate.

• Choice: The daily app tracks effort and streaks; a companion dashboard tracks the application pipeline and outcomes.
• Alternatives: Merge them into one screen (rejected, outcome data, full of rejections, would poison the daily-momentum tool); drop outcome tracking entirely (rejected, seekers still need a pipeline view).
• Why this won: Keeping rejection-heavy outcome data out of the daily ritual protects the motivational core of the habit, while the separate dashboard still serves the organizing need. This is the deliberate, slightly unflattering trade-off: two surfaces instead of one clean integrated product.

Decision 4: Works immediately, no account wall.

• Choice: Start the ritual with no login required.
• Alternatives: Require sign-up for streak persistence (rejected, friction at the door kills daily-habit adoption).
• Why this won: A daily-habit tool has to be frictionless on day one. The cost is that streaks do not persist across devices without later sync, which is a v2 problem.

7. UX

A calm, single-screen daily dashboard. Plus Jakarta Sans, a soft off-white background (#FAFAFA), and three accent colors that code the sessions (coral outreach, teal applying, amber follow-up). The header states the date and "Your 3 1/2 Hours"; stat pills show streak and sessions done . Each session card carries a stroke-animated circular progress ring with the countdown inside, a status label, and, when active, its task list and notes toggle . Motion is purposeful and rewarding: staggered fade-ups on load, a pop-in on completion, a gentle pulse on the running timer, and a celebration banner when all three finish . The companion pipeline dashboard uses a darker, editorial treatment (Fraunces display, IBM Plex) to visually separate outcome tracking from the daily ritual .

8. Success metrics and validation

Leading indicators

• Daily completion rate (target: user completes all three sessions on [X%] of days), measured by completion events.
• Streak length distribution (target: median streak of [X] days), measured from streak data.
• Session start rate (target: [X%] of opens lead to at least one session started), measuring whether the structure lowers activation energy.

Lagging indicators

• Retention over a multi-week search (target: [X%] of users active in week 4), the real test of a habit tool.
• Self-reported consistency and reduced burnout (target: [X%] report the ritual helped them stay consistent).

All actuals are bracketed placeholders. No usage, streak, or retention data has been validated.

What didn't work, and what I'd change. The biggest honest weakness is the missing persistence: a streak that resets when you close the tab undercuts the exact mechanic the whole product depends on, so streak storage is the first thing I would build before any real test. The fixed 3.5-hour target is also an assumption, not a validated dose; for some searches it is too much (part-time seekers, those still employed) and the rigidity could itself cause avoidance. I would test adjustable durations and a "minimum viable day" option. Finally, splitting effort and outcome into two surfaces is a real cost: I would validate whether users actually want a unified view despite the motivational risk, or whether the separation holds.

9. Open questions and roadmap

Open questions

• Is 3.5 hours the right daily dose, or should it flex by situation? (user, data)
• Does the streak mechanic sustain motivation or eventually create guilt that drives avoidance? (user)
• Should effort and outcome tracking eventually merge, and at what cost to morale? (design, user)
• What is the minimum persistence needed for streaks to feel real? (eng)

Roadmap (v2)

• Streak and notes persistence with optional sync.
• Adjustable session durations and a minimum-viable-day mode.
• Light consistency analytics over time.

Positioning

GTM hypothesis: reach active job seekers (including MBA and early-career searchers) through job-search communities, positioning the bounded daily ritual as the antidote to search burnout. Defensible because the behavior-design framing and the deliberate effort-versus-outcome separation are opinionated product choices, not generic features.

10. What this project demonstrates

• Problem identification: named search burnout and formlessness as the real enemy, not a lack of job listings.
• Behavior design: applied habit principles (consistency over intensity, controllable effort, streaks, bounded scope) to a real emotional problem.
• Trade-off reasoning: deliberately separated effort from rejection-heavy outcome data to protect motivation, and named the cost.
• Technical fluency: precise client-side timer logic (intervals, refs, ring animation via strokeDashoffset) with clean state handling.
• Validation discipline: flagged missing persistence and the unproven 3.5-hour dose as the top risks to test.
• Communication: a single-screen ritual that makes "what does enough look like today" instantly legible.

Cover Letter Crafter

An AI tool that turns a job posting and a resume into a tailored, ready-to-send cover letter in minutes.

The 30-second version. Cover Letter Crafter is an AI writing tool built solo on Lovable that drafts a personalized cover letter from two inputs the job seeker already has: the role they are applying to and their resume. It exists to kill the single most-procrastinated step in any job search. The PM work on display is sharp problem scoping (one job, done well, not a general writing suite), input design that gets a strong draft from minimal effort, and an honest stance on AI assistance: the tool drafts, the human edits and owns.

---

Note: the live URL's domain string is a leftover artifact from a renamed Lovable project. It is unrelated to any company and carries no affiliation.

---

Timeline: Weekend prototype, in testing.

---

1. Problem statement

The cover letter is the most-dreaded, most-procrastinated step in a job application. Job seekers know a tailored letter helps, but writing one well from scratch for every role is slow, repetitive, and emotionally draining, so most people either skip it, recycle a generic template, or stall on applications entirely. During an active search that can mean dozens of letters, the friction compounds into fewer applications sent. Cover Letter Crafter's hypothesis is that the inputs needed for a strong, specific letter (the target role and the applicant's own resume) already exist, and that an AI tool can assemble a tailored first draft in minutes, turning a multi-hour chore into an edit-and-send. The cost of not solving this is real: applications not submitted because the letter felt like too much work.

2. Goals and non-goals

Goals

• Produce a strong, role-specific cover letter draft in minutes, not hours (user outcome).
• Make the draft personal by grounding it in the applicant's actual resume, not a generic template (user outcome).
• Lower the activation energy of applying so seekers send more applications (user and business outcome).
• Keep the human in control: the tool drafts, the person edits and owns the final letter (trust outcome).

Non-goals

• Not a general-purpose writing assistant. Scope to cover letters keeps the inputs and output sharp.
• No full resume builder or applicant tracking. Those are adjacent products, not this one.
• No auto-submission to job boards. Sending an unreviewed AI letter is a reputation risk for the user.
• No claim of guaranteed interviews or outcomes. The tool removes friction; it does not promise results.

3. The product

A focused two-input, one-output tool.

The core mechanic is matching: the tool reads the role to understand what the employer wants, reads the resume to understand what the applicant offers, and writes a letter that connects the two specifically rather than generically. The output is a starting draft the user is expected to review and personalize before sending.

4. User stories

The active job seeker

• As someone applying to many roles, I want a tailored letter drafted from the posting and my resume so that I spend minutes per application instead of hours.
• As an applicant, I want the letter to reference my actual experience so that it reads as personal, not templated.
• As a seeker who stalls on writing, I want a strong first draft to react to so that I get past the blank page.

The careful applicant

• As someone who cares about quality, I want to freely edit the draft before using it so that the final letter is in my own voice and I stand behind every word.

Edge and error states

• As a user with a thin or unusual resume, I want the tool to still produce a usable draft (or tell me what it needs) so that I am not blocked.
• As a user who dislikes the first output, I want to regenerate or adjust so that one weak draft is not the end of the road.

5. Requirements

Must-have (P0)

• Accept a role or job posting as input.
  • Given a user pastes a job posting, when they submit, then the role context is used in generation.
• Accept resume content as input.
  • Given a user provides resume content, when they generate, then the letter references that experience.
• Generate a tailored cover letter draft.
  • Given both inputs, when the user requests a draft, then a complete, role-specific letter is returned in a reasonable time.
• Allow editing of the draft.
  • Given a generated draft, when the user edits it, then their changes are preserved.

Nice-to-have (P1)

• Regenerate or tone or length adjustment.
• Copy-to-clipboard or export.
• Saving multiple letters for different roles.

Future (P2)

• Resume import from a file.
• Tone presets matched to industry.
• Integration into a broader job-search toolkit.

6. Key product decisions and trade-offs

Decision 1: One job, done well.

• Choice: Build a cover-letter tool, not a general AI writing app.
• Alternatives: A broad writing assistant (rejected, diffuse value and no clear input or output); a full application suite (rejected, far larger scope than a prototype can validate).
• Why this won: A single, well-understood job has obvious inputs (role and resume) and an obvious output, which makes both the build and the value crisp.

Decision 2: Resume as a required input, not optional.

• Choice: Ground every letter in the applicant's actual resume.
• Alternatives: Generate from the job posting alone (rejected, produces generic letters that defeat the purpose); ask a long questionnaire (rejected, reintroduces the friction the tool exists to remove).
• Why this won: The resume is the cheapest source of real personalization the user already has, and it is what separates a tailored letter from a template.

Decision 3: Draft-and-edit, not auto-send.

• Choice: The tool produces a draft the human reviews and owns; it never submits.
• Alternatives: One-click apply with the generated letter (rejected, sends unreviewed AI text under the user's name, a real reputation risk); lock the output (rejected, removes the human voice).
• Why this won: Keeping the human in the loop protects the user's credibility and respects that a cover letter is a personal artifact. The trade-off is that the tool cannot honestly promise a finished, send-ready letter with zero effort; it promises a strong head start, which is the right honest claim.

7. UX

A minimal, focused interface: input the role, input the resume, generate, edit, use. The screen design keeps the seeker on a single clear path with no distractions from the one job . The generated draft appears in an editable area so refinement is immediate and obvious . The visual language is clean and utilitarian, signaling a fast tool rather than a heavyweight editor.

8. Success metrics and validation

Leading indicators

• Draft completion rate (target: [X%] of sessions that start reach a generated draft), measured by generation events.
• Time from start to usable draft (target: under [X] minutes), measured per session.
• Edit-then-use rate (target: [X%] of drafts are edited and exported, signaling the draft was good enough to build on).

Lagging indicators

• Return usage during an active search (target: [X] letters per returning user), the signal that it became a job-search habit.
• Self-reported satisfaction or "would recommend" (target: [X%]).

All actuals are bracketed placeholders. No usage, quality, or outcome figures have been validated. Note: the source build prompt for this project is a single line, so this PRD reconstructs intended scope from the product's purpose rather than a detailed spec.

What didn't work, and what I'd change. The honest gap is output quality measurement: "drafts a strong letter" is a claim I cannot back without seeing real letters scored against real ones. I would run a blind comparison (tool draft vs self-written) on application response rates, or at minimum collect edit-distance data to see how much rewriting users actually do. If users rewrite the whole thing, the tool is a blank-page-breaker, not a drafting tool, and I should position it that way. I would also test whether resume-only grounding is enough or whether a single targeting question ("why this role?") meaningfully lifts letter quality without adding real friction.

9. Open questions and roadmap

Open questions

• How good are the drafts versus self-written letters, measured how? (data, user)
• Is resume plus posting enough, or does one targeting question materially improve output? (user)
• What is the right balance between draft polish and leaving room for the user's voice? (design)
• Are there fairness or accuracy risks in how the model represents an applicant's experience? (legal, user)

Roadmap (v2)

• File-based resume import and saved letters.
• Tone and length controls.
• A path into a broader job-search workflow alongside tracking and motivation tools.

Positioning

GTM hypothesis: reach active job seekers at the moment of friction (the unwritten letter), likely through job-search communities and as one tool in a small career toolkit. Defensible less by technology than by focus: a tool that does exactly one painful thing well is easier to reach for than a general assistant.

10. What this project demonstrates

• Problem identification: located the single most-procrastinated step in applying and built directly against it.
• Trade-off reasoning: chose draft-and-edit over auto-send to protect the user's credibility, and named the honest claim that follows.
• Input design: used the resume the user already has as the cheapest path to real personalization.
• Validation discipline: flagged output quality as the unproven core claim and proposed how to test it.
• Scope sense: resisted expanding into a general writing or full job-search suite.
• Communication: a clear, single-purpose product framing from a deliberately minimal brief.

Job Spark

A job-search motivation app that delivers encouragement and small wins to keep seekers energized through the emotional grind of looking for work.

The 30-second version. Job Spark is an unpublished job-search prototype built solo on Lovable. It started as a CBS job aggregator (centralizing scattered club Airtables and submissions into one filterable, trackable feed) and is positioned toward the emotional side of the search: keeping seekers motivated and surfacing small wins through a long, demoralizing process. The PM work on display is a clean Business Requirements Document with stakeholders, scope, data model, functional requirements, and Given-When-Then acceptance criteria, plus a clear-eyed primary-versus-secondary problem framing. This PRD documents the prototype honestly: the recovered build is the aggregator BRD; the motivation framing is the product's intended direction.

---

Timeline: Early prototype, unpublished.

---

1. Problem statement

A job search is fragmented and draining. On the practical side, CBS club members waste time cross-checking multiple club Airtables and WhatsApp channels to find relevant roles, and there is no standardized way for club leaders to post them. On the emotional side, the search is a long grind of rejection and invisible progress where motivation quietly erodes. Job Spark's hypothesis is that these are two faces of the same problem: when finding and tracking roles is frictionless and progress is made visible, the search feels less hopeless and seekers stay in it. The earliest recovered build attacks the practical fragmentation directly (a single filterable feed); the product's positioning extends that into sustaining motivation through small, visible wins. The cost of not solving this is seekers who give up or coast, not for lack of opportunities but for lack of energy and orientation.

2. Goals and non-goals

Goals

• Centralize fragmented job discovery into one filterable interface so seekers stop cross-checking sources (user outcome).
• Give club leaders a standardized way to post roles without managing multiple Airtable instances (stakeholder outcome).
• Let seekers track and bookmark roles in one place so the search feels organized, not chaotic (user outcome).
• Sustain motivation by making progress and small wins visible through a long search (user outcome, the product's positioning).

Non-goals (MVP)

• No application status tracking in MVP. Identification and personal tracking come first; status workflows add scope.
• No messaging or networking features. They expand the surface well beyond the core problem.
• No resume parsing. A separate, heavier capability.
• No salary data or company ratings. Out of scope for an early discovery-and-motivation tool.

3. The product

Per the recovered BRD, a three-page aggregator with private and shared visibility controls, framed by a motivation-forward positioning.

The core mechanic is aggregation plus visibility control. Club leaders paste an Airtable URL and the system auto-syncs those roles into the central Jobs table; any user can submit a one-off role and choose whether it is private to them or shared widely. The search page unifies both sources behind category and industry filters, and the personal tracker gives each seeker an organized view of what they are pursuing. The motivation layer (the product's positioning) builds on this foundation: a tracked, progressing list of pursued roles is itself a record of action, the raw material for surfacing small wins and encouragement.

4. User stories

The CBS job seeker

• As a club member, I want all club roles in one filterable feed so that I stop cross-checking Airtables and WhatsApp.
• As a seeker, I want to bookmark roles into a personal tracker so that my search feels organized.
• As a seeker filtering by category and industry, I want only matching roles so that I focus on what fits.
• As a seeker grinding through rejection, I want my accumulated actions and saved roles reflected back as progress so that I stay motivated.

The club leader (AVP)

• As a club AVP, I want to link our Airtable once and have roles auto-sync so that I do not manage a separate submission system.

The contributor

• As any user, I want to submit a one-off role and choose private or public so that I control who sees what I post.

Edge and error states

• As a user posting a private job, I want it visible only to me so that visibility controls are trustworthy.
• As a user, I want a newly linked Airtable's jobs to appear promptly (within minutes) so that the feed feels live.

5. Requirements

Must-have (P0)

• Club AVP Airtable linking with auto-sync.
  • Given an AVP submits an Airtable URL, when they save it, then that Airtable's jobs appear in search within 5 minutes.
• One-off job submission with visibility toggle.
  • Given a user submits a role marked private, when they search, then they see it; when another user searches, then they do not.
• Search with category and industry filters.
  • Given a user filters by "Tech" and "Finance," when they apply both, then only roles matching both appear.
• Personal tracker scoped to the user.
  • Given a user opens the tracker, when it loads, then only roles they added or saved appear.
• Visibility default and toggle.
  • Given a job defaults to private, when the user toggles it public, then other users can see it in search.

Nice-to-have (P1)

• Expandable job cards with full detail.
• All-jobs versus personal-only view toggle.
• Motivation layer: surfacing small wins and encouragement from tracked activity.

Future (P2)

• Application status tracking.
• Messaging or networking.
• Resume parsing, salary data, company ratings.

6. Key product decisions and trade-offs

Decision 1: Aggregate existing sources, do not replace them.

• Choice: Let club leaders link their existing Airtables and auto-sync, rather than forcing migration to a new system.
• Alternatives: A brand-new posting platform leaders must adopt (rejected, adoption friction kills the feed before it fills); manual re-entry (rejected, unsustainable).
• Why this won: Meeting leaders where their data already lives is the only realistic path to a populated, current feed.

Decision 2: Private-by-default visibility.

• Choice: One-off submissions default to private, with an explicit toggle to share.
• Alternatives: Public by default (rejected, exposes roles users meant to keep for themselves and erodes trust); no private option (rejected, removes the personal-tracker use case).
• Why this won: A trustworthy default protects users and makes the personal tracker genuinely personal, while sharing stays one deliberate click away.

Decision 3: Identification first, status tracking later.

• Choice: Scope MVP to finding and bookmarking roles (primary problem), explicitly deferring application status tracking (secondary).
• Alternatives: Build full application tracking in MVP (rejected, large scope that delays the core value); skip tracking entirely (rejected, seekers need at least a bookmark list).
• Why this won: Naming the primary problem (job identification) and the secondary one (personal tracking), then cutting status workflows, keeps the MVP shippable. This is the disciplined, slightly unflattering trade-off: the product ships without the status-tracking many users will eventually want.

Decision 4: The motivation layer rides on the tracker, it is not a separate app.

• Choice: Build encouragement and small-wins surfacing on top of real tracked activity rather than as standalone affirmations.
• Alternatives: A pure motivation app with generic encouragement (rejected, hollow without grounding in the user's actual progress); ignore motivation (rejected, it is the product's positioning).
• Why this won: Encouragement tied to the user's real actions is credible; encouragement floating free of them is noise.

7. UX

A clean, utilitarian three-page web app: upload, search, tracker. The upload page presents two clearly separated paths (Airtable link for leaders, one-off form for everyone) so neither audience is confused about which is theirs . The search page leads with filters (category, industry) and an all-versus-personal toggle, with expandable cards for detail . The personal tracker is a focused list of saved roles, the surface the motivation layer builds on . As an unpublished prototype, the visual language is functional and to be refined.

8. Success metrics and validation

Leading indicators

• Feed population: number of clubs with linked Airtables (target: [X] clubs), measured from the Airtable Links table.
• Search usage: share of active users who run a filtered search (target: [X%]), measured by filter events.
• Tracker adoption: share of users who save at least one role (target: [X%]), measured by tracker writes.

Lagging indicators

• Return usage during a search (target: [X] sessions per week per active seeker), the engagement signal.
• Self-reported orientation and motivation (target: [X%] report the tool made the search feel more manageable).

All actuals are bracketed placeholders. This is an unpublished prototype; no usage, adoption, or motivation data exists. Acceptance criteria above are from the recovered BRD and are design targets, not measured outcomes.

What didn't work, and what I'd change. The honest tension here is positioning: the recovered build is an aggregator, while the product is described as a motivation app, and those are not the same thing. Before building further I would resolve which is the wedge. The aggregator has a concrete, testable value (less cross-checking) and a clear cold-start risk (an empty feed if clubs do not link); the motivation layer is more differentiated but harder to make non-hollow. I would validate the aggregator's cold-start first (can I get a critical mass of clubs linked?), because the motivation layer is only credible once there is real tracked activity to motivate around. I would also pressure-test whether private-by-default suppresses sharing so much that the public feed stays thin.

9. Open questions and roadmap

Open questions

• Is the wedge the aggregator (utility) or the motivation layer (differentiation), and which do we lead with? (product, user)
• How do we solve the cold-start: get enough clubs linked before the feed feels useful? (data, user)
• Does private-by-default starve the shared feed? (data)
• What makes the motivation layer feel earned rather than hollow? (design, user)

Roadmap (path to a buildable v1)

• Resolve positioning, then ship the aggregator core (three pages, sync, filters, tracker).
• Layer motivation on top of real tracked activity (small wins, streak-style encouragement).
• Add application status tracking once identification and tracking are proven.

Positioning

GTM hypothesis: launch within the CBS club ecosystem where the fragmentation is acute and the network is warm, then extend the motivation layer as the differentiator. Defensible because the aggregation of club-specific sources plus an emotional layer is tailored to a community generic boards do not serve.

10. What this project demonstrates

• Problem identification: separated the practical problem (fragmented discovery) from the emotional one (motivation) and related them.
• BRD rigor: a structured spec with stakeholders, scope, data model, functional requirements, and Given-When-Then acceptance criteria.
• Trade-off reasoning: scoped MVP to identification first, deferred status tracking, and named the cost.
• Honest framing: documented the gap between the recovered aggregator build and the motivation positioning rather than papering over it.
• Validation discipline: identified cold-start as the first thing to prove before building the differentiated layer.
• Roadmap sense: a clear path from aggregator core to motivation layer to status tracking.

Tandem (Pomodoro Pals)

A shared focus room for two cofounders: one timer, one rhythm, and a block only starts when both people press start.

The 30-second version. Cofounders who work remotely lose the quiet accountability of sitting at the same desk. Tandem recreates it: one person opens a room and shares a five-character code, the other walks in, and both run the same 50-minute focus and 10-minute break timer. A block only starts when both press start, so neither person drifts. A Solo mode keeps the timer for days alone. Built solo on Lovable.

Live: https://cofounder-focus-flow.lovable.app

Problem

Early-stage founders often work apart, and the hardest part of deep work is starting. Solo Pomodoro apps track time but add no social commitment, and video "body doubling" calls are heavy and distracting.

Who it is for

Two-person founding teams and close collaborators who want light accountability without a meeting.

How it works

Key decisions

• Two people, not a group. The product is a desk for a pair; if a room is full, someone is already holding your chair.
• Mutual start. Requiring both people to press start turns the timer into a small commitment device.
• No video. Presence without a camera keeps attention on the work.

Success metrics

Rooms opened per week, share of rooms where the second person joins, completed blocks per pair, and weekly return rate.

What I would do next

A shared task line for each block and a weekly summary of focus time per pair.

Wanderline (Map Tour Audio)

Name a place and an AI guide plans a walking tour, writes each stop, and reads it aloud the moment you arrive.

The 30-second version. Audio tours exist for famous museums, not for the neighborhood you are standing in. Wanderline lets a user type any place or use their location, choose what to lean into (history, architecture, food, street art, hidden gems) and a length of 3, 5 or 8 stops. AI plans the route and writes each stop, and narration starts automatically, by GPS, as the walker approaches. Built solo on Lovable.

Live: https://stroll-soundscape-guide.lovable.app

Problem

Travelers and locals walk past interesting places without knowing their story. Guidebooks require reading while walking, and recorded tours cover only a few landmarks.

Who it is for

Travelers, new residents and curious locals who want a self-guided walk anywhere, with headphones in and phone in pocket.

How it works

1. Type a neighborhood or use your current location.
2. Choose a focus (history, architecture, food, street art, hidden gems) and a length (3, 5 or 8 stops).
3. AI plans the route on a live map and writes a script for each stop.
4. Narration plays automatically when you come within range of each stop.

Key decisions

• Location-triggered audio. The walker never has to look at the screen; the tour talks when you arrive.
• Adjustable trigger distance. Phone GPS drifts 10 to 30 meters between tall buildings, so the trigger radius can be tuned on the tour screen.
• Interest-led routes. The same street becomes a different tour depending on what the user wants to notice.

Success metrics

Tours completed versus started, stops narrated per tour, and share of users who build a second tour.

What I would do next

Saved and shareable tours, offline audio for weak signal, and fact-checking of generated scripts for well-known sites.

Question Architect (Question Craft)

A thinking tool that walks you through the ten elements of a strong prompt and assembles a precise question to use in any AI tool.

The 30-second version. Most weak AI answers come from weak questions. Question Architect breaks a prompt into ten structural elements (role, context, task, constraints, tone, dos and don'ts, examples, output format, open-ended framing and an iteration hook) and builds the prompt live as the user fills them in. It is a thinking tool, not a chat interface: the user copies the finished question into whichever AI they trust. Built on the QI framework for executive question design from my Columbia coursework. Built solo on Lovable.

Live: https://think-a-prompt.lovable.app

Problem

People type vague requests into AI tools and get generic answers. Prompt advice is scattered across threads and rarely structured as a repeatable method.

Who it is for

Professionals, students and job seekers who use AI for strategy, writing and outreach and want consistently better answers.

How it works

• Ten guided steps, each with a short tip (for example, define a specific methodology instead of a generic "expert" label).
• Skip any element that does not serve the task.
• A live preview assembles the prompt and counts completed elements; one click copies it.
• Starter modes for Product and Strategy, Job Search and Outreach, and Personal Writing, plus Expand, Audit and Split tools.

Key decisions

• Build the question, do not answer it. Keeping the product model-agnostic makes it useful with any AI tool.
• Structure over volume. Ten named elements teach the method, so users improve even without the tool.
• Skippable steps. Not every task needs all ten; the tool rewards precision, not length.

Success metrics

Prompts copied per session, average elements completed per prompt, and return use.

What I would do next

Saved prompt templates and a before-and-after view comparing answers to a basic prompt and an architected one.

Recipe Health

Turns a nutrition goal into a guided cook-along, so eating well becomes a thing you do, not a thing you read about.

The 30-second version. Recipe Health is a guided recipe challenge that turns a specific health goal (here, an iron-rich, anti-inflammatory, heart-healthy eating plan for two) into a single flowing experience: a categorized shopping list you check off, then a deck of 41 recipes you cook one at a time, each under 30 minutes and each tagged with the nutrition reason it earns its place. The current build is a self-contained React prototype with a four-state flow (intro, shop, cook, done), per-item check state, and a progress bar. It demonstrates PM work in turning a clinical goal into a behavior-change loop, designing for adherence rather than information, and being honest about the safety boundary of nutrition guidance.

---

Timeline: Working prototype, live URL pending

---

1. Problem statement

People are told what to eat for a health goal (more iron, less inflammation, a kinder diet for the heart) and then left alone to translate that advice into a week of actual meals. The translation is the hard part: deciding what to buy, what to cook, in what order, and whether any given meal is even helping. Most nutrition content stops at the recipe and never closes the loop from goal to grocery list to a meal on the plate, so good intentions stall at the point of execution. The cost is real for anyone managing a condition through diet, where consistency matters more than any single perfect meal. Recipe Health starts from the hypothesis that adherence comes from a guided, low-decision flow, not from another PDF of recipes.

2. Goals and non-goals

Goals

• Convert a nutrition goal into action by sequencing the whole journey: shop, then cook, one recipe at a time.
• Make every recipe legibly purposeful by attaching a short reason it serves the goal (for example, "lentils are an iron powerhouse; lemon adds vitamin C").
• Lower the activation energy of healthy cooking: every recipe under 30 minutes, scaled for two, with a checkable shopping list so nothing is forgotten.
• Build a structure that generalizes from this one challenge (Red and Iron) to other goals (low-sodium, anti-inflammatory, postpartum) without redesign.

Non-goals

• Calorie or macro tracking. Out of scope because the product is about adherence to a curated plan, not quantified logging.
• Personalized meal generation by AI. Out of scope to keep the recipes human-curated and trustworthy for a health context.
• Grocery delivery or commerce. Out of scope for the prototype; the value to prove first is the flow, not the transaction.
• Medical claims. Explicitly out of scope; the app states it is general nutrition guidance, not medical advice.

3. The product

The app is a single guided flow with four states. The user moves through them in order, but can jump back to the list at any time.

The core mechanic is the cook loop: see one recipe, cook it, mark it complete, advance. The progress bar makes the 41-recipe challenge feel finite and winnable rather than overwhelming.

4. User stories

As someone managing my iron and heart health through diet, I want a single plan that tells me what to buy and what to cook next, so that I do not have to assemble a week of meals from scratch.

As a cook with limited time, I want every recipe to be under 30 minutes and scaled for two, so that healthy eating fits a real weeknight.

As someone who wants to understand my food, I want each recipe to say why it helps (iron, vitamin C pairing, anti-inflammatory), so that I learn the logic and can keep it up after the challenge ends.

As a shopper, I want to check items off a categorized list and see my progress, so that I can shop in one trip without forgetting anything.

As a user who finishes (completion state), I want a clear "done" moment and an easy way to start over, so that the challenge feels like an accomplishment and a habit I can repeat.

As a user with a heart condition (safety edge case), I want a clear up-front note that this is general guidance and that I should confirm sodium, potassium, and vitamin K targets with my doctor, so that I am not misled into treating the app as medical advice.

5. Requirements

Must-have (P0)

• Four-state guided flow (intro, shop, cook, done) with forward progression and a back-to-list escape hatch.
  • Given a user starts at intro, when they tap through, then they reach shop, then cook, then done, and can return to the list from any recipe.
• Categorized, checkable shopping list with a gathered count.
  • Given the shop view, when a user taps an item, then it toggles checked and the "X of N gathered" count updates.
• One-recipe-at-a-time cook deck with a per-recipe nutrition reason and numbered steps.
  • Given the cook view, when a user marks a recipe complete, then the next recipe loads and the progress bar advances.
• Up-front, non-dismissable medical-advice disclaimer.
  • Given the intro screen, when it renders, then the "general nutrition guidance, not medical advice" note is visible before the user begins.

Nice-to-have (P1)

• Persistence of check state and recipe progress across sessions (currently in-memory only).
• Adjustable serving scale (for one, for four).
• A way to mark favorite recipes to repeat.

Future (P2)

• Multiple challenge templates (low-sodium, anti-inflammatory, postpartum recovery) on the same engine.
• Export the shopping list or sync to a grocery service.
• Light tracking of how the goal-relevant nutrients add up across the plan.

6. Key product decisions and trade-offs

Decision: Sequence the whole journey (shop then cook) instead of presenting a recipe library.

Alternatives considered: a searchable recipe collection (rejected because search puts the decision burden back on the user, which is exactly where adherence breaks); a daily meal-plan calendar (rejected as too rigid for how people actually cook). Why this won: a guided flow with a single next action is the lowest-friction path from goal to plate, which is the behavior the product exists to drive.

Decision: One recipe at a time with a progress bar, not a grid.

Alternatives considered: showing all 41 recipes at once (rejected because volume is intimidating and kills momentum). Why this won: a finite, advancing challenge reframes 41 recipes as a winnable journey, and the progress bar borrows the completion psychology that makes habit apps work, without resorting to streaks or guilt.

Decision: Attach a one-line nutrition reason to every recipe.

Alternatives considered: a separate "learn" section (rejected as something users skip). Why this won: embedding the reason in the recipe teaches the logic in context, so the user can keep eating this way after the challenge, which is the real outcome.

Decision (the honest trade-off): Hard-coded content and in-memory state for the prototype.

The current build embeds the shopping list and all 41 recipes as static data, and check or progress state lives only in component memory, so a refresh resets it. Alternatives considered: building persistence and a content backend first (rejected to validate the flow before investing in infrastructure). Why this won for now: the riskiest assumption is whether the guided flow drives adherence, not whether the data persists, so proving the experience came first. The cost is real, persistence is the most important P1, because a recovery or health plan that forgets your progress is not yet shippable to a real user.

Decision: Lead with a safety disclaimer.

Why this won: any product giving nutrition guidance for a health condition has an ethical and trust obligation to state its limits before the user acts. Putting it on the intro, not buried in a footer, is the responsible default.

7. UX

The visual language is warm and editorial: a paper-cream background with green, terracotta, and ochre accents, Fraunces serif display type against a Karla sans body, subtle grain, and staggered fade-in animation. It reads like a beautifully designed cookbook rather than a clinical app, which matters because the goal is to make healthy eating feel inviting, not prescriptive. The mobile-first 480px column and large tap targets (checklist rows, full-width primary buttons) keep it usable one-handed in a kitchen.

8. Success metrics and validation

Leading indicators

• Shop-to-cook conversion: percentage of users who finish the shopping list and start cooking. Target: [55%+]. Measured by state-transition events.
• Recipe completion rate: average recipes marked complete per user. Target: [8+ of 41]. Measured by the cook progress counter.
• Reason engagement: whether users who read the nutrition reason complete more recipes (a proxy for whether teaching drives adherence). Measured once instrumented.

Lagging indicators

• Challenge completion: percentage of starters who reach the done screen. Target: [to be populated after validation].
• Repeat: percentage who start a second challenge. Target: [to be populated after validation].
• Self-reported habit change: survey on whether users kept cooking this way after the challenge. Target: [to be populated after validation].

What didn't work, and what I'd change.

The prototype proves the flow but not retention, because state is in-memory and resets on refresh, which makes a multi-day challenge effectively un-trackable for a real user. The first thing I would change is persistence (Supabase or local storage) so that progress survives, since a health plan that forgets where you are is the one thing this category cannot afford. I would also separate content from code so that new challenges (low-sodium, postpartum) can be authored without touching the component, which is the unlock for the product to be more than one challenge. Finally, the nutrition reasons are currently asserted, not sourced; for a health product I would want them reviewed against a credible nutrition reference before any public launch.

9. Open questions and roadmap

• Should progress live on-device (private, no account) or in an account (cross-device, but adds friction and a privacy surface for health data)? (Owner: design + legal.)
• What is the right review standard for nutrition claims before public launch? (Owner: legal + a nutrition reviewer.)
• Does the challenge format generalize, or do some goals need a different structure (for example, a daily rather than sequential plan)? (Owner: user research.)

v2 scope: persistence, multiple challenge templates on one engine, and adjustable serving scale.

Market positioning:

GTM hypothesis: launch one tightly themed challenge (this iron-and-heart plan) as a shareable, finishable artifact, gather adherence signal, then expand to a library of goal-specific challenges. It is defensible because the value is the curation and the sequencing, and because a femtech and health audience rewards trustworthy, purposeful design over generic recipe volume.

10. What this project demonstrates

• Problem identification: located the real failure point of nutrition advice (the gap between knowing and doing) and built the flow that closes it.
• Trade-off reasoning: chose a sequenced flow over a library, one-at-a-time over a grid, and validated the experience before investing in persistence, while being explicit about the cost.
• Technical fluency: a clean four-state React flow with derived progress, checkable list state, and a clear path to persistence and a content backend.
• Validation discipline: honest that retention is unproven, with persistence named as the gating P1 and nutrition claims flagged for review.
• Roadmap sense: designed a single challenge as the seed of a generalizable challenge engine.
• Communication: a spec that puts the safety boundary first and treats a health context with appropriate care.

Emotional Compass (Name the Feeling)

A quiet check-in app that helps you name what you are feeling with precision, built on an atlas of 88 feelings.

The 30-second version. Most people describe their inner life with three words: happy, sad, stressed. Research on emotional granularity, popularized by Brene Brown's Atlas of the Heart, shows that naming a feeling precisely makes it easier to move through. Emotional Compass turns that idea into a three-step check-in: find the region, narrow the word, mark the moment. Built solo on Lovable.

Live: https://emotional-atlas-guide.lovable.app

Problem

People under stress default to vague labels, and a vague label points to no useful next step. Feeling "bad" could be shame, guilt, envy or grief, and each calls for something different. Journaling apps capture text but do not teach the vocabulary.

Who it is for

Reflective adults who want more self-knowledge, people in therapy who want language between sessions, and anyone who has read Atlas of the Heart and wants to practice it.

How it works

An Atlas page lets users browse all 88 feelings with paraphrased definitions.

Key decisions

• Teach by choosing, not reading. The check-in forces a choice between close words, which builds granularity faster than a glossary.

• Paraphrase, do not copy. Definitions are paraphrased for educational reflection and credit the book.

• Quiet by design. No streaks or scores; the product is a pause, not a game.

Success metrics

Check-ins per user per week, share of check-ins that go past the region to a specific word, and 30-day return rate.

What I would do next

Add a weekly reflection that shows which regions come up most, and test whether naming precision changes self-reported mood.

Lab Insights (LabLens)

Upload a lab report and get plain-language explanations of flagged values, foods to support your body, and questions for your next appointment.

The 30-second version. Patients and caregivers managing chronic illness, chemotherapy or immunotherapy get lab results full of numbers and abbreviations, often before they can talk to a doctor. LabLens reads a photo or PDF of the results, highlights what is out of range, explains each value in plain language, suggests foods to add or avoid, and gives tap-to-copy questions for the care team. Bilingual in English and Spanish. Built solo on Lovable.

Live: https://lab-smart-guide.lovable.app

Problem

Lab portals show results days before the appointment. Caregivers search each abbreviation, find frightening or contradictory answers, and walk into the visit unprepared. Spanish-speaking families face the same problem with even fewer resources.

Who it is for

Caregivers and patients managing chronic illness and cancer treatment, including Spanish-speaking families.

How it works

1. Upload a phone photo, screenshot or PDF, in English or Spanish.

2. Understand a plain-language explanation of every flagged value.

3. Eat with purpose with specific foods to add and avoid, based on the numbers.

4. Ask better with ready questions to copy for the next appointment.

Key decisions

• Prepare, do not diagnose. The output ends in questions for the care team, and every screen says it is informational, not medical advice.

• Bilingual from day one. An EN and ES toggle, because caregiving often happens in a second language.

• Accept messy inputs. Phone photos and screenshots, not only clean PDFs, because that is what caregivers actually have.

Success metrics

Uploads that produce a complete read, questions copied per session, and self-reported preparedness before appointments.

What I would do next

Clinical review of the explanations and food guidance, and a history view to track a value across several reports.

Skin Recipe Genie (Glow DIY)

Describe how your skin looks today and get personalized DIY skincare recipes from simple pantry ingredients.

The 30-second version. Skincare advice is generic and products are expensive, while skin changes day to day. Skin Recipe Genie lets a user describe their skin in their own words, or pick a common state such as "oily T-zone with breakouts" or "red and sensitive after sun", and returns tailored recipes made from kitchen ingredients. Built solo on Lovable with AI-generated recipes and clear safety guidance.

Live: https://skin-recipe-whisperer.lovable.app

Problem

People want simple, natural care for how their skin looks right now, not a 10-step routine. DIY recipes online are not matched to the person and rarely include safety guidance.

How it works

• A free-text box (up to 500 characters) or one-tap examples: dry and flaky cheeks, oily T-zone with breakouts, dull and tired, red and sensitive after sun.

• AI returns personalized recipes using pantry ingredients, matched to the described condition.

Key decisions

• Describe, do not diagnose. Users describe how skin looks today, which keeps the product cosmetic.

• Safety in the flow. Every result carries patch-test guidance and a pointer to a dermatologist for persistent concerns.

• Pantry only. Ingredients people already own lower cost and friction.

Success metrics

Recipes generated per visit, share of users who return to try a second recipe, and self-reported satisfaction.

What I would do next

Saved recipes and an ingredient filter for allergies.

Mood Food Match (Mood Nourish)

Tell it how you feel and get foods, adaptogens and nutrients that support that state, with simple meal ideas, in English and Spanish.

The 30-second version. When people feel tired, anxious or foggy they reach for whatever is closest. Mood Food Match turns a feeling into specific foods rich in the adaptogens, vitamins and nutrients associated with supporting that state, plus easy meal ideas. Ten one-tap moods or free text, bilingual. Built solo on Lovable.

Live: https://moodfoodmatch.lovable.app

Problem

Nutrition advice is organized by nutrient, but people experience their day by mood. There is no quick bridge from "I feel wired but tired" to what to eat next.

How it works

• Pick a mood (tired, anxious, foggy, low energy, stressed, bloated, sad, restless, wired but tired, sore) or describe it in your own words.

• Get foods, the nutrients behind them, and simple meal ideas.

• Toggle English or Spanish.

Key decisions

• Start from the feeling. The input is a mood, not a nutrient, which matches how people think.

• Wellness inspiration, not treatment. Clear "not medical advice" framing.

• Bilingual. Built for Spanish-speaking family members as well as English speakers.

Success metrics

Moods submitted per visit, share of free-text versus one-tap inputs, and return visits within a week.

What I would do next

Save favorite foods and connect to Recipe Health so a mood can lead to a full recipe.

Peace and Pose

Share how you feel and get one yoga pose to meet you there, plus an affirmation to carry with you.

The 30-second version. Yoga apps offer long classes when someone has two minutes and a specific feeling. Peace and Pose asks how you feel right now (anxious, tired, stressed, sad, restless, unmotivated, grateful, overwhelmed) and suggests one pose and one affirmation. A Tai Chi mode offers an alternative practice. Built solo on Lovable.

Live: https://pose-and-peace.lovable.app

Problem

The gap between "I should move" and actually moving is decision fatigue. Choosing a class is harder than doing one pose.

How it works

• One-tap feelings or free text.

• One yoga pose matched to the feeling, with an affirmation.

• A "Prefer Tai Chi?" path for a gentler practice.

Key decisions

• One pose, not a class. The smallest possible action is the one people take.

• Body safety. "Move gently. Skip anything that doesn't feel right in your body."

• Pair movement with words. The affirmation makes the pause emotional as well as physical.

Success metrics

Poses suggested per visit, share of users who request a second pose, and weekly return rate.

What I would do next

Short pose illustrations and a three-pose sequence option.

Tai Chi (Tai Chi para tu animo)

A Spanish-language companion that suggests three Tai Chi postures with clear instructions and an affirmation, matched to how you feel.

The 30-second version. Gentle movement helps with stress and low energy, but most guidance is in English and assumes a class. This Spanish-first app asks "¿Como te sientes ahora mismo?", then suggests a sequence of three Tai Chi postures with clear instructions and a personal affirmation. Built solo on Lovable.

Live: https://mood-to-pose.lovable.app

Problem

Spanish speakers have few simple, at-home movement guides in their language, and a full class is a barrier.

How it works

• Pick a feeling in Spanish (ansioso, cansado, estresado, triste, inquieto, sin motivacion, agradecido, abrumado).

• Get three Tai Chi postures with step-by-step instructions and an affirmation.

Key decisions

• Spanish first, not translated later. Language is the product for this user.

• Three postures. Long enough to feel like practice, short enough to finish.

• Gentle by default. A reminder to skip anything that does not feel right in the body.

Success metrics

Sequences completed and return visits.

What I would do next

Large-text and audio modes.

Yoga Finder (UWS Free Yoga Tracker)

A daily scan of free and intro-offer yoga classes on the Upper West Side, in one list with notifications.

The 30-second version. Free and low-cost yoga in New York exists, but it is scattered across church bulletins, library calendars, park programs, studio intro offers and university listings. Yoga Finder scans those sources every day, sorts results into Free and Intro or discounted, and can notify the user when something new appears. Built solo on Lovable.

Live: https://uws-yoga-finder.lovable.app

Problem

People who want to practice on a budget have to check many small sources by hand, and most listings are posted late or buried in PDFs. The result is that free classes go half empty while people who want them never hear about them.

Who it is for

Upper West Side residents, students and newcomers who want regular yoga without a studio membership.

How it works

Key decisions

• Hyperlocal first. One neighborhood done well beats a city done badly, and it keeps the source list manageable.
• Price is the filter. Free and intro offers are the two categories this user cares about, so they are the main tabs.
• Pull many small sources. The value is in the long tail that general class apps do not list.

Success metrics

New classes found per week, share of listings still accurate on the day, notification opt-in rate and weekly return visits.

What I would do next

Scheduled background scans so the list is never empty on arrival, a map view, and expansion to a second neighborhood.

NYC Event Finder

Every NYC event from Eventbrite, Time Out, Meetup and Partiful in one place, filtered by date, borough, category and price.

The 30-second version. Finding something to do in New York means checking four or five apps that each show a slice of the city. NYC Event Finder pulls events from Eventbrite, Time Out, Meetup and Partiful into one feed, with quick filters for today, this weekend or the next seven days, borough, category and free only. Built solo on Lovable.

Live: https://nyc-events-spy.lovable.app

Problem

Event discovery is fragmented by platform. Each source has its own audience and format, so people miss good events or give up and stay home.

Who it is for

New Yorkers and newcomers who want a quick answer to "what is happening this weekend," especially on a budget.

How it works

• Pick a window: Today, This weekend, Next 7 days, or custom dates.
• Filter by borough (Manhattan, Brooklyn, Queens, Bronx, Staten Island) and category (Music, Food and Drink, Art, Tech, Nightlife, Wellness, Community, Other).
• Toggle Free only.
• Refresh to pull the latest events from all four sources.

Key decisions

• Aggregate, do not host. Each event links back to its source, so the product stays light and current.
• Time first. Most people start with "when," so the date window is the first control.
• Free as a first-class filter. Cost is often the deciding factor in a city this expensive.

Success metrics

Events shown per search, clicks through to a source, share of searches using Free only, and weekly return rate.

What I would do next

Remove duplicates across sources, save favorite categories, and send a weekly digest.

Wisdom Lens (Philosopher in Your Pocket)

Share what is on your mind and see it through five philosophical traditions. Not advice, a way to think.

The 30-second version. Most apps answer "What should I do?" Wisdom Lens answers a different question: "How else could I think about this?" A user writes what is on their mind, and the app reframes it through Stoicism, Buddhism, Existentialism, Taoism and Aristotelian ethics, each with a small practice to try. Built solo on Lovable.

Live: https://pilosopherinyourpocket.lovable.app

Problem

When people are stuck, they tend to hold one interpretation of their situation. Advice apps and chatbots add more instructions, when what helps is a wider view.

Who it is for

Reflective adults working through a decision, a regret or a hard feeling who want perspective, not prescriptions.

How it works

1. Write what is on your mind (up to 800 characters), or tap a starter such as "I feel behind in life" or "Should I quit my job?"
2. Receive five contrasting perspectives, one per tradition.
3. Each perspective ends with a small practice that tradition would recommend.

Key decisions

• Reframe, do not advise. The product never tells the user what to do; the goal is to loosen the grip of a single story.
• Five traditions, side by side. Contrast is the feature; seeing views disagree is what opens thinking.
• Clear boundaries. The app states that it is not advice and not therapy.

Success metrics

Reflections completed, share of users who try a suggested practice, and return visits within two weeks.

What I would do next

Save reflections to a private journal and let users choose which traditions to include.

Wisdom Circle

A second version of Wisdom Lens that answers with a circle of the world's wisdom traditions, each in its own voice.

The 30-second version. Wisdom Circle widens the idea behind Wisdom Lens. A user shares something they are living through and receives a circle of perspectives, from Stoic, Christian and Buddhist to Ubuntu, Existentialist and Indigenous traditions, each written in its own voice. A Wisdom Map shows the traditions together. Built solo on Lovable.

Live: https://wisdomcircle.lovable.app

Problem

Wisdom Lens drew only on five mostly Western and Asian philosophical schools. Many people find meaning in religious, communal and Indigenous traditions that were missing.

Who it is for

People from many cultural and faith backgrounds facing family conflict, career doubt, aging or betrayal who want to feel less alone with it.

How it works

• Describe what you are living through (up to 2,000 characters), or start from a prompt such as "A friend betrayed my trust and asked for forgiveness."
• Open the circle to receive perspectives from many traditions.
• Explore the Wisdom Map to see how the traditions relate.

Key decisions

• Breadth over depth. V2 trades five deep lenses for a wider, more inclusive circle.
• Each tradition in its own voice. Tone matters as much as content when the topic is personal.
• Honest about AI. A note on every result says reflections are AI-generated starting points, not authoritative interpretations.

Success metrics

Circles opened per visit, traditions explored per session, and return use.

What I would do next

Review by scholars or practitioners of each tradition, and let users follow the traditions that resonate most.

Guardians of the Amazon

An interactive pitch deck for blockchain-backed tokens that sponsor real rainforest plots and fund conservation.

The 30-second version. Conservation funding rarely shows donors what their money protects. Guardians of the Amazon proposes tokens that each sponsor a real rainforest plot, paired with NFT art and live satellite imagery, so supporters become Guardians who can watch their forest and vote on how funds are used. The concept is presented as an interactive, web-based pitch deck. Built solo on Lovable.

Live: https://amazon-guardians-token.lovable.app

Problem

Deforestation continues while donors and impact investors lack transparent, ongoing proof that their money reaches the ground.

Who it is for

Climate-minded supporters and impact investors, and the conservation groups and local communities who steward the forest.

How it works

1. Tokenized plots. Each token sponsors a plot from 0.1 to 81 hectares; proceeds fund conservation, reforestation and sustainable livelihoods.
2. NFTs with real ground. Unique art is paired with live satellite imagery of the plot.
3. Low-energy, on-chain governance. A proof-of-stake chain keeps emissions low, and a DAO lets holders direct funds.

Key decisions

• Make impact visible. Satellite imagery turns an abstract donation into a place the supporter can see.
• Interactive deck, not slides. A web deck shows product thinking and is easy to share.
• Governance by holders. A DAO gives Guardians a voice in how funds are allocated.

Success metrics

For the concept: deck completion rate and investor or partner conversations started. For a pilot: hectares sponsored, verified canopy retained and holder participation in votes.

What I would do next

Partner with a verified conservation group and a carbon registry, and pilot with a single protected area.

DevaCup Applicator - PRD

One-line summary: A painless menstrual-cup applicator with a pre-folded chamber, soft iris tip, anatomical angle guide, and depth-stop ring that makes cup insertion confident, comfortable, and repeatable.

Problem

Menstrual cups are sustainable and cost-effective, but a large share of would-be users abandon them because insertion is intimidating, messy, and uncomfortable. Folding the cup by hand is fiddly, the angle and depth are guesswork, and the learning curve drives people back to disposables. There is no purpose-built applicator that removes the fear and mess from the first and every insertion.

Target users

• Primary: People who menstruate and want to switch to or stay with a cup but are deterred by insertion difficulty or discomfort.
• Secondary: First-time cup users (often younger) who need a confidence-building tool to adopt at all.
• Tertiary: People with dexterity limitations or sensitivity who find manual folding impractical.

Goals and Non-goals

Goals

• Make cup insertion painless, clean, and repeatable on the first try.
• Remove the angle and depth guesswork that causes leaks and discomfort.
• Reduce cup abandonment by lowering the learning curve.

Non-goals

• We are not redesigning the cup itself; we make existing-style cups easier to insert.
• We are not making clinical or contraceptive claims.
• We are not targeting removal in v1; the focus is insertion.

Key features

P0 (launch)

• Pre-folded chamber that holds the cup in an insertion-ready fold so the user does not fold by hand.
• Soft iris tip that opens gently to ease entry and minimize discomfort.
• Anatomical angle guide molded into the body to direct correct insertion angle.
• Depth-stop ring that prevents over-insertion and signals correct placement.
• Body-safe, medical-grade materials with a reusable, easy-to-clean design.

P1 (fast follow)

• Size and firmness variants to fit common cup brands and anatomies.
• Travel and storage case with hygienic drying.
• Clear illustrated and video onboarding for first use.
• Single-use sanitary applicator variant for travel or shared facilities.

P2 (later)

• Companion app guidance and reminders (cleaning cadence, sizing help).
• Removal-assist accessory.
• Retail and subscription bundles with compatible cups.

Success metrics

North-star metric: Successful first-try insertion rate among new cup users (self-reported comfortable, leak-free placement on the first attempt).

Supporting metrics

• Cup adoption and 3-month continuation rate among applicator users.
• Reported pain or discomfort scores during insertion.
• Net Promoter Score and repeat purchase or reorder of consumable parts.
• Return and defect rates.

Key risks and mitigations

• Safety and regulatory: an insertion device for an intimate area carries compliance obligations. Mitigate with medical-grade materials, biocompatibility testing, and appropriate regulatory pathway review before launch.
• Anatomical variability: one geometry will not fit everyone. Mitigate with size and firmness variants and an adjustable depth-stop.
• Cup compatibility: cups vary in size and shape. Mitigate by designing to common dimensions first and publishing a clear compatibility list.
• User trust and education: people fear getting it wrong. Mitigate with strong onboarding, illustrated guidance, and a reassuring depth and angle feedback design.

Phased rollout

• Phase 1 (Months 1 to 4): Prototype and validation: build functional prototypes, run usability and comfort testing with a recruited panel, and confirm material safety and the regulatory pathway.
• Phase 2 (Months 5 to 8): Pilot production: manufacture a limited run in one or two sizes, launch a small direct-to-consumer cohort, and measure first-try success and continuation.
• Phase 3 (Months 9 to 14): Scale: add size and firmness variants, travel case, and onboarding content, then expand distribution and explore cup bundles, optimizing for first-try insertion success.

Vela - PRD

One-line summary: Discreet personal-safety jewelry with hidden GPS and a one-touch panic signal, so wearers can call for help without anyone seeing a device.

Problem

People who feel unsafe walking home, on dates, commuting late, or traveling alone want a way to signal for help that is instant and invisible. Phones are slow to reach in a crisis, obvious safety devices can escalate a threat, and existing wearables look clinical or unappealing. There is no everyday-wearable that looks like jewelry, blends in, and silently sends location and an alert when it matters.

Target users

• Primary: Women and other safety-conscious adults who navigate solo situations (commuting, dating, nightlife, travel) and want discreet protection.
• Secondary: Caregivers and family members buying for loved ones (students, older relatives).
• Tertiary: Lone or field workers who want a low-profile duress signal.

Goals and Non-goals

Goals

• Let a wearer trigger a help signal instantly and discreetly.
• Deliver accurate location to chosen contacts or a monitoring service.
• Make the device attractive enough to wear every day.

Non-goals

• We are not a replacement for emergency services or a security guarantee.
• We are not building continuous always-on tracking that compromises wearer privacy.
• We are not launching a full medical-alert clinical product in v1.

Key features

P0 (launch)

• One-touch (or press-and-hold) panic trigger built discreetly into the jewelry.
• Hidden GPS that captures and transmits the wearer's location on trigger.
• Alert dispatch to pre-set trusted contacts with location and a help message.
• Companion app for setup, contact management, and alert history.
• Rechargeable battery with multi-day life and a low-battery reminder.

P1 (fast follow)

• Live location sharing for a session (walking home) with auto-stop.
• Discreet check-in and "I'm safe" cancel to reduce false alarms.
• Multiple form factors (necklace, bracelet, ring) on shared internals.
• Audible or haptic confirmation that the alert was sent.

P2 (later)

• Optional 24/7 professional monitoring and emergency dispatch subscription.
• Fall or inactivity detection for at-risk wearers.
• Two-way communication and an in-app safety network of nearby trusted contacts.

Success metrics

North-star metric: Successful alert deliveries (a triggered alert that reaches at least one contact with accurate location), reflecting the product doing its core job when needed.

Supporting metrics

• Daily wear rate (percentage of owners wearing it on a given day).
• Trigger-to-delivery latency and location accuracy.
• False-alarm rate and cancel-success rate.
• Battery satisfaction and charge adherence.

Key risks and mitigations

• False alarms: accidental triggers erode trust and annoy contacts. Mitigate with a deliberate trigger gesture, a brief cancel window, and clear confirmation feedback.
• Reliability when it matters most: a failed alert is catastrophic. Mitigate with redundant connectivity, delivery confirmations, and rigorous field testing.
• Privacy: hidden GPS raises legitimate concerns. Mitigate by making location capture trigger-based by default, encrypting data, and giving the wearer full control over sharing.
• Wearability versus tech: beautiful jewelry constrains electronics. Mitigate with a modular internals platform across multiple designs and careful industrial design tradeoffs.

Phased rollout

• Phase 1 (Months 1 to 5): Prototype and trust testing: validate the trigger, GPS accuracy, and alert delivery in hardware prototypes; test the cancel flow to drive down false alarms.
• Phase 2 (Months 6 to 10): Limited launch: ship one or two flagship designs to an early cohort, prove daily wear and successful alert delivery, and refine battery life.
• Phase 3 (Months 11 to 18): Expand and monetize: add live session sharing, more form factors, and an optional professional monitoring subscription, optimizing for successful alert deliveries and daily wear.

Kindred

Dating rebuilt on taste, not on swiping.

The 30-second version. Kindred is a consent-first dating concept that matches people on revealed cultural behavior (the music they return to, the films and writers they share, the causes they show up for, the people they already have in common) instead of on a self-reported profile. Built as a concept landing page and interaction model, not a live app, to pressure-test one bet: that taste is a more honest and durable compatibility signal than another personality quiz. The PM work on display here is problem framing in a crowded, profitable, but deeply unhappy market, a regulatory and AI timing thesis, and an honest enumeration of the riskiest assumptions before a line of production code gets written. This is a concept, distinct from the live "Kindred Spirits" dating app.

---

Timeline: Weekend concept artifact, in early validation.

---

1. Problem statement

The swipe era is collapsing under its own weight. A decade of swiping trained people to treat each other as interchangeable, and the result is mass burnout and a slow exodus even as the apps keep printing money. Published 2025 to 2026 industry research points the same direction: a large share of dating-app users report burnout (highest among Gen Z), only a small minority ever find a long-term relationship through an app, and roughly half of users distrust how their data is handled. People are not done with dating. They are done with how it feels.

The market gap is structural, not cosmetic. Every incumbent asks you to self-report who you are, so you write a profile that is aspirational, edited, and a little dishonest, and then you are matched on fiction. The archetypes:

Kindred's wager is that there is room for a fourth approach: match on revealed behavior, the cultural fingerprint people already leave online, read with permission rather than scraped.

2. Goals and non-goals

Goals

• (User) Replace performance with recognition: make the first thing you learn about someone what moves them, not how they angled a camera.
• (User) Reduce dating burnout by surfacing a small, curated set of high-resonance introductions rather than an infinite stack.
• (User) Make privacy the product: every user sees, approves, and controls their own taste fingerprint before anyone else sees a thing.
• (Business) Validate that resonance-led introductions convert to real dates at a higher rate than swipe-led ones.
• (Business) Prove that consent-based "bring your data" onboarding is acceptable enough to a real cohort to be a durable acquisition pipeline.

Non-goals

• Not a faster swipe. We are not optimizing the existing swipe loop, because the loop itself is the problem.
• Not a personality quiz. We will not add another self-report questionnaire, because self-report is the signal we are explicitly trying to replace.
• Not a global launch. We will not chase broad geographic coverage at the start, because match quality depends on local liquidity and a real shared graph.
• Not a data broker. We will never sell or repurpose user data, because in a market where roughly half of users distrust data handling, consent is the differentiator, not a feature to monetize.
• Not a claim that taste predicts chemistry. We are not asserting a compatibility "score"; we treat taste as a high-quality filter and conversation starter, not a magic match guarantee.

3. The product

Kindred reads the cultural fingerprint a person already leaves online, with explicit permission, distills it into a private taste profile the user controls, and uses it to make a few high-resonance introductions each week. The core mechanic is consent-first by design: the user owns the data, Kindred reads the signal.

The trust layer is the social graph. "You have 3 people in common" is social proof a cold-stranger app cannot offer, and it makes a first conversation warmer and safer.

4. User stories

Burned-out dater (primary persona)

• As a Gen Z dater exhausted by swiping, I want to receive a few introductions with a real reason behind each, so that I stop treating people as interchangeable and actually go on dates.
• As someone who is bad at writing a dating bio, I want to be matched on what I genuinely return to (my music, my films, my causes), so that I am represented honestly rather than aspirationally.

Privacy-conscious user

• As a user who distrusts how dating apps handle data, I want to see, edit, and approve my taste fingerprint before anyone else sees it, so that I stay in control of what is shared.
• As a user, I want a clear guarantee that my data is never sold or used without consent, so that connecting an account feels safe rather than risky.

Edge and empty states

• As a new user in a city with too few members, I want Kindred to tell me honestly that the network is still thin here and offer to notify me when it is ready, so that I am not handed low-quality matches that erode my trust.
• As a user who connects only one sparse account, I want a graceful low-data state that still produces a usable (if smaller) fingerprint and tells me what connecting more would unlock, so that onboarding does not dead-end.

5. Requirements

Must-have (P0)

• Consent-first account connection through official, permission-based integrations (no scraping).
  • Given a user wants to connect a source, when they authorize it, then Kindred ingests only the granted data through the official connection and records the consent scope.
• A user-reviewable, user-editable taste fingerprint that is private until the user approves it.
  • Given a fingerprint has been generated, when the user opens it, then they can see every inferred dimension, edit or remove any of it, and nothing is visible to others until they approve.
• A curated, limited weekly introduction set (not an infinite stack), each with a stated reason and shared mutuals.
  • Given a user is active, when the weekly batch runs, then they receive a small set of introductions, each annotated with the specific shared signal and mutual connections.
• An explicit, enforced data-use guarantee (never sold, never used without consent).

Nice-to-have (P1)

• Deeper fingerprint controls (tune weighting across music, values, humor, graph).
• "See who resonates with you" reciprocity view.
• Priority introductions and richer match context for paid users.

Future (P2)

• Human-assisted concierge matchmaking tier (curated, vetted introductions).
• Expansion across cities once per-city liquidity thresholds are met.
• Group and community-seeded introductions that lean on the shared graph.

6. Key product decisions and trade-offs

Decision: Match on revealed behavior, not self-report. Alternatives considered: another personality quiz (rejected, it reproduces the exact aspirational-fiction problem we are trying to kill); photo-first swiping (rejected, it is the burnout engine). Why this won: revealed taste is a richer, more honest signal and doubles as a built-in conversation, not a checklist.

Decision: Consent-first ingestion instead of scraping. Alternatives considered: scraping public profiles (rejected, legally fragile and a trust violation in a market where half of users already distrust data handling); manual taste entry (rejected, high friction and low signal). Why this won: new EU data-portability rules now require major platforms to let people grant apps real-time access to their own data, which for the first time makes consent-based "bring your data" a durable pipeline rather than a hack. The honest cost: this adds real onboarding friction, and willingness to connect accounts is one of our top open risks (see section 8).

Decision: A few curated introductions per week, not an infinite stack. Alternatives considered: the standard endless feed (rejected, it optimizes time-on-app at the expense of the user's actual goal). Why this won: the product should win when a user leaves to go on a date, not when they stay scrolling. The unflattering trade-off: this caps engagement metrics and session counts that investors are used to seeing, so we are deliberately choosing a harder growth story in exchange for a healthier one.

Decision: Subscription, not ad-supported or pay-per-match. Alternatives considered: ad-supported (rejected, it re-introduces the attention-maximizing incentive we are trying to escape); pay-per-introduction (rejected, it nickel-and-dimes the user and distorts behavior). Why this won: a subscription aligned with actually meeting people keeps incentives pointed at outcomes, and premium matchmaking is the fastest-growing slice of the market.

Decision: Narrow, single-city, single-community launch. Alternatives considered: broad launch (rejected, match quality collapses without local density). Why this won: mutual connections have to be real from day one, which is only possible where the graph is dense. The trade-off is a slower, smaller start.

7. UX

The concept landing page sets the interaction language: warm, editorial, and calm, the opposite of a slot-machine feed. Fraunces serif headlines, a clay-and-bone palette, and a subtle grain texture signal "considered" rather than "addictive."

• Two people rendered as nodes joined by an overlapping "resonance" field, with floating taste tags (indie folk, climate work, slow travel, A24 films, salsa) and a "3 mutuals" badge. The visual argues the thesis before any copy does: you meet through what you share.
• A side-by-side "Old way vs Kindred" table that turns vague self-report ("I love travel and good vibes") into revealed behavior ("Saves trips to Oaxaca, Lisbon, Kyoto. Follows three slow-travel writers."). This is the clearest single artifact of the product's premise.
• A three-step flow (Connect what you choose, Build your fingerprint, Meet a few who resonate) that foregrounds consent and review at every stage.
• An honest "open questions" section, on the page itself, naming the riskiest assumptions. Putting the risks in the marketing is itself a design decision: it sets the trust tone the product depends on.

The interaction principle throughout: depth over volume. Every screen is built to feel like recognition, not a quota.

8. How I would validate this

Because Kindred is a concept, the section below is a validation plan, not a record of results. Each hypothesis is paired with the experiment that would test it. All actuals are placeholders to be populated after validation.

Leading indicators (adoption, activation, completion)

• Waitlist conversion from the concept page: target [X%] of visitors who join early access. Method: landing-page analytics on the existing concept artifact.
• Account-connection rate during onboarding: target [X%] of signups who connect at least one real source. Method: instrumented onboarding in a v1 prototype. This is the make-or-break activation metric, because consent-first onboarding is the model's biggest friction point.
• Fingerprint approval rate: target [X%] of users who review and approve their generated fingerprint without abandoning. Method: prototype funnel.

Lagging indicators (retention, conversion to dates, satisfaction)

• Introduction-to-date conversion: target that resonance-led introductions convert to real dates at a measurably higher rate than a swipe-led control. Method: a held-out comparison once there is liquidity in one city. This is the central thesis test.
• Paid conversion to Kindred Plus: target [X%] within the first cohort. Method: subscription analytics.
• Member-reported "this felt different / better" satisfaction: target [X]. Method: post-intro surveys.

The three riskiest assumptions, stated plainly (carried from the concept page)

1. Signal. Does taste similarity actually predict chemistry? Relationship science is skeptical that similarity-matching beats chance, so we deliberately frame taste as a high-quality filter and conversation starter, and we measure conversion-to-date against a control rather than claiming a compatibility score.
2. Access. Will people connect their accounts? The consent-first model is cleaner than scraping but adds friction, and willingness to link a music account or photo library in exchange for fewer, better introductions is unproven.
3. Cold start. Can we seed enough density to matter? Match quality needs liquidity in a city and a real graph, which is why launch is narrow by design.

What didn't work, and what I'd change. The concept page leans on a single, contestable assumption (taste predicts chemistry) that relationship science does not clearly support, and an earlier framing oversold it as a compatibility engine. The honest reframe is that Kindred's defensible claim is "a more honest, less exhausting way to meet," not "a better predictor of love," and the validation plan above is built around proving the former, not the latter. If I rebuilt the page today, I would lead with the burnout-and-consent story (which is well-evidenced) and treat the chemistry claim as an open question to be tested, not a promise. I would also be wary of the cited industry statistics: they are illustrative third-party figures, not Kindred's own data, and should never be presented as validation.

9. Open questions and roadmap

Open questions

• Does similarity-led matching beat a swipe-led control on conversion-to-date? (Owner: data) This is the thesis.
• What is the minimum number of connectable sources that produces a fingerprint users find accurate? (Owner: data + design)
• Will users actually grant the integrations, and which one is the lowest-friction first connection? (Owner: design + user research)
• What is the legal and compliance footprint of consent-based data portability across jurisdictions? (Owner: legal)
• What density (members and graph overlap) does a single city need before introductions feel high quality? (Owner: data)

Path to a buildable v1 A single-city, single-community pilot with one or two connectable sources, a manually reviewable fingerprint, and a weekly batch of curated introductions. Success is defined as a measurable lift in introduction-to-date conversion over a swipe-led control, not raw engagement.

Market positioning

GTM hypothesis. Launch where the graph is dense (one city, one community), let the "3 mutuals" trust signal drive word of mouth, and convert burned-out swipers who want depth. Defensibility comes from the consent-based data relationship and the network effects of a real shared graph, both of which compound and neither of which a cold-stranger swipe app can replicate.

10. What this project demonstrates

• Problem identification: reframes a profitable but unhappy market around the right unit of analysis (the matching signal itself), not surface features.
• Trade-off reasoning: deliberately accepts lower engagement metrics and slower geographic growth in exchange for healthier incentives and trust, and says so out loud.
• Technical fluency: grounds the model in a concrete, current enabler (EU data-portability rules plus cheap-enough AInference) rather than hand-waving.
• Validation discipline: separates a well-evidenced claim (burnout, consent demand) from a contestable one (taste predicts chemistry) and builds the test plan around proving the contestable claim with a control, not asserting it.
• Roadmap sense: sequences a narrow, density-first pilot before expansion, because the product literally does not work without local liquidity.
• Communication: puts the riskiest assumptions on the marketing page itself, demonstrating that trust is treated as the product, not as copy.

The Monthly - PRD

One-line summary: A period-care subscription box timed to each subscriber's cycle, shipping the right pads plus chocolates and rotating self-care items so support arrives exactly when it is needed.

Problem

Period care is predictable yet poorly served. People run out of supplies at the worst moment, generic subscription boxes ignore the actual timing of the cycle, and the experience feels transactional rather than caring. There is no offering that lands the right products in the right week, paired with the comfort items (chocolate, self-care) that make a tough few days a little better.

Target users

• Primary: People who menstruate, ages 16 to 40, who want reliable, well-timed supplies plus a bit of comfort and are open to subscriptions.
• Secondary: Gift buyers (partners, parents, friends) wanting a thoughtful recurring gift.
• Tertiary: People with predictable cycles who value convenience and surprise-and-delight.

Goals and Non-goals

Goals

• Deliver the right supplies timed to arrive before each subscriber's period.
• Pair essentials with comfort and self-care to make the box feel caring.
• Build a sticky, low-churn subscription through reliability and delight.

Non-goals

• We are not offering medical or contraceptive advice or products.
• We are not building a full cycle-tracking health platform; timing is a means, not the product.
• We are not committing to fully custom product mixes at launch.

Key features

P0 (launch)

• Cycle-timed shipping: subscriber sets cycle start and length, and boxes are scheduled to arrive a few days before each period.
• Core supplies: pads in selected absorbencies and counts.
• Comfort add-ins: chocolates and a rotating self-care item each month.
• Simple subscription management (skip, pause, adjust date, cancel).
• Preference setup for absorbency, quantity, and dietary or allergy notes.

P1 (fast follow)

• Cycle-length learning and adjustment based on feedback to improve timing accuracy.
• Expanded product choices (tampons, liners, organic options).
• Gift subscriptions with a personalized note and recipient setup.
• Customizable self-care preferences (tea, skincare, comfort items).

P2 (later)

• Tiered boxes (essentials versus deluxe self-care).
• Cycle reminders and light companion content.
• Bundled one-off restock store for between-box needs.

Success metrics

North-star metric: Active subscribers retained past 3 cycles (subscribers who keep receiving boxes through at least their third delivery, indicating the timing and contents deliver real value).

Supporting metrics

• On-time delivery accuracy (box arrives before the period starts).
• Monthly churn and average subscription lifespan.
• Self-care item satisfaction and box rating per shipment.
• Skip-and-pause versus cancel ratio, and gift conversion.

Key risks and mitigations

• Timing accuracy: cycle variability can make boxes arrive late. Mitigate with conservative lead times, easy date adjustment, and cycle-length learning over time.
• Subscription fatigue: boxes can feel repetitive or like clutter. Mitigate with rotating, genuinely useful self-care items and easy skip and pause to prevent unwanted shipments.
• Unit economics: shipping plus comfort items can squeeze margins. Mitigate with sensible box composition, tiered pricing, and supplier negotiation as volume grows.
• Supply and fulfillment reliability: stockouts break the core promise. Mitigate with buffer inventory on essentials and a vetted fulfillment partner.

Phased rollout

• Phase 1 (Weeks 1 to 6): MVP subscription: cycle-timed scheduling, core pads, chocolates, and one rotating self-care item, with basic subscription management. Launch to a waitlist cohort.
• Phase 2 (Weeks 7 to 14): Personalization: add cycle-length learning, expanded product choices, and customizable self-care preferences. Tune timing accuracy and box ratings.
• Phase 3 (Weeks 15 to 26): Growth and tiers: introduce gift subscriptions, tiered boxes, and a restock store, optimizing for subscribers retained past 3 cycles.

Pivot - PRD

One-line summary: A foot-pedal, touch-free toilet seat that lifts and lowers via a floor pedal, ending the seat-up-or-down standoff and keeping hands off a high-touch surface.

Problem

The toilet seat is a daily friction point in shared bathrooms: arguments over leaving it up or down, and a real hygiene concern because the seat is a high-touch surface people would rather not handle. Existing solutions are either expensive smart toilets, flimsy aftermarket gadgets, or motorized seats that are costly and failure-prone. There is no simple, durable, mechanical way to raise and lower the seat without touching it.

Target users

• Primary: Households with shared bathrooms who want to end the seat dispute and reduce touchpoints, especially mixed-gender homes and families with kids.
• Secondary: Hygiene-conscious individuals and people with germ sensitivities.
• Tertiary: Small commercial and semi-public restrooms (offices, cafes) wanting low-maintenance touch-free fixtures.

Goals and Non-goals

Goals

• Let anyone raise and lower the seat hands-free with a foot pedal.
• Deliver a durable, mechanical solution that needs no power or app.
• Fit standard toilets with a straightforward install.

Non-goals

• We are not building a smart toilet, bidet, or electronics-laden seat in v1.
• We are not motorizing the lid; the mechanism is mechanical and user-driven.
• We are not targeting custom or non-standard toilet geometries initially.

Key features

P0 (launch)

• Foot pedal mounted at the floor that mechanically raises and lowers the seat (and optionally lid).
• Smooth, controlled motion with a soft-close return to prevent slamming.
• Fits standard round and elongated toilet bowls with included hardware.
• Tool-light installation that a typical homeowner can complete.
• Durable, water-resistant, easy-to-clean materials rated for daily use.

P1 (fast follow)

• Adjustable pedal placement and cable or linkage length for varied bathroom layouts.
• Lid-and-seat combined lift option.
• Color and finish variants to match common fixtures.
• Replaceable wear parts and a simple maintenance kit.

P2 (later)

• Commercial-grade variant for higher-traffic restrooms.
• Antimicrobial seat surface option.
• Compatibility kits for non-standard bowls.

Success metrics

North-star metric: Active daily pedal uses per installed unit (households actually using the hands-free mechanism day to day rather than reverting to hand operation).

Supporting metrics

• Successful self-install rate and median install time.
• Mechanism reliability (cycles to failure) and warranty claim rate.
• Customer satisfaction and Net Promoter Score.
• Return rate and repeat or referral purchases.

Key risks and mitigations

• Mechanical durability: a bathroom mechanism cycled thousands of times must not fail. Mitigate with corrosion-resistant materials, high-cycle testing, and replaceable wear parts.
• Install friction: a hard install kills adoption and drives returns. Mitigate with universal-fit hardware, clear instructions, and a fit-check guide before purchase.
• Aesthetics and footprint: a visible pedal and linkage may feel intrusive. Mitigate with discreet, low-profile industrial design and finish options.
• Fit variability: toilets vary in size and shape. Mitigate by designing to standard round and elongated bowls first and publishing clear compatibility guidance.

Phased rollout

• Phase 1 (Months 1 to 4): Prototype and durability: build working prototypes, run high-cycle reliability and soft-close testing, and validate fit on common standard bowls.
• Phase 2 (Months 5 to 8): Pilot launch: small production run for standard bowls, direct-to-consumer launch, and measurement of self-install success and daily use.
• Phase 3 (Months 9 to 15): Expand: add adjustable layouts, finishes, lid-lift option, and a commercial-grade variant, optimizing for active daily pedal use per unit.

Verda

A closet that protects what you wear.

The 30-second version. Verda is a consumer-hardware concept: a wardrobe system with a built-in dehumidifier that holds your clothes at the ideal 45 to 55% relative humidity, so leather does not crack, knits do not mildew, and your best pieces last for years. It treats the closet as a small sealed microclimate (the same idea proven in the dry cabinets that protect camera gear in the tropics) rather than fighting the whole room with a portable unit in the corner. Built as a concept landing page and a reserve-driven demand test, not a shipped product. The PM work here is hardware scoping (a buildable bill of materials and a three-SKU line), a demand-validation mechanism (refundable reservations gated on a real threshold), and honest non-goals about what the first build will and will not do.

---

Timeline: Weekend concept artifact, in demand validation.

---

1. Problem statement

In humid climates and tight city apartments, your closet is quietly ruining your clothes. Ambient moisture sits inside the closet and goes to work: mildew on cotton, white bloom on leather, musty knits, warped shoes, corroded hardware. In tropical and coastal homes, closets can sit at 70 to 85% relative humidity for months, well above the roughly 50% ceiling that keeps fabrics safe. The damage is slow, invisible, and expensive, and it adds up to thousands of dollars of suits, bags, and coats degraded every rainy season.

Existing solutions miss where the damage happens:

The market gap: nobody has scaled the proven dry-cabinet approach up to a wardrobe and finished it like furniture.

2. Goals and non-goals

Goals

• (User) Hold the closet interior at 45 to 55% relative humidity automatically, dry enough to stop mold but never so dry that leather cracks.
• (User) Make protection effortless: no tanks to empty, no dials to babysit, set it and forget it.
• (User) Protect the specific pieces worth protecting (leather, wool, silk, suede, sneakers) for the long run.
• (Business) Validate real purchase intent through refundable reservations before committing capital to a production run.
• (Business) Define a bill of materials and a SKU line buildable with off-the-shelf-adjacent parts, so the first prototype is fast and provable.

Non-goals

• Not a whole-room HVAC system. We regulate one sealed cabinet, not the apartment, because the closet is where the damage happens and a sealed volume is far cheaper to control precisely.
• Not a maximum-drying box. We regulate to a band, not zero humidity, because over-drying cracks leather and embrittles fibers.
• Not a connected-everything smart-home play in v1. The companion app does setpoint, logging, and drift alerts, nothing more, because feature creep delays a hardware build that has to prove the core climate claim first.
• Not a custom-geometry product at launch. We ship defined SKUs, because bespoke closets multiply manufacturing complexity before demand is proven.
• Not built before demand exists. We do not manufacture until reservations clear a real threshold, because building hardware on a hunch is how hardware startups die.

3. The product

Verda is a wardrobe and a microclimate in one. It does not try to dry the room; it treats the closet as a small, sealed environment and quietly regulates it, the same approach proven in tropical camera dry cabinets, scaled up to a wardrobe and finished like furniture.

The line is one system in three forms: The Drop-In (a module that integrates into custom California-style millwork for renovators), The Wardrobe (a sealed, self-contained, plug-and-play piece for apartments and renters, the most popular configuration), and The Walk-In (zoned, ducted, whole-room control with a dedicated vault for the most precious pieces).

4. User stories

Humid-climate homeowner (primary persona)

• As someone living in Singapore, Miami, or Mumbai, I want my closet held at a safe humidity automatically, so that my leather jackets and wool coats stop growing mold and musty smells every rainy season.
• As an owner of expensive pieces, I want a system that protects bags and silk specifically, so that the items worth thousands do not degrade invisibly.

Apartment renter

• As a renter who cannot renovate, I want a sealed, plug-and-play wardrobe with no plumbing or installation, so that I get climate protection without touching the building.

Set-it-and-forget-it user

• As a busy person, I want fully automatic operation with no tank to empty and no dial to babysit, so that protection requires zero ongoing effort.

Edge and error states

• As a user, I want a drift alert when a zone leaves the safe band, so that I find out before damage starts rather than after.
• As a user in a power outage or with a full water tray, I want a clear, non-silent failure state (an alert and a graceful hold), so that I am never falsely reassured that my clothes are protected when they are not.

5. Requirements

Must-have (P0)

• Hold the sealed closet interior at 45 to 55% RH automatically.
  • Given the cabinet is sealed and powered, when interior humidity rises above the band, then the dehumidifier engages and returns the interior to setpoint without manual input.
• Continuous interior sensing, not room sensing, with dual-zone coverage (main bay and vault).
  • Given the system is running, when humidity is read, then it is measured inside the cabinet in each zone, not in the room.
• Even airflow so no damp pockets form (perforated back plenum plus circulation fans).
• Whisper-quiet operation suitable for a bedroom.
• Water handling with no bucket to empty (self-evaporating tray, optional gravity drain).
• A failure/drift alert so the user is never silently unprotected.
  • Given a zone leaves the safe band or a fault occurs, when the condition persists, then the user receives an alert rather than a silent failure.

Nice-to-have (P1)

• Companion app with humidity logging, trend history, and remote alerts.
• A cedar vault liner: a naturally moisture- and moth-resistant zone for bags and silk.
• Multiple finishes to match furniture.

Future (P2)

• The Walk-In flagship: zoned, ducted, whole-room control.
• Smart-home integrations beyond the standalone app.
• Higher-capacity hybrid engine for large walk-in volumes.

6. Key product decisions and trade-offs

Decision: Seal and regulate the closet, do not dry the room. Alternatives considered: a better portable room dehumidifier (rejected, it never reaches inside the closet, runs loud, and holds no precise band); passive desiccant (rejected, tiny capacity, no regulation, no feedback). Why this won: a sealed volume is dramatically cheaper and more precise to control than a room, and the approach is already proven in camera dry cabinets. The trade-off: it requires gasketed doors and a genuinely sealed enclosure, which raises cabinet build cost versus a plastic box.

Decision: Regulate to a 45 to 55% band, not maximum drying. Alternatives considered: drive humidity as low as possible (rejected, it cracks leather and embrittles fibers). Why this won: the goal is protection, not desiccation, and the band stops mold while keeping leather supple. This is the most common misconception the FAQ has to address, so it is a deliberate, stated design constraint.

Decision: A three-SKU line (Drop-In, Wardrobe, Walk-In) instead of one product. Alternatives considered: a single flagship (rejected, it ignores that renters cannot install and renovators want millwork integration); fully bespoke (rejected, it multiplies manufacturing complexity before demand is proven). Why this won: three defined SKUs cover the three real living situations while keeping manufacturing bounded. The lead SKU, The Wardrobe, is deliberately the no-installation, no-plumbing unit because it has the widest addressable audience.

Decision: Build the prototype from off-the-shelf-adjacent parts. Alternatives considered: custom-engineered compressor and enclosure from scratch (rejected, slow and capital-heavy before the climate claim is even proven). Why this won: a thermoelectric or desiccant module, standard humidistats, whisper-grade fans, and a gasketed shell make the first build fast and provable. The honest trade-off: thermoelectric modules are quiet and compressor-free but have limited capacity, which is exactly why the large Walk-In is deferred to a higher-capacity hybrid engine rather than promised in v1.

Decision: Gate manufacturing on a real reservation threshold (500 refundable reservations). Alternatives considered: build first and sell later (rejected, the classic hardware failure mode); pure email waitlist (rejected, a free email is weak signal). Why this won: a refundable reservation is a stronger intent signal than an email but a lower barrier than a full pre-order, and a public threshold creates honest accountability. The unflattering trade-off: a low-friction refundable reservation still overstates true purchase intent, so it must be read as directional demand, not as committed revenue (see section 8).

7. UX

The concept renders position Verda as furniture first and appliance second: the visual language is editorial and warm (Newsreader serif, a bone-and-emerald palette, a cedar accent), deliberately the opposite of a utilitarian gray dehumidifier.

• [Screenshot: verda-open.png] The freestanding wardrobe with both doors open, showing the wardrobe as a finished, furniture-grade piece rather than an appliance. This is the core "California Closets, smart like an appliance" positioning shot.
• [Screenshot: verda-humidity.png] A close-up of the slim glowing digital humidity readout inside the cabinet, making the invisible benefit (a held 50% RH) visible and tangible.
• [Screenshot: Hero readout strip] Three at-a-glance proof points: "45 to 55% target humidity," "24/7 silent monitoring," "0 mildew, ever."
• [Screenshot: How-it-works] A Sense, Regulate, Protect three-step that explains the sealed-microclimate idea without engineering jargon.
• [Screenshot: System cutaway / architecture] A labeled cutaway (cabinet body, sealed interior, cedar vault, control panel showing "50% RH HOLD," base dehumidifier module, airflow arrows) and a Sense, Regulate, hold loop diagram that make the engineering credible to a skeptical buyer.
• [Screenshot: Reserve section] A reservation counter ("312 / 500 reserved") with a refundable $1 hold, making the demand test itself part of the page.

The interaction principle: make an invisible, slow-moving problem feel concrete and a technical solution feel like beautiful furniture.

8. How I would validate this

Because Verda is a hardware concept with no manufactured unit, this is a validation plan, not a record of results. All actuals are placeholders to be populated after validation.

Leading indicators (demand, intent)

• Reservation rate against the public goal: target [X] of 500 refundable reservations within [X weeks]. Method: the reservation counter on the concept page. This is the primary go/no-go signal for committing to a build.
• SKU preference split (Drop-In vs Wardrobe vs Walk-In): target a clear lead SKU to focus the first build. Method: the reservation form's SKU question.
• Geographic concentration of reservations (which cities feel the humidity pain most): Method: the reservation form's city field, used to choose a launch market.

Lagging indicators (build performance, satisfaction)

• Prototype climate performance: target holding 45 to 55% RH in a sealed reach-in across a defined ambient range, whisper-quiet. Method: an instrumented bench prototype. This is the make-or-break engineering proof.
• Reservation-to-purchase conversion once the unit is real: target [X%]. Method: convert reservation-holders at founder pricing and measure follow-through.
• Owner-reported protection satisfaction and "would recommend": target [X]. Method: post-install survey.

What didn't work, and what I'd change. The reservation mechanism is the right instinct but a weak proxy if read literally: a refundable $1 hold (or a free name on a list, in the longer page variant) captures curiosity as much as commitment, so the honest read is directional interest, not committed revenue. The two landing-page variants also tell slightly inconsistent stories (one frames a polished consumer product with a "Reserve for $1" hook, the other a build-it-if-500-want-it crowd-validation with a richer bill of materials and FAQ), and a real test should pick one narrative and one price point so the signal is clean. The hardest unvalidated assumption is engineering, not demand: thermoelectric dehumidification is quiet and compressor-free but capacity-limited, and whether it can hold the band in a large or frequently-opened closet is unproven. If I rebuilt this, I would lead the validation with a bench prototype that proves the climate claim in parallel with the demand test, rather than letting an attractive landing page imply a capability that has not yet been built. The displayed "312 / 500 reserved" figure is illustrative placeholder copy, not a measured count, and must never be presented as real traction.

9. Open questions and roadmap

Open questions

• Can a quiet thermoelectric or desiccant module actually hold 45 to 55% RH in a real wardrobe volume, including a frequently-opened or large closet? (Owner: eng) This is the central technical risk.
• What is the bill-of-materials cost and resulting retail price, and at what price does demand hold? (Owner: eng + finance)
• Which SKU and which launch city do reservations point to? (Owner: data)
• How is condensate handled across renter installs with no drain access, at scale and reliably? (Owner: eng)
• What is the energy draw, and does heat venting create any real conflict with home AC? (Owner: eng)

Path to a buildable v1 Build the lead SKU first (likely The Wardrobe: sealed, plug-and-play, no plumbing) from the defined bill of materials: a thermoelectric dehumidifier module, dual-zone humidistat and temperature sensors, a whisper-grade circulation fan array, a gasketed cabinet shell, a perforated back plenum, a control board with companion app, a cedar vault liner, and a self-evaporating tray with optional drain. Gate the production run on clearing the reservation threshold, and prove the climate claim on a bench prototype in parallel.

Market positioning. Verda sits between premium closet systems (California Closets, furniture-grade but climate-dumb) and appliances (room dehumidifiers, functional but ugly and imprecise). The wedge is "built like California Closets, smart like an appliance." Defensibility comes from being the first to package proven dry-cabinet climate control as furniture-grade wardrobe, plus the design, finish, and SKU breadth that a generic appliance maker would not invest in.

GTM hypothesis. Start in the highest-humidity, highest-disposable-income markets (Singapore, Miami, Mumbai, coastal cities), convert reservation-holders at founder pricing, and let the protection of expensive pieces (the "it pays for itself" argument) drive word of mouth among people who have already lost a jacket to humidity.

10. What this project demonstrates

• Problem identification: locates an invisible, slow, expensive problem (interior closet humidity) that adjacent products consistently miss because they treat the room, not the cabinet.
• Trade-off reasoning: picks a sealed-volume thermoelectric approach with eyes open about its capacity limits, and defers the large Walk-In rather than overpromising.
• Technical fluency: translates the concept into a concrete, buildable bill of materials and a coherent sense, regulate, distribute, protect architecture borrowed from proven camera dry cabinets.
• Validation discipline: designs a demand gate (refundable reservations against a public threshold) and is honest that it overstates intent, while naming engineering, not demand, as the riskiest assumption.
• Roadmap sense: sequences a single lead SKU and a parallel bench prototype before the flagship, matching build order to where risk and addressable audience actually sit.
• Communication: makes an invisible benefit tangible (a glowing humidity readout, furniture-grade renders) so a skeptical buyer can feel the value before the product exists.

Luli

A keepsake pregnancy journal, built as a gift for one person.

The 30-second version. Luli is a private pregnancy companion and keepsake journal, built as a gift for one real person (Lulie). Each week it shows her what is growing, what her hormones are doing, what she might feel, what to eat, and a gentle movement and affirmation, then invites a sentence or two of journaling. When she nears the end, she can export the whole thing as a beautiful PDF keepsake of her pregnancy. It runs entirely in her browser with no account, no backend, and no tracking. Designed for an audience of one, it demonstrates real PM rigor: a deliberate data model, week-aware content, a hard privacy stance, and a clear-eyed view of the trade-offs that come from building for exactly one user.

---

Timeline: Personal gift build, completed and delivered

---

1. Problem statement

Pregnancy is forty-some weeks of profound bodily and emotional change, and the apps meant to accompany it mostly get the tone wrong: they are pastel, cartoonish, cliche-ridden ("mama," "mommy-to-be"), and built to harvest attention and data rather than to hold one person gently. Lulie deserved something that felt like hers: a calm, adult, beautifully made space that explained what was happening in her body each week and let her keep a private record she could carry forever. The personal problem was specific and real. How do you give someone you love a companion for the most intimate stretch of her life that comforts rather than commodifies, and leaves her with a keepsake at the end? Luli is the answer to exactly that.

2. Goals and non-goals

Goals

• Help Lulie understand her body and her baby each week, in warm, direct, non-clinical language.
• Make journaling the heart of the experience, so the app accrues into a personal record, not just a feed of facts.
• Produce a genuinely beautiful PDF keepsake at the end, so the months become something she can hold and revisit.
• Protect her completely: no account, no tracking, no data leaving her browser, because intimacy requires privacy.

Non-goals

• A commercial, multi-user product. Out of scope by design; this is a gift for one person, which sharpens rather than weakens the constraints.
• Accounts, payments, or sharing. Out of scope because every one of those adds a privacy surface and friction Lulie does not need.
• Medical authority. Out of scope; the content is a warm companion, with a clear footer disclaimer to always talk to her provider.
• Baby-app cliches (pastel pink, cartoon babies, "mama"). Explicitly out of scope; the tone is a Brooklyn stationery journal, not a nursery.

3. The product

Luli calculates the current pregnancy week from a due date, then serves week-aware content and a journaling space. Everything persists locally.

The current week is derived as 40 minus weeks-until(dueDate), clamped to 1 to 42, so the right content always surfaces without her having to track anything. The journal input is the most important interaction: large, inviting, and auto-focused.

4. User stories

As Lulie, opening the app mid-pregnancy, I want to see exactly what is happening this week in my body and my baby's, so that I feel informed and accompanied without searching.

As Lulie at the end of a long day, I want to write a sentence or two about how I am feeling, so that I capture this moment before it blurs into the next.

As Lulie nearing my due date, I want to download everything as a beautiful keepsake, so that I can hold the record of these months long after they pass.

As Lulie, who values her privacy deeply, I want nothing I write to leave my device, so that this space is entirely and only mine.

As Lulie returning to an empty journal (empty state), I want a warm, inviting prompt rather than a blank wall, so that the first entry feels easy to begin.

As Lulie if I go past my due date (edge case), I want the app to keep meeting me gently through weeks 41 and 42, so that an overdue week does not leave me staring at outdated content.

5. Requirements

Must-have (P0)

• Local-only persistence, no account, no backend, no external calls.
  • Given Lulie uses the app, when she enters anything, then it is stored only in her browser's localStorage and never transmitted.
• Accurate week calculation driving content.
  • Given a saved due date, when she opens Home, then the correct pregnancy week (clamped 1 to 42) and its content are shown.
• Journaling as the central interaction.
  • Given the Home screen, when she writes and saves, then the entry stores with today's date and the current week and appears in her history.
• Beautiful PDF keepsake export from week 38.
  • Given week is 38+ (or the arrived toggle is on), when she taps Download Keepsake, then a serif-typeset PDF generates with a cover page and one block per entry plus that week's note.
• Warm, adult, cliche-free tone with a medical disclaimer.
  • Given any screen, when it renders, then the language speaks directly to "you," avoids baby-app cliches, and the footer notes Luli is not medical advice.

Nice-to-have (P1)

• Subtle line-drawing illustrations per week.
• Photo attachments on journal entries (kept local).
• A gentle weekly "you reached a new week" moment.

Future (P2)

• A postpartum continuation companion.
• Optional encrypted backup so the keepsake survives a lost device, without compromising the no-account principle.

6. Key product decisions and trade-offs

Decision: Build for an audience of one, on purpose. Alternatives considered: generalize it into a shippable app (rejected because the gift's whole value is that it is hers, named for her, tuned to her). Why this won: designing for one real, known user is a PM discipline, not a shortcut. It forces concrete choices (her name, her due date math, her tone) instead of hedged defaults, and it is the reason the product feels personal rather than generic.

Decision: localStorage only, no account, no backend. Alternatives considered: a small backend for cross-device access and backup (rejected because it introduces an account, a privacy surface, and a dependency for a deeply private journal). Why this won: for an intimate record, the strongest privacy guarantee is that the data physically cannot leave the device. This is also the clearest unflattering trade-off in the build: it means the keepsake lives or dies with one browser, and a cleared cache or lost device loses everything. I accepted that risk for the privacy and simplicity it buys, and named encrypted backup as the future mitigation.

Decision: Make the PDF keepsake genuinely beautiful, and gate it to the end. Alternatives considered: an always-available export, or a plain text dump (rejected because the keepsake is the emotional payoff and should arrive as a moment, beautifully). Why this won: gating it to week 38 turns the export into a milestone, and the serif-typeset, one-block-per-entry layout makes it an object worth keeping rather than a data file.

Decision: Refuse baby-app conventions. Alternatives considered: the familiar pastel, cartoon, "mommy-to-be" idiom that the category defaults to (rejected because it is exactly the tone that made existing apps feel wrong for her). Why this won: tone is the product here. A warm, adult, stationery-journal aesthetic is what makes Luli feel like a gift and not an app.

7. UX

Even built for one person, the UX is held to a real standard. The palette is warm cream, deep brown, sage, terracotta, and dusty rose; headings are serif (Fraunces / Cormorant / DM Serif), body is clean sans (Inter / Geist); the layout is mobile-first at a 480px column with generous whitespace, 16px-plus rounded corners, and soft shadows. The microcopy speaks directly and warmly without ever tipping into saccharine, and there are no em-dashes anywhere, a small typographic discipline carried through the whole build. The journal input is deliberately the most prominent, auto-focused element, because writing is the behavior the product most wants to invite.

8. Success metrics and validation

For a gift of one, success is not adoption curves; it is whether the one person it was made for feels held and keeps something she treasures. Honest metrics for this build are qualitative and personal.

Leading indicators (for this build)

• Whether Lulie returns to check in across weeks. Target: regular use across the trimester. Measured: by her own account (no tracking by design).
• Whether the journal accrues entries. Target: a meaningful record by week 38. Measured: anecdotally.

Lagging indicators

• Whether she generates and keeps the PDF keepsake. Target: yes, the keepsake is the success condition.
• Whether the experience felt warm and private rather than clinical. Target: her felt sense of being cared for. [To be populated by her own reflection.]

What didn't work, and what I'd change. The single hardest trade-off (localStorage only) is also the build's biggest fragility: a cleared cache or a switched device wipes an irreplaceable record. For a keepsake, that is a serious risk, and if I rebuilt I would add an opt-in encrypted local backup or an exportable data file early, so privacy and durability can coexist. I would also add periodic gentle nudges to export progress, rather than gating the keepsake entirely to week 38, so that an early arrival or an unexpected loss does not leave her with nothing. The content is warm but asserted; for anything beyond a private gift it would need clinical review before it could responsibly reach other people.

9. Open questions and roadmap

• How do we add durability (so the keepsake survives a lost device) without breaking the no-account, nothing-leaves-the-device promise? (Owner: eng + the recipient's preference.)
• Should Luli continue into a postpartum companion, or is the keepsake the right place to end? (Owner: the recipient.)
• If ever generalized, what clinical review and tone guardrails would the content need? (Owner: legal + a medical reviewer.)

v2 scope (if ever extended): opt-in encrypted backup, per-week illustrations, and a postpartum continuation, always preserving the privacy-first core.

Positioning note: Luli is intentionally not in the commercial pregnancy-app market (BabyCenter, What to Expect, Ovia), which competes on features, community, and monetized attention. Its differentiation is the opposite: a private, ad-free, beautifully made companion for one person. That is not a market position so much as a design philosophy, and it is exactly what makes the gift land.

10. What this project demonstrates

• Problem identification: named precisely why existing pregnancy apps felt wrong (tone, cliche, data harvesting) and built the deliberate inverse.
• Trade-off reasoning: chose privacy over durability with eyes open, gated the keepsake to make it a moment, and refused category conventions on purpose.
• Technical fluency: a clean local data model, derived week math, and a real PDF export pipeline, all with zero backend.
• Validation discipline: honest that "success" for a gift is qualitative, and forthright about the fragility the privacy stance creates.
• Roadmap sense: a credible path to durability and a postpartum continuation without compromising the core principle.
• Communication: designing for one named, real user is a forcing function for clarity, and this spec shows the discipline that produced.