MUDITA · PHASE ONE
THE BUILD · WHAT IT IS, WHAT IT TAKES
19 AUG 2026
Phase One
Connect what you already have.
Not new software. Not a new tool for your team.
The join your data has never had.
The point
Your business already records the answers. Nothing reads them together.
Every ad, every payment, every minute watched is already being written down — into four systems that have never
been introduced to each other. Phase one introduces them. To prove it is not a promise, we ran it on batch 26 before writing this page.
Exhibit A — the proof
One ad, made in December, produced 83% of batch 26's revenue. Nobody could see it.
| Ad creative | Seats | Buyers | Revenue ₹ |
|---|
| VS-36 — "So you didn't do…" · Unnati · 31 Dec 2025 | 116 | 3 | 1,98,604 |
| VS-47 — "Your money is silently dying" · Kashish · 29 Apr | 78 | 2 | 17,703 |
| VS-57 — "Your money is silently dying" · Kashish · 1 Jun | 9 | 1 | 11,802 |
| IC-88 — "Math" · Soumen · 25 May RETARGET | 3 | 1 | 5,901 |
| IC-79 — "Testimonial Card" · 26 May | 12 | 0 | 0 |
| VS-48, VS-57 (19 May), IC-77, IC-81 and others | 12 | 0 | 0 |
| Entered outside the landing page — untraceable | 18 | 1 | 5,901 |
Broken tag — {{ad.name}} never resolved | 2 | 0 | 0 |
Read the top two rows together. VS-47 brought two-thirds as many seats as VS-36 — and one-eleventh of the money.
On seat count they look like comparable ads. On revenue they are not the same business. Batch 26 was carried by a creative that was
already eight months old, and the media plan had no way of knowing.
How this was recovered — and why it was invisible
Only 2.7% of payments carry the ad in the payment record itself. But 100% of landing-page sessions carry the full ad tag,
and 96% of payments carry the session id that links the two. Joining them succeeds for 95.8% of payments.
The bridge table for exactly this join already exists in the database — and has never had a single row written to it.
Nothing above required new tracking. It required the join.
Where you stand today
Three systems are flowing. The layer that makes them mean something stopped in June.
| System | What is in there | Through | Status |
|---|
| Razorpay — payments | 40,208 records | 31 Aug | LIVE |
| Meta — ad spend, daily | 2,478 records | 30 Aug | LIVE |
| Landing pages — sessions + ad tags | 33,858 records | 31 Aug | LIVE |
| Batches — who was in which batch | 3,198 records | 12 Jun | STOPPED |
| Attendance — who watched, how long | 460 records | Jun | PARTIAL |
| Zoom — attendee sessions | 120 records, one day only | 6 Jun | PARTIAL |
| Zoom — registrants | empty | — | NEVER RAN |
| Sales calls — who called whom, outcome | empty | — | NEVER RAN |
| Ad ↔ payment bridge | table exists, empty | — | NEVER RAN |
This is the honest starting line. The expensive half — the money data — is already flowing.
What stopped is the layer that turns payments and spend into batches, people and outcomes. Phase one restarts it and keeps it running.
What we build
- 01The join — every rupee gets its ad.
Payment ↔ session ↔ creative, written continuously, and backfilled across every batch already in the database. Batch 26's table above, for every batch you have ever run.
- 02Restart the batch layer, permanently.
Who is in which batch, when they paid, how long the gap was — automatic after every batch, not a manual pull that stops in June.
- 03Attendance, properly.
Registrants and minute-level attendance for both days, every batch. Today this exists for a single day in June.
- 04The sales record.
Every call and outcome per representative, landing in the same brain as the ad and the attendance — so post-webinar performance is finally visible per person and per rep.
- 05One record per person.
The spine that ties it together: ad → landing page → payment → attendance → calls → revenue. One row per human, across every batch, never deleted.
- 06The outputs.
The leak map, the batch report that writes itself, and the always-on scorecard — built on the spine, arriving without anyone assembling them.
What we need from you
- Read access to Meta, Razorpay, Zoom and WhatsApp — most already in place
- One tracking line kept on the payment page — already there for 96% of payments
- Thirty minutes with whoever keeps the sales sheet today
- Nothing else. No new tool for your team to learn
What phase one does not do
- It does not send messages on its own
- It does not change or pause ads on its own
- It does not replace any tool your team uses today
- Those come later, priced separately, and only if you want them
Sequence — proposed
FirstThe join, and the backfill. Every batch in the database gets the table you saw above. This is the fastest visible win — the history is already sitting there.
ThenThe batch and attendance layer, running again. From the next batch onward it never stops, and never needs anyone to remember.
ThenThe sales record and the spine. One record per person, end to end.
LastThe outputs. Leak map, batch report, live scorecard — arriving on their own after every batch.
One thing to decide together
The batch layer stopped on 12 June. Every batch run since then is still recoverable from the payment and ad records —
but the attendance detail for those batches is only as good as what Zoom still holds. The sooner the layer restarts,
the less of this year is reconstructed rather than recorded.