A voice chatroom app, pressable

The part nobody demos

Most demos of a voice chatroom app show the room. The room is the easy half — seats, a speaking indicator, a gift animation — and it is not what an operator is buying. What they are buying is the machinery underneath: a wallet holding three different kinds of balance, a ledger that records every movement, an identity check, a queue of payments waiting for a person to approve them, and a console for the person doing the approving.

And one thing more, which is why this page exists in the shape it does.

Agencies are the product

Apps in this category do not grow by waiting for hosts to sign themselves up. They grow through agencies: someone recruits hosts, keeps them on the mic to a monthly target, handles their scheduling and their complaints, and is paid a share of what those hosts earn.

That changes the arithmetic at the centre of the app. A gift is no longer split two ways between host and platform — it splits three. There is a second class of payee with its own tiers, its own targets and its own monthly settlement, and it needs to be visible in the ledger from the first line of code. Adding it after the wallet is written means a third party needs a share of a number the ledger was never designed to divide, and that rewrite is expensive precisely because it is the part handling money.

Why the tier is measured in hours

In this demo an agency's commission tier comes from the hours its hosts have logged this month, not from the diamonds they earned. That is a deliberate product decision rather than a detail: paying for hours buys rooms that are open when a listener opens the app, which is the thing that actually grows this kind of product. Paying on diamonds alone rewards an agency for finding one big spender and leaves the app empty on a Tuesday afternoon.

The tier is also derived rather than stored. It is computed from the hours every time it is shown, so it cannot drift away from the thing it describes — which a stored tier does the first time an hour is added and something forgets to recalculate.

The money path, in five steps

• Coins in. A listener pays money and receives coins at a rate the operator sets.
• Gift. A gift costs coins. They leave the sender's balance in one movement, recorded once.
• Agency cut. The host's agency takes its tier's share of that same gift.
• Diamonds. The host receives their share as diamonds — a balance that is earned rather than bought, and is the platform's debt to them.
• Payout. Diamonds convert to rupees at the operator's rate, and a withdrawal request enters a queue a person works through by hand.

Why the admin panel is the real product

The client question that matters is never "can users send gifts" — it is who is owed what, whether their identity cleared, whether the earnings are genuine or a self-gifting ring paying itself, and which member of staff pressed approve at 02:40. So the console here is not a screenshot: approving a payout in it changes the app, verifying a CNIC in it unlocks the withdraw button, and the Economy tab writes back into the arithmetic every other screen uses.

That last one is worth pressing. Change the host share and the gift table, the agency table, the platform margin tile and the host's own earnings screen all move together, because none of those numbers is written down twice. Push the host and agency shares up far enough and "Platform keeps" turns red — the model tells you the deal is underwater before the bank does. An app that pays out a figure its own settings page disagrees with is a specific, common and expensive bug, and the fix is architectural rather than careful.

What an operator has to be able to do

• Work a payout queue — approve, reject, and have a rejection return the money rather than lose it
• Credit deposits that arrived by bank transfer or wallet screenshot, before any gateway is integrated
• Verify or reject identity documents, and see which payouts are blocked because of one
• Mute a host, close a room, kick and ban — in one press, from a list
• Approve agencies, set their tiers, and settle what they are owed each month
• Price the gift catalogue and set the coin, diamond and minimum-payout rates
• See what the platform actually keeps, computed rather than typed in

What this demo is not

It is the interface and the money model — deliberately, because those are the two things worth agreeing before anything else is written, and the two that are cheapest to change at this stage. A real build adds, at minimum:

• Live audio through a real-time SDK rather than anything hand-rolled — this is bought, not built, and it is a per-minute cost that belongs in the model early
• A server-side ledger, because a balance a phone can edit is not a balance
• Payments in, whether a gateway or a reviewed manual-transfer queue for a first release
• Fraud controls, which in this category means self-gifting rings, refund abuse, stolen wallets and agencies inflating hours
• Recording, reporting and moderation tooling, and someone rostered to use it
• Push notifications, without which nobody learns a room started
• App store submission, which for a live social app is its own project

The parts that get an app of this kind removed

Worth raising early because it changes what gets built rather than what gets written in a policy afterwards. Live audio with strangers and real money moving between them attracts three specific problems, and the app stores review all three: minors on a platform built around adults paying adults for attention, content that nobody is watching in real time, and money moving in patterns that look like laundering because sometimes they are.

Practically that means age assurance at sign-up rather than a checkbox, a report button on every room and every profile that reaches a human quickly, recording retained long enough to act on a report, and limits on how much can move between two accounts before somebody looks. None of it is exotic. All of it is cheaper designed in than added after a suspension.

What the scope divides into

No price and no delivery date on this page, and that is deliberate — this site does not publish numbers it cannot source, and a quote depends on decisions that have not been made yet. What a quote is actually built from is this, and it is worth reading before asking anyone for one:

• The spine — wallet, ledger, identity, payout queue, admin console. Built once, and the piece that must not be rushed.
• The room side — room list, seats, real-time audio integration, gifting, chat, moderation.
• The agency side — recruitment, hours tracking, tiers, monthly settlement.
• Payments in and out — which gateways, and whether a manual queue covers the first release.
• Trust & safety — age assurance, reporting, recording retention, transfer limits.
• Apps — Android first, iOS with it or after, and who owns the store accounts.
• After launch — moderation cover, payout processing, and who is on call when a room goes wrong at midnight.

Bring that list to a conversation and it can be quoted properly. How we build apps covers the process; the contact form and WhatsApp both reach us.

Questions

Is this a real app I can sign into?

No. It is a prototype — a working interface with invented figures, running entirely in your browser. There is no account, no server, no payment and no real money. Nothing you press reaches anything, and nothing about you is stored or uploaded. It exists to show what Maxverse Lab builds.

How does the coin and diamond economy work?

A listener buys coins with money. A gift costs coins. The host receives an agreed share of that cost as diamonds, their agency receives another share, and diamonds convert to rupees at a rate the operator sets. Whatever is left between what the sender paid and what the host and agency can withdraw is the platform's. In this demo all of those numbers are editable in the admin panel's Economy tab, and changing one moves the gift table, the agency table and the host's earnings screen at the same time.

What is the agency system, and why does it matter so much?

Agencies are how apps in this category actually grow. Rather than waiting for hosts to sign themselves up, an agency recruits them, keeps them streaming to an hours target, and is paid a share of what those hosts earn. It means a single gift has to split three ways rather than two, and it means the platform has a second class of payee with its own targets, tiers and monthly settlement. Building the wallet without it and adding it later is the expensive order to do this in.

Why are agency tiers measured in hours rather than diamonds?

Because paying on hours buys rooms that are open when a listener opens the app, and that is what grows the product. Paying on diamonds alone rewards an agency for finding one big spender while leaving the app empty on a Tuesday afternoon. In this demo the tier is derived from the hours its hosts have logged rather than stored as a field, so it cannot drift away from the thing it is supposed to describe.

Why does the admin panel matter more than the app screens?

Because paying money out is the one action that must not be automatic. An app of this kind lives or dies on the payout queue: who is owed, whether their identity cleared, whether the earnings are genuine or a self-gifting ring paying itself, and who pressed approve. Moderation is the other half — mute, kick, close a room — and it is what decides whether a live product survives its first month.

What does a real build add that this demo does not show?

Live audio through a real-time SDK, a server-side ledger that cannot be edited from a phone, a payment gateway or a reviewed manual-transfer queue, push notifications, fraud and abuse controls, recording and moderation tooling, age assurance, and the app store submissions. This page is the interface and the money model, which is the part worth agreeing before any of that is written.