Four teams ran the numbers on My Wedding Coordinator (working title): a feasibility researcher, a red team, a blue ops team, and a green build team. One page: every issue, the detail, and the fix or thing we build.
Feature-by-feature verdict. Green = easy/cheap. Yellow = doable, budget real dev time. Red = hard or a trap for MVP.
| Feature | Verdict | Why |
|---|---|---|
| Budget planner + cost-per-person | Green | Pure client-side math. Zero AI/infra cost. Trivial. |
| Vendor marketplace + listings | Green | Standard, well-trodden marketplace pattern. |
| Text / location / budget / style search | Green | Postgres full-text + filters. No exotic tech. |
| Specials / vouchers hub | Green | CRUD + simple expiry scheduling. |
| AI chat wedding planner | Green *with guardrails | Cheap per couple (R1-5/mo) if capped + cached. Unmetered = biggest cost-blowout risk on the platform. |
| Guest manager + RSVP + drag-drop seating | Yellow | No infra risk - it's a UI engineering effort (canvas/drag). Budget real dev time. |
| Wedding-day assistant | Yellow | Green as checklist/timeline; scope-creep risk if it means live day-of AI coordination. |
| Inspiration mood boards | Yellow | Green as plain "save to board"; couples to the visual-search trap if it needs AI auto-tagging. |
| Visual search ("Google Lens for weddings") | Red for MVP Yellow P2 | Tech is cheap (self-host CLIP + pgvector, <$0.0001/query). The trap: needs a 10k+ image catalogue before results feel useful - an early/growth milestone, not pilot. |
The web server is the cheapest line item at every tier. The real cost drivers are AI API spend (scales with couples) and image bandwidth (scales with vendors). ZAR at ~R16.40/$.
| Tier | Load | Compute | DB (Postgres+pgvector) | Image blobs | AI budget | Total / mo |
|---|---|---|---|---|---|---|
| Pilot | <100 couples, ~50 vendors | 1× VPS 2-4 vCPU / 4-8GB (Hetzner ~R120, SA VPS R300-600) | <1 GB | 0.5-2 GB (B2 ~R90) | R300-1,000 | R1,500-3,000 |
| Early | 1-2k couples, ~300 vendors | 4-8 vCPU / 16GB (Hetzner ~R1,000) + Redis | 2-5 GB | 10-15 GB + CDN | R1,500-4,500 | R6,000-15,000 |
| Growth | 10k couples, ~1k vendors | Managed PG + 2-3 app servers + LB + Redis | 10-20 GB | 100-150 GB (B2 ~R1,800-2,700) | R15,000-40,000 | R35,000-70,000 |
DB storage is a non-issue - max ~20 GB Postgres even at 10k couples. Images live in S3-style object storage (Backblaze B2 at $0.006/GB), never as DB blobs.
| Entity | Pilot | Early | Growth |
|---|---|---|---|
| Vendors | ~50 | ~300 | ~1,000 |
| Couples | <100 | ~2,000 | ~10,000 |
| Guests (avg ~130/wedding) | ~13k | ~260k | ~1.3M |
| AI chat messages | ~10k | ~300k | ~2M+ |
| Images + CLIP embeddings | ~1.5k | ~25k | ~230k |
AI cost per couple - the one variable to control tightly. Default couples to a cheap model; reserve premium (Sonnet-tier) for a paid upsell.
| Model | Light couple (~15 msgs/mo) | Heavy couple (~100 msgs/mo) |
|---|---|---|
| GPT-4o-mini | ~R0.12 | ~R1.50 |
| Claude Haiku 4.5 | ~R0.86 | ~R9.80 |
| Claude Sonnet 4.6 | ~R2.62 | ~R29.50 |
Ranked most-lethal first. The critical cluster splits two ways: the business model (cold start, TAM, WTP, disintermediation) and SA law (POPIA special data, cross-border transfer, IDOR). Legal bites early and hard - R10m / 10-year fine cap under POPIA.
| # | Issue / Attack | Why it bites | Mitigation |
|---|---|---|---|
| 1 | Two-sided cold startCritical | Couple lands on a 5-vendor city, bounces; vendor sees zero traffic, won't pay R400-1200/mo. Each SA metro needs separate critical mass. | Fix: seed one city hand-onboarded + a WhatsApp lead-gen wedge before opening the directory; don't go multi-city until one is liquid. |
| 2 | Shrinking SA marriage TAMCritical | Marriages down YoY 10+ yrs. Every funnel layer sits on a shrinking base; the lead-gen pivot doesn't escape it. | Fix: size realistic market before spending; widen TAM with adjacents (engagements, vow renewals, corporate/matric events). |
| 3 | Vendor willingness-to-pay unprovenCritical | Vendors get free leads via IG/referral/WhatsApp. Fixed monthly fee before a lead converts → expect <10% cold conversion, heavy month-2 churn. | Fix: pilot pay-per-qualified-lead or first-month-free with 5-10 vendors before building recurring billing. |
| 4 | Disintermediation kills commissionCritical | Profile shows phone/WhatsApp/email → couple books direct, platform can't detect or collect. Most common services-marketplace failure. | Fix: masked number / in-app chat, reveal contact only after a trackable lead event - or drop commission for a flat lead-fee. |
| 5 | POPIA special-category dataCritical | Allergy/dietary = special personal info (s26), health-data tier. Free-text RSVP field with no consent gate = day-one violation. | Fix: explicit opt-in before capture; store separately under tighter access; document lawful processing condition. |
| 6 | Cross-border PII to a US LLMCritical | Guest names/allergies/addresses into US-hosted GPT/Claude = cross-border transfer (s72) needing adequacy/consent/DPA. Exactly what a complaint triggers on. | Fix: sign a DPA with the AI vendor, strip/redact PII before the prompt, cover transfer in consent/ToS. |
| 7 | No Information Officer / lawful basisCritical | POPIA requires a registered Information Officer + documented lawful condition per processing category. Solo founders skip it until a complaint forces it. | Fix: register an IO (can be the founder) before production PII; document lawful basis per data category up front. |
| 8 | Breach-notification duty + finesCritical | s22: notify Regulator + subjects ASAP. Fines cap R10m / 10 yrs. No incident plan = can't even detect a breach in time. | Fix: write + rehearse a breach runbook (detect, contain, notify, log) before go-live. |
| 9 | IDOR: guessable IDs across portalsCritical | Sequential IDs (/guests?wedding_id=1042) → increment to another couple's list or a rival vendor's leads. Most common MVP bug class. | Fix: object-level auth on every endpoint, non-sequential UUIDs, IDOR sweep across all sibling endpoints before launch. |
| 10 | Enumerable RSVP linksCritical | Short/sequential links (/rsvp/1042) → enumerate, harvest guest names/emails, submit fake RSVPs. | Fix: cryptographically random single-use tokens (128-bit+); rate-limit; alert on sequential access. |
| 11 | Uncapped LLM cost on free chatHigh | Multi-month chat replays history; by month 3 a turn carries 5-10k tokens. Zero cap → one scripted user = four-figure surprise bill, no revenue behind it. | Fix: cap tokens/messages per user/day, summarize context, per-IP + per-account rate limiting from day one. |
| 12 | Vision-search cost, no revenueHigh | Every visual search fires an image call ($0.005-0.03). Free feature, cost scales linearly with usage - more popular = more bleed. | Fix: daily free quota; cheap CLIP embeddings (~$0.0001) not full vision calls; reserve expensive calls for paid tier. |
| 13 | Visual search needs a catalogue that doesn't existHigh | Useful image search needs thousands of tagged photos per category. A young SA directory won't have volume - sparse, repetitive, off-category results. | Fix: don't ship until catalogue density is real (thousands/category); build it last. |
| 14 | Wrong / embarrassing matchesHigh | Elegant dress → knockoff; luxury venue → cheap hall. Screenshot-shareable credibility damage in a trust-driven category. | Fix: human-curate the seed catalogue; confidence threshold below which no result shows. |
| 15 | Fraud vendors take deposits, vanishHigh | No CIPC check → scammer lists a fake venue, collects a deposit off-platform, disappears. Couple blames the platform. | Fix: verify CIPC + ID before going live; "directory, not a party to your contract" disclosure; escrow/verified-badge tier. |
| 16 | Vendor no-show liability (CPA)High | If Aisle facilitates booking without airtight structure, the CPA's "supplier" framing can pull the platform into liability for a vendor's failure. | Fix: SA counsel drafts T&Cs positioning Aisle as facilitator/marketplace only, explicit at every booking touchpoint. |
| 17 | Backup / DR failure for wedding-day dataHigh | Guest list/seating/timeline are irreplaceable + time-critical. Loss the day before a wedding = catastrophe. Solo founder likely never ran a restore drill. | Fix: point-in-time backups + quarterly restore drills; extra redundancy/alerts within 14 days of a wedding date. |
| 18 | Bus factor 1, no on-callHigh | 2am outage/breach/corruption has nobody else to page. Recovery time balloons - during wedding season it touches live weddings. | Fix: automated monitoring/alerting minimum; pre-arrange a contractor/on-call backup for peak season. |
| 19 | Seasonal spike vs idle infraHigh | Season ~Sept-April. Trough-sized infra gets hammered at peak; peak-sized burns cash idling 4-6 months on a pre-revenue product. | Fix: autoscaling/serverless for AI + search tiers so cost tracks usage. |
| 20 | Chat abuse / prompt injection / spamHigh | No throttling → scripted cost-drain loops, prompt injection to extract system prompt or others' context, spam bots on free tier. | Fix: rate-limit by account + IP, anomaly detection on volume/cost, isolate context between sessions. |
| 21 | Pay-to-play featured, no quality gateHigh | If "featured" is purely for-sale, couples learn it tracks budget not quality → trust erodes → vendors stop paying → revenue line collapses. | Fix: minimum quality bar (verified reviews, completed bookings) for eligibility; label sponsored clearly. |
| 22 | Fake / inflated specialsHigh | Vendor marks up then posts "50% off," or never honors it - deceptive-discount pattern the CPA targets; cheap to game. | Fix: require documented before/after pricing or redemption tracking; spot-audit high-traffic specials. |
| 23 | Directory scrapingHigh | Unauthenticated paginated directory with contacts + pricing is trivially scraped - whole catalogue cloned in an afternoon. | Fix: rate-limit + bot-detect public directory, gate full contacts behind login/lead-capture, watch for bulk patterns. |
| 24 | PayFast / PCI scope creepHigh | Hosted redirect keeps you in SAQ A. A card field in your own app jumps scope to SAQ D - a burden a solo founder can't carry. | Fix: never touch raw card data - always redirect to PayFast hosted page/iframe. |
| 25 | Vendor payout data exposureHigh | Payout bank details in the same model as RSVP data turns one IDOR into a privacy breach + fraud vector (redirected payouts). | Fix: isolate financial data in a separate tightly-controlled service, encrypt at rest, log all access. |
| 26 | Seating drag-drop concurrencyMedium | Bride + planner editing same chart with last-write-wins silently drops changes - found days before the wedding. | Fix: optimistic locking or CRDT/OT for shared state; "someone else is editing" indicator. |
| 27 | Relational schema won't scaleMedium | Naive guests/tables/seats FKs choke on seating many-to-many + bulk ops past a few hundred guests with concurrency. | Fix: proper indexing + pagination from the start; load-test 300+ guest multi-editor before launch. |
| 28 | Search index cost / lock-inMedium | Algolia/Elastic scale with records + queries - fine at 200 vendors, a budget line at 5,000, painful to migrate off. | Fix: start with Postgres full-text / pgvector until vendor count justifies managed search. |
| 29 | AI provider rate limits at peakMedium | One shared key for chat + vision hits org rate limits during Dec/Jan engagement season - when first impressions matter most. | Fix: negotiate higher tiers ahead of spikes; graceful degradation (queue/retry w/ backoff) not hard fails. |
| 30 | Image storage growth + moderationMedium | Uploaded photos accumulate cost and, unmoderated, can be inappropriate/copyrighted. Solo founder has no moderation pipeline. | Fix: storage lifecycle/compression; cheap auto content-moderation API before publish. |
| 31 | Defamatory reviewsMedium | A false damaging review → defamation claim against the platform. ECT Act safe-harbor only holds with proper takedown handling. | Fix: publish moderation/takedown policy; respond within a defined SLA to preserve ECT safe-harbor. |
| 32 | Refund / dispute ambiguityMedium | No written policy → every deposit dispute is ad-hoc, challengeable as an unfair term under the CPA; erodes trust fast. | Fix: publish a clear CPA-compliant refund/dispute policy before accepting any payment. |
| 33 | WhatsApp concierge cost + lead qualityMedium | WhatsApp Business API bills per conversation (R0.50-2). Unreliable matching → mismatched leads → month-one churn, killing the lead product. | Fix: pilot the concierge manually (founder answers) to validate match quality before paying per-conversation at scale. |
| 34 | Feature sprawl vs solo capacityMedium | 8+ major surfaces for one person to build/secure/maintain. Security is what gets skipped when stretched thin. | Fix: cut to the pilot lead-gen core (WhatsApp concierge + directory); defer everything until vendor WTP is proven. |
| 35 | "Product-less" pilot still needs a legal wrapperMedium | Even a no-product pilot processes PII + brokers introductions. Skipping POPIA consent + vendor T&Cs "because pilot" carries full exposure. | Fix: treat pilot data + vendor agreements with full rigor: consent, basic T&Cs, lawful-basis note from day one. |
| 36 | Commission has no measurement pathLow | Without payment-through-platform or attribution, commission is largely unenforceable - near-zero in practice. | Fix: pick one enforceable mechanism (subscription or pay-per-lead) as primary; treat commission as a bonus, not a plan. |
Aisle processes couples' and guests' personal information, including dietary/allergy data, which is health-tier special personal information. South Africa's POPIA applies from the first vendor and couple, pilot included. Most of it is cheap or free; the costly part is building the app right, which you are doing anyway. And one architectural move neutralises the scariest item.
| Obligation | What it means for Aisle |
|---|---|
| 1 · Register an Information Officer | Mandatory. The company (or JP) registers with the Information Regulator. Online, free, ~20 min. Do it before any real user data touches the system. |
| 2 · Lawful basis + consent | You need a ground to process. Couples: contract / consent. Guest dietary/allergy (special personal info, s26) needs explicit opt-in consent - a real checkbox with purpose text, not a silent free-text field. |
| 3 · Operator agreements (s21) | Every third party touching the data (AI vendor, host, PayFast, email) is an "operator." You need a signed DPA with each. They all offer one off the shelf. |
| 4 · Cross-border transfer (s72) | Sending guest PII to a US LLM leaves SA. Legal only with the data subject's consent or a DPA giving adequate protection. |
| 5 · Security + breach + rights | Encryption, access control, kill the IDOR/RSVP bugs, a breach-notification plan, honour "delete my data", and auto-purge guest data after the wedding. |
| When | Action |
|---|---|
| Phase 0Before any real PII | Register the IO with the Information Regulator (free, online). Sign DPAs with every operator and flip the AI vendor to zero-retention / no-training (Anthropic and OpenAI both offer this). Publish a privacy policy + consent flows (toolkit template, then ~R5-15k SA lawyer review). Data minimisation by design; dietary/allergy behind an explicit opt-in. |
| ArchitecturalHighest leverage | Strip PII before it hits the LLM (tokens/IDs not names). Single biggest lever - turns the scary cross-border item into a non-issue. |
| Phase 1Build-time, already in scope | UUIDs not sequential IDs + per-object auth (kills IDOR); random RSVP tokens; encryption at rest; TLS. Retention: auto-purge guest PII a set number of days after the wedding date. Data-subject requests: a simple export/delete path. Breach runbook + logging so you can detect and notify in time. |
| Item | Cost |
|---|---|
| Information Officer registration | Free |
| DPAs / zero-retention toggle | Free (admin only) |
| Privacy policy + consent, lawyer review | ~R5-15k one-off |
| Everything else | Already in the build budget (it is just doing auth / encryption / retention correctly) |
Concrete tactics to keep the AI bill and DB load flat as usage grows. The two levers that matter most: precompute embeddings offline, and route cheap-model-first.
| Tactic | How |
|---|---|
| Cache AI responses | Hash (prompt template + key inputs) → Redis, TTL 1-24h by volatility. "Recommendations for budget X" cacheable 6h; live chat not cached. |
| Precompute embeddings offline | Nightly cron / on-upload webhook generates vendor-image embeddings once - never inside the search request path. |
| Cheap-model-first routing | Small model triages intent → routes only complex turns to the expensive model. Cuts AI spend 60-80%. |
| Token budgets per couple | Hard cap (e.g. 50k tokens/day), soft warn at 80%, hard block + upgrade prompt at 100%. Stops runaway loops and abuse. |
| CDN + image resize/webp | All images via Cloudflare Image Resizing / resize-on-upload → webp, responsive srcset. Never serve full-res originals. |
| DB query caching | Redis for hot reads (vendor list, active specials), short TTL 60-300s, cache-bust on write. |
| Cursor pagination + lazy-load | Guest lists, search results, chat history - cursor-based (not OFFSET at scale), infinite scroll client-side. |
| Debounce search | 300-400ms debounce before firing; cancel in-flight request on new keystroke. |
| Edge rate-limiting | Per-IP + per-account limits at Cloudflare, ahead of the app - stops scraping/abuse before it hits DB or AI spend. |
| Connection pooling | PgBouncer in front of Postgres - critical once serverless/edge functions multiply connection count. |
| Signal | Why | Tool (free tier) |
|---|---|---|
| Uptime (web + API) | Catch outages fast | UptimeRobot |
| Error rate / exceptions | Catch regressions | Sentry |
| AI spend / day | #1 startup-killer risk here | Cron sums tokens_used → Telegram if over threshold |
| DB size / growth | Plan tier upgrades early | Provider dashboard + weekly pg_database_size() |
| Latency p50/p95 | UX + early slowness warning | Cloudflare Analytics + Sentry Perf |
| Background jobs (embeddings, backup) | Silent failures are worst | Healthchecks.io dead-man's-switch |
Goal: a non-expert colleague opens Claude and either fixes it safely, or correctly recognizes "stop and wait for JP." Three parts: a runbook, a way to talk to Claude, and a hard line on what's off-limits.
| # | Symptom | Diagnose | Fix / Escalate |
|---|---|---|---|
| 1 | Site down / 502-503 | curl -I the URL; systemctl status aisle-app | Fix: restart service; check df -h. Escalate if not up in 5 min or disk full. |
| 2 | AI chat not responding | journalctl -u aisle-ai-gateway -n 100 | Fix: check API key + provider status. Escalate if provider outage (just wait/banner). |
| 3 | AI spend spike alert | Query tokens_used by couple, last 24h, desc | Fix: if one abuser - rate-limit/temp-block that account. Escalate if broad-based. |
| 4 | DB connection errors | SELECT count(*) FROM pg_stat_activity; | Fix: restart PgBouncer. Escalate if DB itself down (provider-side). |
| 5 | Image search empty/erroring | Check pgvector loaded \dx; embedding job last-run | Fix: rerun embedding batch. Escalate - never reindex a corrupt index without JP. |
| 6 | Vendor images not loading | curl image URL: bucket direct vs via CDN | Fix: purge Cloudflare cache. Escalate if bucket inaccessible. |
| 7 | Backup job failed (missing ping) | Check /var/log/aisle/backup.log | Fix: rerun backup.sh. Escalate if rerun fails too. |
| 8 | SSL expiring/expired | openssl s_client → check dates | Fix: trigger AutoSSL/LE renewal via panel. Escalate if renewal fails repeatedly. |
| 9 | Guest/seating data looks wrong | Read-only query on that couple_id | NONE without JP - user data, never manually edit rows. Always escalate. |
| 10 | Suspected security incident | Check auth logs for account/IP | Only revoke sessions/keys for affected account. Escalate immediately, always. |
| ✅ Safe - self-serve OK | ⚠️ Caution - read-only investigate | 🛑 Dangerous - JP only, never delegate |
|---|---|---|
| Restart app / web service | Query prod DB (SELECT only) | Any DDL (ALTER/DROP/CREATE TABLE) |
| Restart Redis / cache | Read app / error logs | Bulk UPDATE or DELETE |
| Purge CDN cache | Check provider status pages | Rotate / revoke API keys or DB creds |
| Rerun a batch job (embeddings, backup) | SSH to read config files | Force-push / merge to main unreviewed |
| Restart PgBouncer | Check disk / memory / CPU | Modify DNS records |
| Trigger AutoSSL renewal | Pull a manual backup (read op) | Restore a backup over production |
| Temp rate-limit an abusive AI user | Review AI spend by account | Suspend / delete a customer account |
Ruthless MVP: ship the lead-gen wedge that earns vendor money, defer everything that's a demo-day nice-to-have. Each deferred feature has a reason.
| Concern | What we build / do |
|---|---|
| MVP core (ships first) | WhatsApp reverse-quote concierge + vendor directory + budget/cost-per-person calc + guest/RSVP + vendor portal + static vouchers hub. That's the whole pilot. |
| Deferred, with reason | AI chat (cost control first), visual search (no catalogue yet), seating planner (UI-heavy), wedding-day assistant (scope creep), premium AI extras (upsell later). |
| Budget + cost-per-person | Pure client-side math. No server compute, no AI. Instant "what if we add 20 guests" ticker. |
| Seating planner | Client-side drag-drop, JSON state saved to DB. No server compute. Add concurrency-safety when 2 editors is real. |
| Visual search | Offline-batched embeddings, single-image query-time inference, pgvector. Bolt-on once catalogue is dense. |
| AI planner | Decision-tree first, LLM only as overflow for the messy questions. Cheap-model default, capped. |
| Cold-start seeding | Metro-by-metro manual vendor onboarding + human-curated concierge answering quotes. One city liquid before the next. |
| Disintermediation | Masked-number relay + in-platform value (quote comparison, contracts, milestones) + subscription billing, not per-booking commission. |
| Vendor onboarding friction | WhatsApp-native listing - vendor sends photos + details over WhatsApp, we build the profile. |
| POPIA-compliant guest data | Minimal collection, explicit consent, encryption at rest, auto-purge after the wedding, responsible-party/operator framing. |