What this is, who it is for, and what to build first

A shaping document. Written 9 August 2026, corrected the same day. For Shemeer. Nothing here is decided — the decisions are listed at the end.

⚠️ Correction to the earlier version of this document

An earlier version of this document recommended dropping Open Collective. Its central reason was wrong, and the verdict below is a fresh one, not a defence of the old one.

The earlier version said Open Collective could not show a donor anything — that a donor on a private collective would see nothing at all. That claim was reached by reading the code. It has since been disproved by running it, on the live fork, with a real login:

The rule that permits it is a deliberate one, and its own note in the code says so: an order is blocked when its destination is private unless the viewer has a direct stake in it — contributor, creator, or fiscal host admin. A donor is the contributor. She keeps her own history even when the recipient has gone dark.

So: private collectives, donor accounts, contribution receipts and one login spanning several organisations all work, with no code changes. The platform is not disqualified on capability.

Three things the correction does not touch, and they still stand:

1. The part of Open Collective that is genuinely hard and genuinely excellent is fiscal hosting — one organisation holding and disbursing money for many. This model rejects fiscal hosting outright.
2. It is not the book of record. Each organisation's CA files from Tally or Zoho Books.
3. Donor-only transparency is worth nothing unless donors come back. That is unchanged and it is still the hardest problem in this product.

And one true finding from the earlier version stays, demoted: donor-only updates really do die on a private collective — the code turns the Updates feature off for private accounts entirely. Shown that trade, the Builder said the smaller thing was "good enough for now", so it is a known limit rather than a blocker. It is recorded in section 5.

The old 90-day kill test is dead for a different reason than before: it required public pages, and there will not be any. A replacement is in section 7.

What being wrong cost. One shaping round, and a "drop it" recommendation that would have thrown away something usable. Caught in hours, before anything was built on it. That is the cheapest possible version of this mistake, and it is only cheap because the fix was a measurement rather than an argument. The lesson is narrow and worth keeping: reading permission code tells you what a rule says; only running it tells you which rule applies.

1. What changed this week, and what it costs

The premise that changed: transparency is no longer public. It is for donors only, permanently. In your words:

"Priya now has a login with our platform. she can go back in there and generate her donation reciepts. download them. see updates about the project she donated to. and find other projects. Only donors will have visibility. transparency is only for the donors. not for everyone at this point."

Asked whether that was a first phase, you said permanent. Three further corrections came with it: organisations get paid, never individuals; no organisation joins expecting to use FCRA here; storyboards as diagrams.

Three things this deletes outright

One thing it deletes that nobody has said out loud yet

Priya can no longer show anyone what her money bought. The last frame of the old storyboard was her forwarding the page to the friend who sent her the story. Under donor-only visibility that friend sees nothing on that page. The sharing loop — the growth mechanic, and the top of the old ladder — is gone by definition.

That is not an argument against your decision. It is the price of it, and it should be paid knowingly rather than discovered in month four. What the friend can be shown is settled in section 4.

What being asked this late cost

The fork was set up, a Razorpay payment provider was built inside it, and two shaping rounds were written around a public ledger. The Razorpay week was written off by the config-only rule. The centrepiece of the last document — the public page, the forwarding loop — is written off now. Call it a fortnight of work and two rounds of thinking. Cheap, because nothing has been announced and no donor has given a rupee. It would not have been cheap in three months.

2. What Open Collective can and cannot do, now that it has been measured

This is the whole factual basis for the verdict. Two columns, and the second one is what decides it.

It can do these, today, with no code written

It cannot do these, and no setting reaches them

One thing that is read but not run, and it decides everything

Under this model no money ever passes through Open Collective — it lands in the organisation's own Razorpay and its own bank. So the helper app has to tell Open Collective a gift happened.

Reading the code, there are two doors for that, and they do not agree:

• The ordinary contribution path never checks whether the destination is private. It looks like it would work.
• The "record a payment that happened elsewhere" path — the one this model actually wants — is refused for an arbitrary donor when the account is private, unless the caller is the platform's own root operator.

⛔ That has not been run, and after this week's correction I will not treat reading as knowing. It is the single test that settles the platform question, and it is an afternoon:

The test. As an ordinary donor account that administers nothing, get one ₹500 contribution recorded against a private collective through the API, then read it back as that donor. If the write is refused on every route, Open Collective has nothing left to do here and drops. If it works, the shape in section 3 stands. Owner: builder.

3. Does Open Collective survive? Yes — behind the wall, not in front of it. Needs your yes.

Recommend: keep it, as the organisation's own book that Devi and her colleagues keep. Do not make it Priya's product. Conditional on the test above.

This is not the old verdict flipped. It is a smaller claim in a different place.

Here is the argument in five lines.

1. Everything a donor meets has to be built in the helper app anyway. The stranger's giving page, because Open Collective will not serve an anonymous visitor a single byte of a private account. The "what your money bought" page, because a donor cannot see a bill. The 80G certificate and the 10BD file, because they are Indian law. The email that fires when something is bought, because nothing in the platform fires on that event.
2. But the admin side is a genuinely good fit, and that is new. An expense with the shop's bill attached, two people approving it, and a ledger that balances afterwards is roadmap item 8 — above the release line — and it is precisely what this software already does well, on a private account, with configuration only.
3. Fiscal hosting is still rejected, so the ceiling is low. The thing Open Collective is famous for — one body holding money for many — is the thing this model refuses. You are keeping the filing cabinet and declining the safe. That caps how much value it can ever add here.
4. It is still not the book of record. Each organisation's CA files from Tally or Zoho Books. This is a second set of books that no filing comes from, and a second set of books that nobody is required to keep correct is a set of books that eventually is not.
5. It costs four services on a box that cannot comfortably take them, from a codebase nobody here wrote, with no supported install path, and stock secrets published in its own public repository that must be regenerated per instance.

So: keep, narrowly. Lines 1 and 3 are why it must not become the donor's product. Line 2 is why dropping it outright would throw away real work. Lines 4 and 5 are why it must never grow past the back office.

Cost of my being wrong in the keeping direction. You carry four services and an unowned codebase for an expense screen six people open, and Devi has a second login on her Tuesday — which makes the most fragile frame in the whole storyboard slightly worse. Recoverable: the helper app talks to it through one narrow seam, and replacing that seam with its own tables is days, not weeks.

Cost of my being wrong in the dropping direction. Roadmap item 8 — the approval flow, the attachment, the ledger that balances — gets built by hand, badly, in the middle of the release. That is the more expensive mistake, and it is the one the earlier version of this document was about to make.

The line that protects you either way

One seam, named now: the helper app writes contributions in, and reads expenses back out. Nothing else. No donor ever holds an Open Collective login. No page of it is ever shown to anyone outside the organisation. If that seam ever needs to widen, the answer is to drop the platform, not to widen the seam.

⛔ And the standing rule is unchanged and not up for discussion: no new features in Open Collective's code, ever. Settings and configuration only; everything else is the helper app beside it, talking to its API. That rule already cost a week of Razorpay work; it does not get re-litigated because a measurement went our way.

What is still adopted rather than built

Not a decision I take — architect runs the alignment gate. Naming candidates so it is not re-derived from nothing:

4. What a stranger sees before she has an account

This was the sharpest open question, and the measurement answers most of it.

An anonymous visitor asking Open Collective about a private organisation is refused outright — not a stub, not a name, not a progress bar. Nothing. Therefore:

The giving page cannot live in Open Collective. It is a page the helper app serves, on our own address, that a stranger opens with no account and no login.

That is not a compromise; it is what the config-not-fork rule already assigns to the helper app — the country's payment rail, and the checkout itself. It simply is not optional any more.

Recommend for what that page shows: the story, the ask, and the progress — "₹23,400 of ₹40,000 raised". Everything else is behind a login: the ledger, the bills, the names, the updates.

Two details that follow, and both matter:

• The progress number is published by the helper app from its own record. It is not read live from Open Collective, because an anonymous read of a private account is refused. Anyone building this must know that before they wire it, or the page will be blank in production and fine in testing.
• The forwarded link lands on the giving page, not on a locked door. Priya cannot show her friend what her ₹500 bought. She can show her the thing that needs money. That is the largest surviving fragment of the sharing loop and it costs nothing.

A progress bar reveals nothing about any individual and is the single strongest reason a stranger gives. If you mean that even the total is private, say so — and the giving page loses its best device. This is decision 3.

5. What this is now, in one sentence

The product changed category this week. It is not a transparency platform any more. It is a donor account.

Give to one of these Indian organisations, and you get a permanent account that shows you exactly what your money bought — with the bill.

Who it is not for. The general public, journalists, funders doing diligence. Individuals who want to be paid. Donors outside India. Organisations that want somebody else to hold their money. Anyone looking for a payment gateway.

The thing that is structurally different, and it matters more than anything else here

Public transparency works even if nobody looks. It is a signal. It sits there being checkable, and that is most of its value.

Donor-only transparency is worth exactly nothing unless donors come back. It is a locked room. If Priya never returns, the entire justification for this product is a room nobody enters.

So the whole thing rests on one behaviour: the return visit. That is a harder product problem than a public page, and it is what the build has to be aimed at. The correction does not soften this one bit — it only means the room now has a working door.

The known limit, recorded plainly

Donor-only updates die on a private collective. The platform switches its Updates feature off for private accounts entirely, so "a post only my backers can read" cannot come from it. Shown the trade, the Builder said the smaller version — she sees her own donations and her receipts — is "good enough for now." So this is a limit, not a blocker. If donor-only updates are ever wanted, they are a helper-app page (roadmap item 12), never a change to the platform.

What you gain by donor-only, which is real

The second organisation's first objection was never "how much work" — it was who gets to see my numbers. Donor-only makes that a much easier yes. And "you can see this because you gave" is a genuine reason to give, which a public page can never be. Transparency stops being marketing and becomes membership. Better product for organisations, worse one for growth.

6. Three storyboards

Everyone here is invented. Priya, Devi, Nusrat, Rahitha and Chalanam Foundation are illustrative characters written to test the product, not real people or real organisations, and nothing said about them — including any registration or tax status — describes anybody actual.

The low scores in these tables are the point. Where the feeling drops is where the product fails.

A — Priya, and the year after her ₹500

Priya — her ₹500, and the year after it

The forwarding frame is no longer a 1, and that is the correction's only real effect on Priya. The friend still cannot see the bill. She can see the thing that needs money, which is the part worth forwarding anyway. The reason to exist is the fourth section. Anyone can build the second section in an afternoon with Razorpay. Almost nobody builds the fourth.

B — Devi at Aikyam, who is the whole product's weakest link

Devi at Aikyam — the person everything quietly depends on

Read the third section twice, and note the frame the correction adds. Keeping Open Collective means Devi has a second login, in a dashboard designed for open-source collectives on the other side of the world. That is the honest cost of the recommendation in section 3, and it lands on exactly the person the product can least afford to lose. Under a public ledger a stale record is embarrassing and somebody complains. Under donor-only it is invisible, and the only symptom is that Priya's email never arrives — which looks like nothing at all.

Note also that Rahitha never receives money. Aikyam buys drums for its own programme, from its own bank, and Rahitha never floats a rupee. That is the whole of what survives of the old storyboard B.

C — Nusrat, deciding whether to bring the second organisation

Nusrat at Chalanam Foundation — deciding whether to join

The second section is much easier to say than it was last week, and that is the one clear win from your change. The last two frames are the new cost of collecting PAN from her profile rather than at checkout — see decision 6.

Where the money and the information actually go

Open Collective now appears, and it appears exactly twice. One write in, one read out, and no line from it to Priya. That picture is the recommendation. If either of those two lines turns out to be impossible, the box comes out and the helper app grows two tables.

7. The eleven-star ladder

The moment: Priya coming back, and finding out what her ₹500 did.

Why this moment and not the gift. Giving is a commodity — every Indian platform has had a UPI button for a decade, and we will never be better at it, only adequate. And now that nothing is public, the old moment — a stranger reading the ledger — cannot happen at all. What is left is the return visit, and it is the only thing that makes donor-only transparency worth anything.

What the correction did to this ladder: it raised the floor, not the ceiling. Three stars is now free out of the box — a login, a list of her giving across every organisation, receipts to download. That is real and it should be said. But the platform's contribution stops at three, and every rung from five upward is a page and an email the helper app has to write. The product still lives between six and eight, and nothing there got cheaper this week.

Six is the build. Seven is nearly free once six exists — the helper app already knows which gifts paid for which bill, so the sentence is a sentence, not a system.

Eight is the one to fight for, and it is cheap: it is the difference between a newsletter and a product, and it costs nothing extra because the app already knows the moment Devi records something.

Nine, ten and eleven are why you would keep going.

What this ladder rules out. No rung is improved by a shared ledger, a public page, a directory, a platform balance, or by putting Priya inside Open Collective. Every rung above five is one person being told, precisely, what her own money became. That is the product.

8. What to cut

The constraint, so this is a real choice: one build effort, eight weeks, two organisations live before anything is announced. Change the constraint if it is wrong; do not remove it.

Every item is labelled Setting (a switch that already exists), Configuration (information typed in, or an existing screen set up by hand), or Helper app (the separate program beside everything else, which is where all the building happens). Nothing anywhere is labelled "change the platform", because that is not a thing that happens here.

Cut because the premise changed

Cut because no frame needs it, unchanged from before

Events and ticketing · tiers with physical rewards · ring-fenced sub-budgets · discussion threads · automatic bank feeds · multi-currency · cards and Stripe and PayPal · any platform-level payment account including RazorpayX · reimbursing people who had to spend their own money first.

Each of these is a "do not build". None appears in any frame.

What the change adds, which must be said plainly

This is not a simplification. It removes a public page and adds a login product.

Net: the change costs more work than it saves, and it weakens the growth loop. Keeping Open Collective narrowly — for item 8 only — pays back some of it, not all.

9. One roadmap, in order

One list. Helper app unless labelled otherwise.

——— THE RELEASE LINE ———

Where the line sits, and why there

Above the line: a stranger can give in under a minute, the organisation banks the rupee itself, she gets a receipt that is legal, she can come back without a password, she can see what her money bought with the bill next to it, the tax filing is possible, and a second organisation can go live in half an hour.

Item 9 is the one I would defend hardest. Without it this is a donate button with a login, and it has no reason to exist. Note honestly that item 9 ships silent — on launch day nothing has been spent yet, so the first of those emails goes out weeks later. Expected, not a fault.

Item 0 is first for a reason. It is half a day, and it decides whether items 8 and 8a are configuration or three weeks of building.

What someone can do the day it ships

• Priya can read a story, tap once, give ₹500 by UPI in under a minute from a bus, and get a receipt before her stop.
• She has an account she never signed up for, and she gets into it by tapping a link in an email.
• She sees everything she has given, to every organisation, in one place.
• Weeks later, one email shows her the exact thing her money bought, with the bill above the gifts that paid for it, and the sentence already written.
• She can add her PAN once and download an 80G certificate, and every receipt she has ever had.
• She can read an update that only the people who funded that thing can see.
• She can forward the ask to a friend, who can give without an account.
• Aikyam requires two people for anything going out, and hands the CA one file on 31 May.
• Nusrat can put Chalanam live in half an hour without giving up control of a rupee or showing her numbers to anyone who did not give.

What it cannot

• She cannot show anyone what her money bought — only what still needs money. This is the largest single limitation and it is deliberate.
• No monthly giving. Every gift is one-off.
• No money from outside India, for any organisation, ever.
• No unregistered individual receives money. Organisations are paid; people are helped.
• Nobody, donor or otherwise, sees an organisation's overall finances.
• No tickets, no rewards, no directory, no bank feeds, no public page.

The way this fails, and the new kill test

Two failure modes, and the second is the one that closes the product.

One: nobody records what was spent. Money never passes through the software, so nothing forces the record to match the bank. Contributions are safe — they write themselves. Spending is not. And now nobody outside can notice, because nobody outside can look. The only symptom is that Priya's email never arrives, which looks exactly like nothing. There is no clever fix; there is a small one: one named person owns that record, and a monthly check that the two totals agree. Write the name down before launch.

Two: she never comes back. Donor-only transparency is a locked room. The measurement this week proved the door works. It proved nothing about whether anyone walks through it.

The old kill test required public pages and cannot be run. This one can:

By 90 days after the first "what your money became" email goes out:

1. At least half the donors who received one opened it and clicked through.
2. At least one donor came back a second time without being emailed first.
3. Every month in that period had at least one purchase recorded with its bill attached.

Any one of those failing is a finding, not a footnote. If under a quarter clicked, donor-only transparency is a room nobody enters — and the honest response is to make it public, or to stop giving transparency as the reason this exists, not to build more of it. If the third fails, the problem is Devi's Tuesday, and no amount of donor-facing work will fix it.

10. PAN, receipts, and foreign money

Nothing here can be a global rule, because organisations differ. Each gets a record, and the giving page reads that record and behaves accordingly.

A page that promises a receipt an organisation cannot issue is worse than a page that promises nothing.

Two different receipts, and they are not the same document

Worth separating, because the measurement this week made one of them free and left the other exactly where it was.

• The contribution receipt — "you gave ₹500 to Aikyam on 4 September". Open Collective issues this, and a donor can pull her own even when the collective is private. Free.
• The 80G certificate — the one worth money to her, carrying the organisation's registration number and her PAN, and matching what the CA files in Form 10BD by 31 May. Nothing in the platform produces this and nothing ever will. Helper app, roadmap item 11.

How PAN works now, and the hole in it

Under your decision, checkout asks for a citizenship tick only. PAN comes later, from her own profile, once, reused forever. The change makes this genuinely better than the old plan — the old document called PAN-at-checkout "the only thing that cannot be added later", and now it can be, because she has an account.

The forcing mechanism is the certificate: "Your 80G certificate for last year is ready. Add your PAN to download it." People will do that, because it is worth money to them.

The hole: a donor who gives in March and never returns cannot be filed for. Not "is hard" — cannot. Form 10BD needs an identifier by 31 May and she is gone. She loses her deduction; the organisation files without her. That is a real cost of collecting PAN later rather than at checkout, it is visible in the last frames of Nusrat's storyboard, and it needs your yes as decision 6.

How foreign money is blocked

Every organisation refuses foreign money, including one holding FCRA. Permanently, not just in release one — that is your instruction and it removes a whole below-the-line item. Cost of being wrong: Chalanam loses some foreign giving and takes it the way it always has. The reverse error is criminal. Not a close call.

11. The decisions that are yours

Eight. Each with a recommendation and what it costs if I am wrong. The first one is new, it is the biggest, and I am deliberately not taking it.

1. Which product is this — the donor account with the bill, or a receipts-and-history login? The measurement opened a genuine fork, and it is yours.

• A) The donor account with the bill. The fifteen items above. The 6★ and 8★ moments — an email that fires because something was bought, a page where the bill sits above the gifts that paid it. Eight weeks. It is the thing worth building and nobody else is doing it.
• B) The receipts-and-history login. A giving page, a UPI button, and Open Collective's own donor view for the rest. She logs in, sees what she gave across every organisation, downloads her receipts. This is literally what "good enough for now" describes and it is measured as working today. Perhaps three weeks. It has no "what your money bought", no 80G certificate, no triggered email, and it sends her into a product she was never meant to see.

Recommend: A. B is a donate button with a history page, and the ladder says the reason to exist starts at six. But B is real, and if the eight weeks are not there, B in three weeks beats A in never — provided you say out loud that it is a stepping stone, because B's donor lives inside Open Collective and moving her out later is a migration. Cost of being wrong: choosing A when the time is not there means shipping nothing; choosing B and liking it means the product quietly becomes something with no reason to exist.

2. Open Collective: keep it as the organisation's private book, or drop it? Recommend: keep, narrowly — Devi's book and the approval flow, roadmap item 8, and nothing else. Conditional on the test in section 2, which builder can run in an afternoon. It is genuinely good at an expense with a bill attached and two approvals, and that is above the release line. Cost of being wrong: four services and an unowned codebase carried for a screen six people open, plus a second login on Devi's Tuesday — the most fragile frame in the storyboard. Recoverable in days, because the seam is one write and one read. Cost of the reverse: item 8 gets hand-built, badly, mid-release. That is the more expensive error, and it is the one the earlier version of this document was about to make. Either way: the donor never touches it, and no feature is ever added to its code.

3. What does a stranger see before she has an account? Recommend: a helper-app page she can open with no login, carrying the story, the ask and the progress — "₹23,400 of ₹40,000 raised" — with the progress number published from our own record, not read live from the platform. Everything else is behind a login. Cost of being wrong: if you meant even the total is private, the giving page loses its strongest device and conversion drops. Visible in the numbers within a fortnight, reversible in an hour. Not optional: the page itself must be ours. Open Collective refuses anonymous visitors outright, so there is no version of this where the stranger lands on the platform.

4. Is her account created automatically at the first gift, with no signup step? Recommend: yes. Nine seconds of UPI at 9pm on a bus does not survive a registration form, and if she has no account she can never come back — which is the entire product. Cost of being wrong: some people dislike being given an account they did not ask for. Mitigated by saying so in the receipt email and offering one-tap deletion. The reverse error is fatal.

5. Sign-in by emailed link only, no passwords? Recommend: yes. She visits three times a year. She will never remember a password, and a forgotten password is a donor who never comes back. Cost of being wrong: almost none. Passwords can be added later; taking them away later is harder.

6. PAN from her profile rather than at checkout — accepting that some donors are never filed? Recommend: yes, as you decided, with the 80G certificate as the forcing mechanism and a plain sentence on her page telling her what she loses by not adding it. Cost of being wrong: every donor who never returns before 31 May loses her tax deduction and the organisation files a short list. You will see the size of that hole in the first year, and if it is large the fix is to ask at checkout after all. Say now that you accept this, because it will land on a real person in May.

7. The friend Priya forwards to — the ask, and nothing else. Confirm? Recommend: she lands on the giving page, sees the story, the ask and the progress, and can give without an account. She never sees the bill or the ledger. Cost of being wrong: the sharing loop is weaker than a public ledger either way. This is only about whether a forwarded link lands somewhere useful or on a locked door. A locked door loses the gift.

8. "Find other projects" — a directory, or one line? Recommend: one line at the bottom of her page. With two organisations, a directory is a list of two, and it is the kind of thing that quietly grows into a marketplace. Cost of being wrong: trivially reversible. Nobody has ever been lost by not having a directory.

Unchanged, and still standing

RazorpayX cancelled. UPI Autopay applied for now, Aikyam only, on its own account. Foreign money refused everywhere. No individual ever receives money. Two organisations live before anything is announced. Aikyam checks each organisation's book monthly against that organisation's bank statement. No feature is ever added to Open Collective's code.

12. The sentence to keep testing

Give to one of these Indian organisations, and you get a permanent account that shows you exactly what your money bought — with the bill.

Every time something is proposed, ask whether that sentence survives it. It survives receipts, updates, a second organisation and monthly giving. It does not survive a directory, a marketplace, a payment product, holding anybody else's money, a page nobody can get into, or a donor being sent to log in somewhere else.

And when the sentence stops being true, it is not the sentence that is wrong.