Anand Mahindra
Chairman, Mahindra Group. Padma Bhushan, 2020.
Private & Confidential · Draft v1.0 · Cognisho
Now scroll down
The Lawrence School · Lovedale · Est. 1858
The situation
Every Old Lawrencian is already a member. The Association does not have a recruitment problem. It has an identification problem — and everything downstream of it.
Who is in the register
Industrialists, admirals, ministers, hoteliers. The Association's asset is not a mailing list — it is the standing between the names on it. A platform's only job is to make that standing usable.
…and to make it usable by an OL who does not already know whom to ask.
Chairman, Mahindra Group. Padma Bhushan, 2020.
AVSM. The first Old Lawrencian to hold Army Commander rank.
PVSM, AVSM (Retd.), Indian Navy.
Minister, Government of Tamil Nadu.
Founder of Kerala's leading eco-hotel group.
Ati Vishisht Seva Medal, Indian Navy.
Drawn from public record. The platform's directory is member-maintained and consent-based — no OL appears anywhere they have not chosen to appear.
Where it stands
Requirements as stated
If we have any of these wrong, the rest of the document is wrong too. This is the first thing to correct.
Association structure
The platform architecture mirrors the organisation, not the other way round. Chapters are member-run within a centrally governed system — not independent silos.
The master registry and the SOPs each chapter runs on. Technical, financial and procedural support. HQ is the financial backstop for the entire operating system.
Any funds raised or spent flow back. Reporting rolls up. Any support a chapter needs routes through HQ rather than around it.
Open question, carried forward from the chapters brief: are regional and passion-based chapters the same underlying entity with a type flag, or genuinely different structures? It changes how Wave 1 (Communities) and Wave 3 (chapter-level ledgers) are scoped, so it wants answering before Wave 1 is costed.
The approach
Alumni platforms fail the same way every time: one enormous application, commissioned all at once, delivered eighteen months later to a community that has stopped waiting.
We propose the opposite. A modular suite of applications sharing one central database, released in stages, each stage sequenced against Return on Engagement rather than against a Gantt chart. If a module is not earning its place, it does not get built.
Everything below is live. Drag it, type in it, break it.
Scope is not fixed ten months out and then defended. On the 25th of every month we meet, review what shipped, and agree together what the next month contains — the scope, the priorities, the trade-offs. OLA sets the direction every single month, in the room, with us.
Which means a change of mind is a conversation on the 25th, not a variation order six weeks later.
Try it · 01
Move the sliders. This is the model we would hold ourselves to.
Illustrative model, not a forecast or a commitment. Every coefficient is exposed and editable — we would replace them with OLA's own historicals before any of this is used to make a decision.
Try it · 02
Four houses. Sixty years of unfinished argument. Onboarding becomes a house fixture, and the register fills itself.
Points accrue for verifying your own record, adding a batchmate, RSVPing to the December '26 reunion, and uploading to the archive. Weighted so that a small batch can still win.
Try it · 03
Ask the question an OL actually asks. The Personal Graph answers it by relationship, not by search term.
Ranked on shared batch, shared house, shared chapter, geography and second-degree overlap. An OL only ever appears in another OL's graph with their consent.
Try it · 04
Natural-language search across members and documents — with the API billed to OLA's own account, metered in the open, and switchable off by OLA at any moment.
Cap set by OLA. At the cap the feature pauses itself rather than billing on. Cognisho never sits between OLA and the model provider.
Try it · 05
Edit any figure. The reunion stops being a WhatsApp thread and becomes a budget with an audit trail.
| Line | Amount |
|---|---|
| Income | |
| Attendees confirmed | |
| Ticket, per head | |
| Sponsorship | |
| Costs | |
| Catering, per head | |
| Venue & production | |
| Merchandise & archive | |
| Surplus to the Association | — |
Figures are placeholders for demonstration. QR attendance ties each head counted here to a verified OLA ID, so the P&L reconciles against the door.
The build
Shyam, Johnny, Revanth —
this is the ten months.
Almost every downstream feature depends on one verified identity per alumnus, and that identity has to be created with consent already attached. Building the visible things first means retrofitting identity and consent later, under a live member base, at several times the cost.
So the sequence below is not a marketing order. Waves are ordered by what the next wave cannot be built without, across ten months — forty-three working weeks.
Every wave runs the same way. Design first. Nothing is built until OLA has seen the design and approved it. Only then does development start, followed by testing, and then the wave goes to production — live, in front of members, before the next wave begins.
The ten months is measured against the user stories once they are locked at the start of the engagement. If something has to change after that, all parties sit down together, agree it, and the timeline moves accordingly. How that works.
Forty-three working weeks across ten months. Week counts are our estimate against this wave table, not the source document's — its figures are keyed to an earlier sequence. They firm up wave by wave as each design is approved, and each month's actual scope is set together on the 25th.
The spine, the identity, and somewhere to land once you have one.
Exit criteria: one clean record per alumnus with a provenance trail, a permissions model that can express “Bangalore Chapter Head, until March 2027”, and a WhatsApp message to a verified digital ID in under three minutes.
School master records, Squarespace data and chapter spreadsheets merged into one schema. Deduped, phone numbers normalised to E.164, conflicts flagged for human review. Expect this to be the slowest item in the programme.
First-class tables, not columns bolted on: who consented, to what purpose, when, against which notice version, and how they withdrew it.
Roles modelled as (person, role, scope, valid_from, valid_to) from day one — so a Chapter Head role expires at end of term and an Election Committee role is live only during the poll window.
Residency, encryption, retention and erasure agreed in writing before any code is cut.
AES-256 at rest, quarterly third-party vulnerability scanning, automated secure cloud backups, and RBAC paired with MFA across all roles. Each is substantial infrastructure work, not a configuration toggle. Costed and scheduled as its own line item; secure cloud backups are priced separately and are not in base scope.
WhatsApp and mobile OTP matched against the master registry, issuing a Unique OLA ID and QR-coded digital ID card.
Mobile-match rates will not be 100% for a 4,000-person body with ageing records. Admin review queue plus a peer route — batch vouching, house-and-year attestation — so nobody is locked out by a stale phone number.
Consent notice, granular directory visibility toggles, LinkedIn auto-fill, "12 of your batchmates are already here", and a single "Hi" that lands you in your batch community. Points and leaderboard tied to real actions.
Automatic batch groups, passion-based groups, chapter announcements, posts, comments, polls, and a privacy-first directory masked by default.
View, correct, withdraw consent, request erasure — by the member, without an email to anyone.
The first visible return — which is what keeps sponsorship for the rest of the programme.
A Chapter Head runs their own event end to end without OLA HQ in the loop.
RSVP and pay in one step. Razorpay — UPI, cards, bank transfer.
Scan in, with OLA ID as the fallback. Attendance reconciles against the door, not a clipboard.
Task costing and a live budget view during planning; money raised versus money spent, published after.
Donate to an event you cannot attend.
Photos tagged to the event at upload, so they are findable in five years.
Every chapter’s events in one view — monitoring without micromanaging.
Content, media, historical registrations, order history. Sequenced here on the assumption that back-office work follows revenue-facing work. If OLA would rather migrate existing assets first, this moves earlier — an open sequencing choice, not a fixed decision.
The unglamorous half that decides whether the rest survives volunteer turnover.
Event organisers raise requests; treasurers review and e-sign. Auditable trail on every spend.
A New York chapter buying from a US vendor gets its own vendor list and purchase records, scoped to its region, still rolling up into HQ’s central ledger. One system with chapter-scoped views, not a separate system per chapter.
Send RFPs to multiple vendors and compare responses, optionally AI-assisted, so selection rests on evidence.
Vendor agreements and proposals, indexed — so institutional knowledge survives a change of committee.
Financial responsibility distributed without handing everyone full access.
Answering the question an OL actually asks.
Connections surfaced by shared batch, house, chapter, interest and location — not by search term.
Travel-aware suggestions, which is the single most requested thing an alumni network can do.
What you do now feeds discovery, so others find you without you broadcasting.
Official merchandise, then peer-to-peer, then trust.
Shopify storefront with Razorpay checkout. Razorpay only for this phase — other gateways, including Dodo Payments for international transactions, are a separate later item.
Low-stock alerts, cart abandonment and re-engagement triggers. This is what “marketing” means here: moving inventory the Association has already bought, to generate revenue — not brand awareness.
List an item, or post that your business is open for inquiries from fellow OLs.
Every listing passes a moderation gate before publication; sign-ups cross-referenced against school master records. Documented content policy, appeals path, moderation audit log.
Listings from your batch or chapter surface first, with signals like “3 people from your batch bought from this seller” — a trust indicator that works before any star rating exists.
Encrypted document repository on Cloudflare with signed expiring URLs, and a per-document AI-read toggle for confidential material.
Deliberately last. Lowest tolerance for identity error, highest reputational cost on failure.
Voting rights bound to the verified OLA ID.
Election Committee roles live only during the poll window, using the Wave 1 permissions model.
AGM registration, secure portal access and schedule reminders over the channel built in Wave 1.
Results published automatically, without an editing step between count and publication.
Admin-only. Buildable independent of the member-facing waves.
Runs alongside the waves; not on the critical path.
Approval and workflow application for purchase orders and administrative requests, with e-signatures and a full audit trail.
Feedback capture by point-and-click and screen recording, installed on OLA’s site so the committee can report a problem without writing an email.
Flagged rather than guessed. Both need a decision from OLA before they can be sequenced.
Unscheduled until OLA assigns them a wave.
Donation flows with transparent progress bars, anonymous or public attribution, receipting and tax documentation, donor CRM segmentation. This module was in the original scope but dropped out of the last agreed wave table. KYC and AML checks on campaigners and significant donors are compliance-heavy work — involve counsel before committing to any scope or timeline.
Plain-language querying across members and documents, with API cost borne directly by OLA and a dashboard to view spend and pause the feature. Gated on data volume, not on time. Search is only a differentiator once there is a real corpus to search — profiles, posts, listings. Launched against a thin database it is not a wow feature, it is a dumb one.
Capability detail
Terminology below is lifted from OLA’s own strategy deck and kept intact rather than paraphrased — so it reads back the way it was pitched, and you can see exactly what we think is easy, what is not, and where we disagree.
The backlog
Every wave above is broken down into user stories — what each person needs, and why. Eighty of them across six waves and six roles, from an alumnus logging in with a WhatsApp OTP to a treasurer appointing sub-treasurers with scoped permissions.
We go through these together at the start of the engagement, refine them, and lock the set. The ten months is measured against that locked list — and each wave's stories still pass through the design approval that opens the wave.
80 stories · 6 waves · 6 roles
Before Wave 1
None of these are technical. All of them change what gets built, and all of them get more expensive to answer once code exists.
The Association, the school, or both jointly? This determines who signs consent notices and who carries breach liability. A governance decision, not a technical one — and the first domino.
At 4,000 members a fully bespoke platform may be over-engineering. Shopify plus a headless membership layer plus the WhatsApp Business API may cover most of scope. Worth a costed comparison before committing — and we will run it even though the bespoke answer is the larger engagement for us.
Both required under DPDP. Counsel should confirm the currently applicable deadlines rather than relying on the deck.
4,000 active implies a larger total roster. Which population migrates, and what is the policy for the inactive tail?
The highest-risk item in the plan. Delivering Waves 1–4 well and running one more election cycle manually is a defensible choice, and we would rather say so now than discover it in Wave 6.
The ask
Nothing else is blocking. The Data Fiduciary question first — it decides who signs the consent notices, and every record we write afterwards depends on the answer.
Johnny John · President
Shyam Nair · Product Lead & Treasurer
Ajjay / Revanth · Administrator
Commercial & process
OLA has said it will assess proposals on stakeholder benefit rather than direct cost comparison. We will support that with a benefits-per-feature report, so the committee can defend the decision on its merits.
We will push back — respectfully — on features that do not serve the objective. Final decision authority stays with OLA in every case. You are buying an argument, not an order-taker.
AI usage is billed to OLA's own provider account. Cognisho does not mark it up, does not route it, and cannot see a margin in you using it more.
DPDP Act implementation by May 2027 is the target. GDPR, CCPA and every other regime are explicitly out of scope for the phases priced here. If OLA later requires an additional regime, we review it and return with a new quote and effort estimate before any related work begins.
Razorpay only — UPI, international cards, bank transfer. Dodo Payments and any other gateway are a separate, later-scoped item, pending the dedicated call.
This proposal comes by email, not WhatsApp, for privacy. For the longer collaboration we would move to a shared workspace.
The clock that is already running
The DPDP Act implementation deadline, and the reason Wave 1 is the spine rather than the storefront. A member database holding personal data on 8,000 people has to be compliant by then, and consent cannot be retrofitted under a live member base.
The engagement
What that buys is not a number of hours. It is a team that treats OLA as the only client in the room.
One named person who knows the Association, sits in your meetings, and is accountable for the engagement end to end. Not a ticket queue. Not a rotating account handler who needs the history explained each time. You will have their number, and they will already know what happened last month.
Every screen, every flow, every design decision comes back to you before it is built, and your input changes it. You are not handed a finished product to approve at the end. You shape it while it is being made, in the detail, whenever you want to.
We sit down together and set the next month: what gets built, what waits, what changed. Direction stays with OLA at a monthly cadence rather than being locked at signature and defended for a year.
The user stories are already written; that is what we are proposing to build. At the beginning of the engagement we go through them together, refine them, and lock the set. From that point the ten months holds against the locked list, and the monthly meeting on the 25th sequences the work inside it rather than renegotiating it.
If part way through OLA decides something has to change — more on Events after Events has shipped, the waves in a different order, something dropped — that is fine, and it is not a corridor decision. The respective parties sit down together, we agree what changes, and the timeline moves accordingly. New scope means new time, and we will tell you how much before anything is committed, not after.
We will tell you when a feature is not worth building, when the assemble option beats the bespoke one, and when a wave should be deferred. Final authority stays with OLA in every case — but you are buying an argument, not an order-taker.
Fee is exclusive of GST. AI API usage is billed directly to OLA's own provider account and is not marked up by Cognisho. Third-party costs — hosting, Shopify, Razorpay, WhatsApp Business API, secure cloud backups — sit with OLA and are quoted separately as they arise.
The school motto
1858 · LOVEDALE · 2026