Threadit
An AI-powered wedding vendor coordinator that centralizes vendor timelines and payments in one place, and automatically finds backup vendors when something falls through.
Built live during my job search, and now it's built, deployed, and running end to end.
Problem
Indian weddings involve coordinating dozens of vendors, caterers, decorators, photographers, venues, each with separate timelines, payment schedules, and communication threads, usually managed manually across WhatsApp and email by one exhausted family member.
Process
- Defined the core data model: Wedding, Contributor, Vendor, Commitment, Payment, Issue, Message, and Emergency Contact entities, so every feature has a clear source of truth to read from.
- Scoped an MVP that proves the core loop for real: a Claude-powered parser that reads a pasted WhatsApp or email message and extracts vendor, deadline, and payment data automatically, feeding a unified timeline dashboard and a split payment ledger.
- Designed a fallback vendor agent and an urgent-issue WhatsApp alert flow, both fully specified with their UI and logic, with the outbound message-sending itself mocked for the MVP rather than wired to a live provider.
Outcome
- A real, working message-parsing flow, not a mockup, that turns unstructured vendor communication into structured data automatically.
- A unified timeline dashboard and split payment ledger, so coordination and money tracking live in one place instead of scattered chat threads.
- A clearly scoped roadmap distinguishing what's built for real, what's built with a simplified layer, and what's documented as future work, honest about where the MVP's edges are.
Product Thinking
Three design decisions that shaped where the AI stops and the human stays in control.
Designing the Message Parser (Jobs to Be Done)
The problem
Threadit's core promise depends on one thing working well: turning a messy, informally written WhatsApp message into clean, structured data, a vendor name, a deadline, a payment amount. Get this wrong and the whole product feels broken, no matter how good the dashboard looks.
Framing the design decision
Instead of asking what should the parser extract, the design started with the job the user actually hires this feature to do: when a vendor tells me something important, I don't want to have to re-read it later and manually figure out what it means for my planning. That reframes the parser from a data-extraction tool into a comprehension tool, it needs to understand intent, not just pattern-match keywords.
How it's applied
- The prompt sent to Claude includes the raw message text plus structured context, the wedding's existing vendor list and any prior commitments tied to that vendor, so the model isn't parsing in a vacuum.
- Output is constrained to a structured format, vendor name, deliverable, deadline, payment amount, confidence level, rather than free text, so the app can act on it directly.
- A confidence score on each extraction lets the app decide when to auto-populate the dashboard silently versus flag the extraction for the user to confirm, low-confidence parses get surfaced for a quick human check rather than silently guessed.
Handling the edge case
Real family WhatsApp threads are messy, mixed languages, half-finished sentences, context assumed from earlier messages. The design choice is that the parser should fail visibly, not silently. An ambiguous message becomes a needs review item on the dashboard, not a wrong entry the user discovers later.
Why this matters
This is the difference between a demo that works on clean example messages and a product that works on the messy reality of an actual family WhatsApp thread. The Jobs to Be Done framing kept the design honest about what the user actually needs, understanding, not just extraction.
Where the AI Stops (Trust Boundaries and Human-in-the-Loop Design)
The problem
The fallback vendor agent is Threadit's most powerful feature and its riskiest one. When a vendor falls through, the agent can search for alternatives and draft outreach messages. The design question that matters most here is where exactly it should stop.
Framing the design decision
Every agent action was mapped on two axes, how reversible is it, and how much does it affect someone outside the app, a real vendor receiving a message on the couple's behalf. Actions that are low-reversibility and externally visible, sending an actual outreach message, always require explicit human approval. Actions that are internal and easily corrected, flagging an issue, suggesting alternatives to browse, can happen automatically.
How it's applied
- The agent can search, rank, and draft. It cannot send.
- Every drafted message is shown to the user with the option to edit before approving, not just approve or reject.
- The system never silently substitutes a vendor. If a decision needs to be made, a human makes it.
Handling the edge case
A wedding is one of the most emotionally significant purchases most people make. An agent that autonomously contacts a backup decorator without asking first isn't saving time, it's taking a decision away from someone at a moment that matters to them.
Why this matters
Most AI agent portfolio projects showcase autonomy as the impressive part. The genuinely harder and more valuable product skill is knowing where autonomy should end, and being able to explain that choice with a real framework behind it, not just instinct.
What Threadit Does and Doesn't Store (Data Minimization)
The problem
Threadit reads real personal communications, WhatsApp messages and emails between families and vendors. That's meaningfully more sensitive than typical app data, and the product has to earn the right to process it.
Framing the design decision
The guiding question for every piece of data Threadit touches is whether the product actually needs to keep it, or whether it only needs to use it once and let it go. This is a standard privacy engineering principle applied here as an explicit product decision, not just a compliance checkbox.
How it's applied
- The structured output of a parsed message, vendor, deadline, amount, is stored, since the dashboard and ledger need it to function.
- The raw message text is stored only linked to its structured extraction, as an audit trail, not indexed or used for anything beyond showing the original source message.
- Nothing is used to train models or shared with vendors without explicit action, the vendor never sees the couple's internal coordination, only the specific outreach message the couple approved sending.
- Users can delete their wedding's data entirely, including all linked messages, at any time.
Why this matters
A feature that reads personal communications without a clear, explainable answer to what happens to this data isn't ready to ship, regardless of how good the AI is. Trust and safety thinking has to be a first-class part of the product decision, not an afterthought bolted on before launch.
Behind the Build: Architecture & Technical Decisions
How Threadit is actually put together, where the AI runs, and which parts are real versus deliberately scoped as concept demonstrations.
How the feature set was derived
Threadit's scope wasn't assembled feature by feature from a wish list. It traces back to a single inspiration: production incident coordination, the PagerDuty-style pattern of tracking an incident to its root cause, escalating it to the right owner, and holding a clear record of who committed to what. Wedding vendor coordination has the same underlying failure mode in a completely different domain.
- Scattered updates across channels: vendor changes arrive over WhatsApp, email, and phone calls with no shared log.
- No single source of truth: the current state of a booking exists only in one person's memory and their chat scrollback.
- No structured way to handle a commitment falling through: when a vendor drops, recovery is improvised under time pressure.
Every feature added afterwards extends that same core loop rather than sitting beside it. The AI-generated checklist is the incident-prevention layer, the notifications hub is escalation, the payment ledger is the commitment record, and the fallback vendor agent is the recovery runbook.
Technical architecture
Threadit runs on a real Supabase backend, not a mocked data layer, with a full relational model behind it: Wedding, Contributor, Vendor, Commitment, Payment, Issue, Message, and ChecklistItem, plus the relationships that let the dashboard resolve a message back to the vendor and commitment it affects.
- Server-side functions handle every AI call and every database write. The browser never talks to the AI provider or the database directly, so provider keys and write paths stay off the client.
- The AI layer prefers the Claude API when a key is present, and falls back automatically to a Gemini-based model through Lovable's AI gateway when it isn't.
- That fallback is a resilience pattern rather than a demo trick: a missing or rate-limited primary provider degrades the model choice, not the feature.
Where AI actually does the work
Four places, each with a specific job and a specific output contract.
- Message parser: sends a structured prompt including the wedding's existing vendor and commitment context, and receives JSON back with per-field confidence scores. Low-confidence extractions are flagged for human review on the dashboard instead of being silently guessed into the timeline.
- Fallback vendor agent: a deterministic scoring function ranks candidates first, on category match, location proximity, and keyword overlap with the issue description. Only the top-ranked candidates go to the model, which drafts personalized outreach for each.
- Checklist generation: the prompt carries the wedding's actual date, days until the wedding, and already-confirmed vendor categories, so the model reasons over real state rather than emitting a generic timeline template.
- Voice notes: transcribed through a real speech-to-text model call, not a placeholder transcript.
The trust boundary as an architectural choice
Every AI-drafted output in Threadit, vendor outreach, contributor notices, Instagram DMs, passes through the same reusable approval-checkpoint component rather than through per-feature safeguards.
- Drafts are editable before they go anywhere, so the human can correct tone and detail rather than only accept or reject.
- Approval stays disabled until the user explicitly acknowledges that they are the one sending the message.
- There is no code path in the application that sends an outbound message automatically.
This is a design principle applied consistently across the product, not a one-off guardrail on the riskiest feature. Any new AI output surface inherits the same checkpoint by construction.
Email ingestion: from webhook demo to a real Gmail integration
Email ingestion evolved from a webhook demo into a real Gmail OAuth integration: users connect their actual Gmail account with read-only access, tokens are encrypted at rest with automatic refresh, and a tiered relevance search (known vendor senders first, then vendor-specific keywords, filtered against a noise-domain list of common consumer senders) surfaces genuinely vendor-related mail rather than processing an inbox indiscriminately.
- Testing against a real connected inbox surfaced a genuine bug worth documenting: messages from generic addresses (Gmail, Outlook) were being incorrectly matched to existing vendors purely by shared email domain.
- The AI parser itself would sometimes force a new company onto the nearest existing vendor rather than recognizing it as new.
- The fix added a freemail-domain exclusion and a name-agreement check that independently verifies the AI's own vendor suggestion before trusting it, rather than taking the model's output at face value.
When a message clearly names a new business, Threadit now creates a proper new vendor record instead of defaulting to manual review.
Honest scoping: what's real and what's a concept demo
- Real: email ingestion runs on a live Gmail OAuth connection that reads, parses, and files inbound vendor mail from a user's own inbox.
- Concept demo: WhatsApp auto-ingestion, running on seeded data and clearly labelled in the UI.
- Concept demo: Instagram vendor scouting, also seeded and labelled.
- Both concept paths depend on external business API approval processes, the WhatsApp Business API and the Instagram Graph API via Meta, which sit outside what a portfolio project can obtain. The parsing, scoring, and approval logic behind them is the same code the live integrations would use.
Build Status
- PRDcomplete
- Data Modelcomplete
- Timeline Dashboardcomplete
- AI Message Parsercomplete
- Fallback Vendor Agentcomplete
- Notifications Hubcomplete
- Wedding Checklist (AI-generated)complete
- Instagram Vendor Scouting (Concept Demo)complete
Build Log: A Real Bug, Not a Claim
A specific postmortem from testing the live Gmail integration against a real connected inbox.
What broke
While testing the Gmail integration against a real connected inbox, a test email from a brand-new vendor — "Kabir, Bloom & Bough Decor" — was incorrectly flagged for manual review, even though the message clearly named both the person and the company.
Root cause
Two separate faults were stacking on top of each other.
- Any email from a generic address like gmail.com was being matched against existing vendors purely by shared domain, so a gmail.com sender collided with an unrelated existing vendor who also happened to use Gmail.
- Separately, the AI parser would sometimes force a genuinely new company onto the nearest existing vendor in its list instead of recognizing it as new.
The fix
- A freemail-domain exclusion list, so personal email providers never drive vendor matching.
- A namesAgree check that independently verifies the AI's own suggested vendor match before trusting it, comparing distinctive words in the business names rather than accepting the model's pick at face value.
Verified
Re-tested live against the real inbox, not synthetic data. A properly-named new vendor now correctly creates a new vendor record, commitment, and payment, with the confirmation message: "Added Bloom & Bough Decor as a new vendor, created a new commitment, logged a payment."
- The same relevance-filtering pass cut a 50-message scan down to 4 genuinely relevant candidates.
- Confirmed end to end against a real connected Gmail inbox.
This is the actual value of building something real instead of a mockup: the bug only existed because the integration was genuinely live, and it could only be caught, diagnosed, and fixed by testing against real data — not assumed away in a demo.
Future Scope & Vision
Where Threadit could go next, and what is deliberately left for a later phase.
Event-specific planning
Beyond the current build, Threadit's roadmap has two natural directions. The first is tagging checklist items and vendor searches by the specific wedding function they belong to — Haldi, Mehendi, Sangeet, Wedding Day, Reception — so a family can plan and budget function by function.
- A lightweight version of this ships in the current build as a filter, so users can already narrow the checklist and vendor list by event.
- The fuller version adds per-event budgets and per-event vendor shortlists, turning the wedding from one big number into a set of manageable mini-plans.
A full booking layer
The second direction is moving from vendor discovery and coordination into actual venue and vendor booking within the app.
- That means real payments, real availability calendars, and real liability — a meaningfully different product from coordination.
- It is intentionally out of scope for the concept build, not because it is technically impossible, but because it changes the risk, compliance, and operations surface enough to deserve its own scoped phase.
Monetization & Business Model
How Threadit could make money without putting the core coordination experience behind a paywall.
Core coordination is free
The core coordination features — parsing, the ledger, the checklist — are free to the couple. The goal is genuine retention through ongoing utility, not a paywall on the thing that builds trust.
- Monetization sits on the vendor side: vendor subscriptions for enhanced, verified, and prioritized visibility in Find Vendors.
- This mirrors how directory platforms monetize placement rather than the core user experience.
Retention through the coordination layer
A plain vendor directory's value ends the moment a user gets a phone number. There is no reason to reopen the app.
- Threadit's coordination layer — the timeline, ledger, checklist, and notifications hub — is what keeps genuine utility alive well past that initial discovery moment.
- That gives users a real reason to keep the app open for months, which is the foundation for any vendor-side monetization.
A possible future secondary stream
Once a real booking layer exists, a small success fee on confirmed bookings becomes a natural secondary revenue stream.
- This is explicitly framed as unvalidated future thinking, not a current plan.
- It only makes sense once the product has moved into actual transactions, which is a separate scope from the coordination build.
What I'd do differently
The risk is over-automating a deeply emotional purchase. The product has to feel like a helpful coordinator, not a chatbot making decisions about someone's wedding day.