Aisle · Strategy Memo
A red-team of the investor pitch, a competitive teardown of every player worth naming, and three new features that turn Aisle from a nice idea into an un-ignorable one.
Short version: the pitch is more solid than most seed decks on the numbers, but it is selling the wrong story. Right now it reads as "a consumer app couples pay for." The real business underneath is a vendor lead-generation SaaS with a couple-facing product wrapped around it. That reframe fixes the unit economics, sharpens the moat, and tells an investor exactly where the money compounds. Below: the holes an investor will hit and how to answer each, the one place the whole product should point, and three features designed to prove it.
A couple is a once-in-a-lifetime purchase. They pay R2,500 to R4,500 one time, maybe a token top-up, and never buy again. No repeat, no compounding. Couple LTV caps at roughly R3,500, full stop. That is a fine number to acquire a user, but it is not a business an investor gets excited about, because there is no second sale.
The vendor side is the opposite. A photographer or venue paying R700/mo and staying ~18 months is worth ~R12,600, and every renewal compounds. So the correct sentence in the deck is:
Nothing about the plan changes. What changes is which number leads: stop leading with couple ARPU, lead with vendor LTV and the flywheel that feeds it.
Five objections a sharp investor raises, each with the counter a prepared founder gives. Fill these into the deck as pre-emptive answers, do not wait to be asked.
StatsSA: 102,373 registered marriages in 2024, down 28.5% from 2015. The deck's "120k weddings, 16% CAGR" sits on a market that has declined for a decade.
The 16% is tooling adoption off a near-zero base, not celebration volume. Model on a flat 100k-110k base. Capturing a few thousand couples a year is the entire ask, no market growth required.
Hitting the R6-15m SOM via couples needs ~1,700-4,300 paying couples. The R100k GTM line implies a ~R25-80 couple CAC. Real D2C CAC for a considered purchase is R300-900. The numbers do not close.
Couples are acquired near-zero CAC via vendor referral: a booked venue hands the couple an Aisle invite as part of its own onboarding. Paid media is not the channel. The R100k funds content, SEO and vendor sales collateral. If referral fails, the model fails, which is exactly why it is the first thing to test.
The only published SA directory rates are R65-R95/mo. Aisle asks R400-1,200/mo, 5-15x higher, from a mostly informal, price-sensitive, sole-trader vendor base. No local comp proves this willingness to pay.
Anchor to opportunity cost, not to listings. R1,200/mo against a single incremental R15k booking pays for itself, versus a 10-15% referral commission that costs far more per lead. But it only holds if Aisle sells qualified, pre-briefed leads plus a vendor auto-responder tool, not a passive listing. Different, pricier category. Pilot before you assume it.
Strip the chat UI and it is a directory plus a site builder plus a CRUD guest list plus a seating solver, all solved since 2015. Any incumbent bolts an LLM on in weeks. Where is the moat?
The model is rented and commoditising monthly, so it is the wedge, not the moat. The moat is (a) vendor-side operational lock-in and (b) SA-specific integration depth (WhatsApp + PayFast + ZAR + load-shedding-aware). See section 3, the incumbents structurally cannot copy the agent that acts without detonating their own P&L.
SA weddings are sharply seasonal. A 6-9 month runway gives roughly one engagement-to-wedding cycle. If the first test underperforms in month 2-3, there is no capital left to re-test before the window closes.
Scope runway to span a full engagement-to-wedding cycle, not an arbitrary six months. The 60% infra reuse compresses build to weeks, maximising real cohorts inside the funded runway instead of burning it on build.
Teardown of Zola, Joy, The Knot / WeddingWire, Bridebook, Hitched, Appy Couple, and the SA directories yields one clean finding: every incumbent is a vendor-paid directory whose "AI" recommends, then hands the couple a list and a contact button. None book, draft-and-send, negotiate, or auto-assemble. Their AI optimises matching within a pay-to-be-recommended structure; it never closes the loop.
They cannot close it. The Knot / WeddingWire's revenue is the manual enquiry, the billable lead event. An agent that auto-drafts and sends qualified briefs to best-fit vendors collapses that lead-padding model, which is already under fire (a 2025 New Yorker investigation into fabricated leads, a vendor class action, 200+ FTC complaints, a US senator asking the FTC to investigate). Aisle's core feature is their P&L's poison. That is a wedge they cannot fast-follow.
In South Africa specifically there is no AI-native wedding platform at all. Discovery already happens on WhatsApp (Instagram browse, then WhatsApp quote). The closest local thing is a 5-message chatbot used as a lead-capture gate. The lane is open.
A WhatsApp reverse-quote concierge: "Text one number. Get real vendor quotes back." The couple describes the wedding once, date, budget, style, headcount, and the agent drafts, sends and chases enquiries to best-fit vendors, then hands back a clean comparison of who is available and what they cost.
It meets SA where it already is (zero behaviour change, zero install), it proves in the first five minutes that the agent acts instead of advising, it attacks the incumbents exactly where they are frozen, and it seeds both sides of the marketplace at once: couples get a magic time-saver, vendors get structured pre-qualified briefs, the direct antidote to the "spam lead" complaint that makes the R400-1,200/mo price defensible.
| Aisle feature | Verdict |
|---|---|
| Guest list / RSVP | Commodity. Table stakes, wins nothing. |
| Budget tracker | Commodity. Everyone has a spreadsheet-with-a-skin. |
| Chat-to-build website | Novel delivery, but already exists (Nigeria's Vowthread, Joy Pro). Do not lead with it. |
| Venue / vendor matching | Contested, but couple-aligned matching (best fit, not best-paying) is something incumbents cannot do without cannibalising revenue. |
| Constraint-solved seating | Rare and hard. Zola's is iOS-only and 15-guest capped; Bridebook has none. Genuine proof-of-competence feature. |
| Live DJ / Spotify playlist | Uncontested. No wedding platform does this. Viral at the event, which doubles as couple acquisition. |
| One agent that plans and acts | Uncontested category. The moat is not the feature, it is the orchestration layer that executes. |
These are designed in full, with user stories, screens, data models, AI hooks, offline handling and monetisation, in a companion prospectus. Summaries here; open the full doc for the build detail.
The thing that makes a vendor happily pay and not churn. A Listing Health score with a concrete checklist, a catalogue and package manager that feeds the AI matcher, an analytics funnel (impressions to views to shortlists to leads to bookings, benchmarked against similar vendors), a WhatsApp-native lead Kanban, an availability calendar wired into the matcher, and a "why am I recommended" transparency panel with a what-if simulator. Boosted placement only re-ranks within already-relevant vendors, so it can never bury a better match.
Anti-churn is a number, not a feature: every login shows an attributed-revenue ledger, "3 bookings this quarter, worth R48,000." A vendor whose accountant can see what the subscription bought renews without being asked.
Free / R400 Growth / R1,200 Pro · PayFast recurring
Live wedding-day ops: QR and fuzzy-name check-in in under three seconds, a live table-by-table arrival grid ("has my aunt arrived yet"), one-tap headcount to the caterer over WhatsApp, walk-in and no-show reconciliation that pulls open seats straight from the seating solver. A Command device (coordinator) and Check-in devices (ushers) with locked-down roles.
The design that makes it real is the offline model: every check-in is an append-only, idempotent event written to the device first, gossiped peer-to-peer over venue wifi even when the internet uplink is dead, relayed to cloud by whichever single phone has data. No last-write-wins race, and every screen states its own sync honesty. Built for the day load-shedding takes the venue's fibre down. Every incumbent stops the day before the wedding.
~R249 per wedding · natural upsell after the seating solver
One thread per guest that resolves RSVP, dietary, transport and group gifting in the guest's own words. A form captures "attending: yes, party: 2." It cannot turn "ya we coming but my mrs doesn't do meat" into an RSVP, a party size, and a dietary flag on the right person. That parse, in the language the guest actually used, is the product, and it is genuinely hard without an LLM.
It is the connective tissue: dietary output lands in the caterer's lead thread (A), the final guest list is the authoritative manifest the day-of app downloads (B), transport needs cluster into a shuttle, and a PayFast cash fund lets diaspora family contribute. Confidence-gated: ambiguous replies never silently produce a wrong headcount, they surface for the couple to confirm.
Plan allowance + per-guest overage + small basis-point fee on gift throughput
All three share one architecture: the Concierge is the data engine, the Vendor Dashboard's calendar keeps the matcher honest, and the day-of app's offline-first pattern (local write, peer sync, opportunistic cloud) is how the whole ZA-facing product should be judged, because patchy connectivity is not specific to a wedding day, it is specific to the country.
The single most likely way this dies in 18 months is the classic two-sided cold start, SA-flavoured: couple revenue is too thin and one-time to cover burn, and vendor recurring revenue, the only line that carries the model, takes longer to convert than planned because the vendor base is informal and hard to onboard onto recurring billing. The runway runs out before the flywheel closes.
So before building the AI agent, the seating solver or the site builder, run a product-less pilot:
The bones are good and the numbers hold up better than most seed decks. Three moves make it un-ignorable: reframe it as a vendor SaaS, lead with the WhatsApp reverse-quote concierge, and prove vendor willingness-to-pay with a product-less pilot before the build. The feature set above is what you point at when an investor asks "and then what," it shows the product has a second, third and fourth act that all feed the one line that compounds.