I built PartyCall after watching my family spend 3 days calling 200 relatives for a function — here's what I learned about a problem hiding

The "headcount panic the day before" framing is sharper than what we've been leading with — and you're right that it's the moment where the pain is most visceral. Everything before that (the missed calls, the stale spreadsheet, the WhatsApp group nobody's reading) is background stress. The night-before headcount is the crisis. That's the feeling worth leading with.
It also changes who the message lands for. "Automate your guest calls" speaks to someone in planning mode. "Know exactly who's coming before the day arrives" speaks to someone who has been burned before — which is almost everyone who has self-organised a large event.
Curious about PainBase — is it a tool you've built for surfacing pain signals from communities, or something broader? Would genuinely like to understand how you're approaching validation there, especially for problems that are felt widely but rarely articulated as a product need.

This is one of the sharpest pieces of feedback we've received and I want to sit with it properly rather than just say "great point."
The in-call branding idea is something we hadn't fully thought through — you're right that every call is essentially a product impression to someone who didn't choose to discover us. If that introduction is handled well, it's a warm touchpoint. If it's handled poorly, it damages trust in the host. So the design challenge is: how do you make the branding feel like it adds credibility to the invitation rather than feeling like an ad?
On the repeat purchase point — you've essentially articulated our ICP debate more clearly than we had internally. The wedding story gets attention but HR managers and community organisers are where the unit economics actually make sense. We've been trying to serve both simultaneously and your framing makes me think we should lead acquisition with the wedding story and conversion with the recurring use case. Going to think hard about how that changes our onboarding flow.
How would you handle the branding in the call itself — would you introduce it at the start, end, or weave it into the confirmation prompt?

This reframe is genuinely useful and I think you're more right than wrong.
The person suffering is often not the decision-maker — the bride's mother is exhausted by the process but the person who actually signs up for a tool might be the cousin who got handed the responsibility last minute and has no emotional attachment to "how we've always done it." They're more open to trying something new precisely because they didn't choose this job.
What this probably means for us practically: our messaging should target the reluctant organiser, not the experienced one. "Got voluntold to manage the guest list? Here's how to survive it" is a very different hook than what we've been running. And that person is younger, more tech-comfortable, and more likely to be on the channels we're actually using.
Does that match what you were thinking, or were you pointing at something more structural about the sales motion?

Really appreciate that — honest feedback from someone trying it fresh is worth more to us right now than almost anything else. Looking forward to hearing what you find, especially anything that feels confusing or broken on first use. Those are the things we can't always see ourselves.

You've essentially described exactly why we built around voice calls rather than just another WhatsApp tool — the muted chat problem is real and widespread, and it hits hardest with the guests hosts most need to reach (older relatives, busy professionals, people with notification fatigue).
On the marketing piece — that's genuinely our hardest problem right now. The product makes sense once someone experiences it, but getting to that first experience is the challenge. If you have any instincts about what kind of marketing would have actually caught your attention for something like this, I'd love to hear it. You sound like exactly the person we're trying to reach.

The vertical vs horizontal framing is exactly right and it took us longer than I'd like to admit to get there clearly.
The honest answer on timing: we knew the problem was specific from the beginning, but we kept being tempted to describe it in broader terms — "event communication platform" — because it felt safer and more scalable. It took probably two to three months of muddled conversations with potential users before we accepted that "family calling for Indian events" was the more honest and more powerful description. Specificity felt limiting until we realised it was actually the asset.
The domain expertise point resonates strongly. The multilingual piece alone — knowing that a call to a 70-year-old Telugu grandparent needs to sound different from a call to a 28-year-old HR manager in Bangalore — is the kind of detail that a horizontal tool would never care about but that makes or breaks trust for our actual users. That's the moat you can't buy.
Interesting point about the fundraising angle — hadn't framed it that way but it makes sense that vertical depth is a more defensible story to investors than "we're building for everyone who does events.

The spreadsheet line is one I keep coming back to myself — it captures something important about why the whole system breaks down. The problem isn't the spreadsheet, it's that the spreadsheet is downstream of five unreliable data sources and has no way to update itself.
On why calls specifically: honestly it came from watching the actual behaviour rather than assuming. WhatsApp messages get delivered and ignored. Texts get read and forgotten. But when a phone rings, people pick up — especially older guests who have conditioned themselves over decades to treat a ringing phone as something that requires an answer. The call creates a moment of attention that a message doesn't.
The language piece amplified this — a WhatsApp message in English from an unknown number gets ignored. A voice call in Telugu that addresses you respectfully gets a response. Those are different psychological experiences.
Your observation about the multi-company founder parallel is interesting — the underlying problem is really "too many inputs, no prioritised single source of truth." The form it takes in events is RSVP chaos; for a founder running multiple companies it's decision paralysis across contexts. Same root problem, different surface.

You've put your finger on exactly why the spreadsheet fails even when it's carefully maintained — it's a static output trying to track a dynamic, multi-channel conversation. The moment someone updates their RSVP verbally in a phone call and the host forgets to log it, the whole thing drifts.
The live dashboard in PartyCall is specifically trying to solve this — every response, from every channel, updates one place in real time so the host never has to reconcile sources again. Whether we've actually achieved that cleanly is something we're still learning from early users, but that was the specific design goal.
The multi-company founder equivalent you describe is a genuinely interesting adjacent problem. Have you come across anything that handles that well? I ask partly out of curiosity and partly because the underlying architecture of "aggregating responses across communication channels into one prioritised view" is something we've thought about more broadly.

This is the insight that shaped the entire product and you've stated it more cleanly than our own marketing does.
"The more reliable interface" — that's exactly it. We didn't choose voice calls because they're technologically interesting. We chose them because for a significant percentage of the guest list at any Indian family event, a phone call is the only communication channel that reliably produces a response. Everything else is optional for them.
The product has to work for the 75-year-old who answers unknown numbers and the 25-year-old who declines them. That tension in user behaviour is something we're still navigating in the UX.

You're right that multilingual routing is genuinely hard — and it's not just translation, which is the easy part. It's tone, register, and the cultural expectations embedded in how a formal invitation should sound in Telugu versus Hindi versus English. A direct translation of the same script doesn't work because the scripts themselves need to be different.
The 75-year-old who never opens the group is the specific person we designed around. She's also the person whose confirmation matters most to the host — she's the elder whose absence would be noticed and who would be offended to learn she wasn't personally invited. Getting her RSVP right is both the hardest technical problem and the highest-value outcome.
The "WhatsApp blast" default is interesting to unpack — I think it persists because it feels like you've done something even when it hasn't worked. You sent the message, you can see it was delivered, the failure mode is invisible until it's too late. A failed phone call, by contrast, shows up immediately as a missed call. That visibility is part of what makes the dashboard useful.

This is direct and right and I appreciate it being said plainly.
We've been guilty of exactly what you're describing — trying to position for weddings, corporate events, birthdays, and family functions simultaneously because each one feels like a real use case. But "works for everyone" is a positioning that convinces no one.
The weddings wedge makes strategic sense for a few reasons beyond just market size: the emotional stakes are high (getting RSVPs wrong at a wedding has real consequences), hosts are already spending money to reduce stress, and a good experience is likely to generate word of mouth within the wedding circle — photographers, caterers, planners, and future hosts who attended all see the product in action.
The question we're sitting with is whether to publicly reposition around weddings or to let that be the primary acquisition channel while keeping the product general. Do you think the positioning itself needs to change, or just the marketing focus?

These are the right questions and I want to answer the last one directly because it comes up.
A WhatsApp bot plus form combo works well for guests who are WhatsApp-active and comfortable with digital forms — roughly the 25–45 age bracket who are used to clicking links in messages. It breaks down for guests who don't open unknown WhatsApp messages, who don't click links from numbers not in their contacts, or who are uncomfortable with form interfaces. In an Indian family event guest list, that's often 30–40% of the people you most need to confirm.
Voice calls get through to that segment. They're also harder to ignore — a ringing phone demands a response in a way a WhatsApp message doesn't.
On the "+guest" handling — this is a known gap and you're right that it's a major real-world edge case. "I'm coming and bringing my wife" is a completely normal response that our current flow doesn't handle gracefully. It's on the roadmap but I won't pretend it's solved yet.
On confirmation trust — this is something we're actively thinking about. The dashboard accuracy is only as good as the responses, and we're exploring ways to give hosts more confidence in the numbers beyond just showing a count. Open to specific ideas if you have them.

This is a more precise articulation of the problem than the one on our own website and I mean that seriously.
"Turning RSVP collection into something that updates itself" — that's the product in one sentence. The invitation is almost a secondary feature. The thing that actually saves time and stress is the live, self-updating confirmation status that doesn't require the host to chase anyone.
The distinction you're drawing — coordination problem versus invitation problem — is important for how we talk about the product. We've been leading with "automated invitations" in a lot of our marketing because it's the most visible feature, but the real value is in never having to wonder "wait, are they actually coming?" three days before your event.
Going to think about how to shift the messaging around this framing. Thank you for putting it that clearly.

Great question — and honestly one of the more interesting UX challenges we've had to think through carefully.
When a guest answers but doesn't give a clear response, the system flags them as "needs follow-up" on the dashboard rather than assuming a confirmation or decline. The host can see exactly who fell into this bucket and decide whether to trigger a retry call, send a WhatsApp follow-up, or reach out personally.
We also built in automatic retries for guests who didn't pick up at all — so the no-answer cases are handled without the host having to do anything. The ambiguous responses are the ones that genuinely need a human judgment call, and we didn't want to automate that incorrectly.
Curious — do you think hosts would prefer the system to make a default assumption and let them override, or keep it flagged for manual review? We've gone back and forth on this internally.