What Super Apps Still Haven't Solved: Planning Between Friends
A super app can move money, order dinner and hail a car without you ever leaving the conversation. It still cannot tell you whether Saturday is on, because event coordination between equals was never the kind of service this model was built to host.
Quick answer
Super apps like WeChat bundle payments, commerce and third-party mini programs into one identity and one inbox, solving almost every everyday transaction inside a single conversation.
What they haven't solved is a private plan between friends: a record several equals jointly hold, update and answer, as opposed to a transaction between a person and a business.
A real fix needs a private-by-default record, addressable by one link, that costs guests nothing to answer and leaves the conversation itself completely untouched.
One app, everything in it, except the one thing
Open WeChat and you can pay a friend back, order a coffee, book a doctor, hail a ride and read the news, all without ever leaving the app.
It is, genuinely, a whole operating system living inside a chat client. MIT Technology Review has described how WeChat expanded from messaging into payments, shopping and streaming, then in 2017 added mini programs that let outside services run inside it without anyone leaving the platform.
And yet the actual plan for Saturday still lives in a scroll of messages that nobody can query. The super app absorbed almost everything except the one thing a group of friends does every single week: agree on when and where to meet.
What "super app" actually means
The term gets used loosely, so it is worth being precise. A super app is a single application that bundles messaging, payments and a wide range of third-party services, usually through an internal platform for lightweight apps that run inside the host rather than as separate downloads.
WeChat is the model everyone points to, but it is not the only one, and the pattern is well documented enough to have its own entry describing the concept: one identity, one inbox, dozens of services, no separate installs.
WeChat's own developer documentation calls these embedded services mini programs, official infrastructure for building an app that runs entirely inside another app. That is the architectural trick that makes the whole model work: you are never asked to leave.
A super app removes the friction of switching apps for almost everything. It has not yet removed the friction of switching from talking about a plan to actually holding one.
How this actually plays out for nine people planning a trip
Take something more involved than dinner. Nine friends are trying to plan a weekend away, and the group chat is where the whole thing lives.
Someone floats three possible dates. Four people answer in the thread, two answer by reacting to a message from two days earlier, and one person texts a completely different friend outside the group to ask what's actually been decided.
A date eventually wins, mostly by attrition rather than a clean vote. Then the harder part starts: who's driving, who's splitting a room with whom, whether the group is renting a place or booking two rooms at a hotel.
Every one of those sub-decisions generates its own thread of replies, and every one of them is one scroll-past away from being lost. By the Thursday before the trip, at least one person is asking a question that was already answered twice, because the answer was never anywhere except three separate message threads.
None of this happens because the group is disorganized. It happens because a super app gave them an excellent tool for talking and no tool at all for holding the result of the talking still.
Why event coordination is the gap, not an oversight
It would be easy to assume nobody has built this because nobody thought of it. That is not quite right.
Payments, shopping and ride-hailing all share a structural feature that event coordination does not: they are transactions between a person and a business, with a clear start and a clear end. Event coordination between friends is not a transaction. It is an ongoing, changeable, entirely social agreement that several people have to hold in common.
Mini program platforms are built to let a business or service plug into the super app. They are not built around the idea of a plan that a group of equals owns jointly, updates together, and eventually finishes.
That is a genuinely different shape of problem, and it explains why the gap has persisted even inside an ecosystem that otherwise absorbed almost everything else.
| Already solved | Still missing for a group plan |
|---|---|
| One identity across every service | A private, shared record several people can jointly hold |
| Payments without leaving the app | A plan's current state, separate from the chat about it |
| Third-party services running inside the host | A structure built for a group of equals, not a business and a customer |
| Instant messaging at enormous scale | A record that survives edits without losing who agreed to what |
What a good event layer inside a super app would need
Picture what this would actually require, not as a wishlist, but as a specific set of constraints the existing ecosystem already half-solves.
Start with the version everyone has already lived through. Someone in the group opens the chat, types "so are we still doing Saturday", and waits.
Three people react with a thumbs up. Two more type "yes!" as separate messages. One person asks what time again, because the time was mentioned four days ago and has since scrolled past a birthday photo, a meme and an argument about the restaurant.
Nothing about that exchange is broken exactly. It is just doing a job the chat was never built to do well: holding a fact steady while the conversation keeps moving around it.
It has to be a record, not a mini program bolted onto a chat
A calendar-style mini program that just displays dates does not fix anything if the underlying plan still lives as scattered messages. The record has to hold the actual state: who is invited, who has answered, what the current time and place are, and what changed since the last version.
It has to stay private by default
Everything else in a super app either broadcasts (posts, articles) or transacts with a business (payments, orders). A private event between nine friends is neither, and it needs to default to closed rather than being bolted onto tools built for public discovery.
It has to cost the guest almost nothing
The reason mini programs work at all is that opening one requires no install and no separate account, just a tap from inside a conversation you're already in. An event layer has to inherit that exact property, because the moment a guest needs to set anything up, some fraction of the group will simply not answer.
It has to leave the conversation alone
This is the constraint every design conversation tends to skip. The chat is good at deciding, arguing, getting excited. An event layer that tries to replace the chat, rather than sitting alongside it, is solving a problem nobody has.
It has to survive being edited without losing the history
Plans change. The restaurant falls through, the time slips an hour, someone new gets added on Thursday.
A record that just overwrites the old details loses something real: who agreed to what, and when. The version people actually need keeps a clean current state on top, with the trail underneath for whoever wants to check it.
| Where the plan lives | What it's good at | What it quietly breaks |
|---|---|---|
| Scattered chat messages | Fast to send, no setup, everyone already there | No single current version, buried within hours |
| A pinned message or post | One visible location, easy to point new members to | Still has to be manually rewritten by hand every time something changes |
| A shared record with one address | Always shows the current state, holds a clean history underneath | Has to be built, and nobody has built the private, guest-friendly version yet |
Why nobody has built this well yet
Three separate obstacles, not one.
Business incentives point elsewhere. Mini program platforms grew around commerce because commerce has an obvious business model attached to it. A private, ad-free record for nine friends planning dinner does not obviously make anyone money, so it has never been where platform investment goes.
The audience assumption is baked in everywhere. Almost every existing tool, event pages, ticketing platforms, even public-facing mini programs, assumes an audience worth reaching. A private plan actively wants the opposite: the smallest possible visible footprint.
Cross-platform reality breaks single-ecosystem thinking. A genuinely good event layer would need to work whether your group is entirely inside one super app or scattered across half a dozen separate messaging apps, and most platform teams design as if their app is the only one anyone uses.
The dependency risk nobody plans around
There is a less obvious cost to folding your entire social plan into one company's platform, and it is worth naming plainly.
When your messaging, payments, event records and social identity all live inside a single app, losing access to that account does not just cost you one service. Reporting on WeChat account bans has described exactly this: users who lost access described it as losing their entire social and digital life at once, not just their chat history.
That is an extreme case, but the underlying shape of the risk applies more broadly to any super app model. The more one platform holds, the more a single account problem, a ban, a lost phone, a company decision, takes down at once.
A genuinely good event layer would want some independence from that single point of failure: an address for the plan that survives even if one particular app becomes unreachable.
What this looks like if it gets built right
Some version of the future is easy to sketch, because the pieces already exist separately.
- One tap creates the record. Inside whatever conversation the group already uses, someone starts a plan the way they'd tap into any other embedded service, no separate download.
- The record lives at one address. Not a message, not a pinned post, an actual object with a current state that updates rather than accumulates.
- Guests answer without installing anything. The same frictionless tap that makes existing mini programs work extends to responding, whichever app each guest happens to use.
- The plan stays private to the guest list. No public page, no discovery feed, nothing indexed, because the audience is fixed and small by design.
- The conversation keeps running exactly as before. The chat still does the arguing and the excitement. The record just quietly holds the facts everyone keeps asking about.
None of these five steps requires inventing new technology. Every piece already exists somewhere in the current ecosystem. What is missing is somebody building the specific, narrow layer that connects them for a plan between equals rather than a transaction with a business.
What builders keep getting wrong when they try
A few platforms have taken a run at this, usually by adding an events feature to an existing group tool. The pattern of what goes wrong is fairly consistent.
The first mistake is treating the record as a bigger, prettier message. A nicely formatted card that still lives inside the chat's own timeline has the same fatal flaw as a pinned post: it ages the moment anything changes, because updating it means editing or resending, not simply changing a field.
The second mistake is inheriting the audience-first thinking baked into everything else the platform does. A calendar feature built by a team used to thinking about reach and discovery tends to add sharing, public links and follower counts to something that was supposed to be small and private by default.
The third mistake is asking guests to do work. The moment an invite requires a guest to create an account, download something separate, or navigate an unfamiliar interface, some real fraction of a nine-person group will simply not respond, and the organizer is back to chasing replies by hand.
Put together, these three mistakes explain why "we added an events tab" so rarely fixes the actual problem. The tab exists. The underlying behavior of a group of friends barely changes.
Why this matters beyond WeChat specifically
WeChat is the clearest example because its mini program platform is the most mature version of the super app pattern in daily use anywhere. But the same gap shows up wherever messaging has absorbed everything except this one specific job.
Any sufficiently large messaging platform eventually faces the same question: now that people do almost everything here, why does planning a dinner still feel like it is happening in the wrong tool? The answer, consistently, is that planning between equals was never the kind of service these platforms were built to host.
That is not a criticism of any single company. It is a genuine gap in a category of software that has otherwise solved an enormous amount.
Where Ontaym fits
Ontaym is built as exactly that narrow layer: a record for a private plan, addressable by a single link, that any conversation on any platform can point to.
It does not ask your group to move anywhere, and it is not trying to become a super app itself. It is trying to be the one missing piece that a super app's own architecture has never quite gotten around to building.
That is a deliberately small scope. A ticketed festival belongs on a publishing platform built for audiences, and Ontaym is not that.
What to actually watch for
If you want to know whether this gap is closing, the useful place to look is not marketing copy about new features.
It is whether a platform lets a private plan exist as a genuine record, addressable and private, without asking every guest to install anything.
Most announcements about calendars, groups or events inside super apps still describe better messages, better polls, better pinned posts. Those are all improvements to the conversation, and none of them are the record.
The actual fix looks smaller and less exciting than a new feature announcement. One address, one current state, one link the conversation can point to.
Everything else about the super app can stay exactly as it is. That is, in a way, the whole point: the fix is narrow on purpose.
A test you can actually run
Here is a simple way to check whether any given "events" feature inside a super app is the real thing or another layer of chat.
Ask what happens the moment a detail changes. If the fix requires someone to retype a message, edit a pinned post, or start a new poll, you are still looking at a conversation wearing a calendar's clothes.
If the fix is a single edit that every guest sees reflected the next time they open the same link, that is a record. The difference sounds small until you have lived through the first version at least a dozen times.
There's a second test worth running alongside the first: what happens to a guest who has never opened the super app at all. If the platform requires an install, a login or an account before that person can even see the plan, it has quietly rebuilt the exact friction it was supposed to remove.
A genuine fix treats the guest list as the constraint, not the platform's own user base. Someone on a completely different messaging app should be able to open the same link and see exactly the same current state, no download required.
That last part matters more than it looks. Real friend groups are rarely tidy about which app they all use. One person is on WhatsApp because that's what their family uses, another is on iMessage because they've never left it, and a third only checks Discord because that's where a different community of theirs lives.
Any fix that only works if everyone happens to already be inside the same super app quietly excludes exactly the people who make coordination hard in the first place. The nine-person trip from earlier in this piece is a fairly ordinary example: not everyone in that group was using the same app to begin with, and the plan still had to hold together anyway.
Frequently asked questions
What is a super app, exactly?
A single application that bundles messaging, payments and a wide range of third-party services, usually through an internal platform for lightweight apps that run inside the host without a separate install. WeChat is the model most people point to.
If super apps already do so much, why can't they hold a group's plans?
Because payments, shopping and rides are transactions between a person and a business, with a clear start and end. A group plan between friends is an ongoing shared agreement between equals, which is a structurally different problem nobody has built the internal platform for.
What are WeChat mini programs?
Lightweight applications, introduced in 2017, that run inside WeChat itself rather than as separate downloads, letting outside services operate without anyone leaving the app. WeChat publishes the framework for building them in its own developer documentation.
What would a good event layer inside a super app actually need?
A real record rather than a display, private by default rather than built for discovery, effectively free for a guest to answer, and complete indifference to the conversation itself, which should carry on exactly as before.
Why hasn't a big platform already built this?
Three separate reasons: there's no obvious business model attached to a private, ad-free plan for a few friends, most existing tools assume an audience worth reaching, and cross-platform groups break any design that only accounts for one app.
Is there a real risk to putting everything, including your social plans, in one super app?
Yes. Reporting on WeChat account bans has described people losing their entire messaging, payment and social history at once when a single account was suspended, which is the sharpest version of a risk that applies to any single-platform dependency.
Does this mean a private-event layer would replace group chats?
No, and that's the point. The conversation stays exactly where it is, doing the arguing and the excitement it's already good at. The record only needs to hold the facts everyone keeps having to ask about.
Where does something like Ontaym fit into this picture?
As the narrow layer super apps haven't built: a private record for a plan, addressable by one link, that any conversation on any platform can point to without asking the group to move anywhere.
Give your next plan one address instead of one more thread.
Plan it with Ontaym