Documentation for the platform products — Ledger Platform, Trade Desk, WhatsApp Automation, Field Operations, Company OS: architecture guides, API references, integration recipes and operational runbooks. Public where possible, engagement-gated where a client’s specifics require it.
What lives here
- Architecture overviews. How each platform is built and why, with the trade-offs named rather than smoothed. The same candour as the teardown series, turned on my own work — if I critique Stripe’s or Nubank’s decisions publicly, mine should survive the same light.
- API references. Endpoints, idempotency rules, error contracts, webhook payloads and retry semantics. Written for someone integrating at 11 PM rather than for someone browsing.
- Integration recipes. The paths people actually walk: connecting Retail ERP to WhatsApp nudges, feeding Company OS from Tally exports, posting into the Ledger Platform from an existing payment stack.
- Operational runbooks. Backup and restore, upgrade procedure, monitoring signals, incident basics — for self-hosted deployments, where operating the thing is genuinely your responsibility.
- Changelogs, with breaking changes announced rather than discovered.
Why documentation is a product surface
Because half the findings in technical due diligence are documentation failures wearing technical costumes. A system nobody can explain is a system nobody can safely change, and the cost shows up as key-person risk, slow onboarding and a rewrite proposed because reading the existing code is harder than replacing it.
So writing this well is both a service to clients and a demonstration of the standard I hold. It is also, frankly, the most effective sales material I have: an engineer who reads the ledger architecture guide and finds it precise has learned more about whether to work with me than any case study would tell them.
The evaluation path I recommend
Read the architecture guide for whichever platform interests you, and read it critically. Look for the decisions I have made explicit and ask whether you agree — the event model, the projection strategy, the choice to keep the chart of accounts in data rather than code.
Then arrive at the call with objections. Disagreement about a specific design decision is a far better first conversation than a walkthrough of features, and it tells us both quickly whether the fit is real. The clients I work best with are the ones who pushed back on something in the docs.
What is deliberately not here
Marketing copy dressed as documentation. Screenshots substituting for explanation. And roadmap promises, because a roadmap in documentation reads as commitment and I would rather under-promise in a place people treat as factual.
Where a platform is at preview status — Ledger Platform, Trade Desk, Portfolio Manager, Company OS — the docs say so at the top rather than in a footnote, including what specifically is not yet self-serve. That honesty is the point of having the tag at all.
How the docs are structured
Each platform follows the same four-part shape, so knowing one means knowing all of them.
Concepts — the model in prose, with the reasoning. What an event is in this system, why balances are projections, what the idempotency key is scoped to. Readable in twenty minutes and sufficient to hold an informed opinion.
Reference — every endpoint, field, error and webhook, generated from the source so it cannot drift from behaviour.
Recipes — task-shaped walkthroughs for the integrations people actually build, written as a sequence rather than as a feature description.
Operations — deployment, backup and restore, upgrade paths, the monitoring signals that matter and what each one means when it fires.
The separation is deliberate: someone evaluating reads Concepts, someone building reads Recipes then Reference, and someone on call reads Operations. Documentation that mixes those audiences into one long page serves none of them.
Related reading
/products/ledger-platform — the most documented platform · /services/delivery — where documentation failures surface as diligence findings · /blog/ledger-design — the public version of the ledger architecture · /products — the full catalogue
Read first, ask second
Reading documentation before buying is exactly the right instinct. Start with the ledger architecture guide, then bring the hard questions. /contact — padh ke aao, sawal tez honge, and that is a good thing.
Questions I actually get
Are the docs public or gated?
Architecture guides and API references are public wherever they can be. Deployment runbooks and anything containing a client's specific configuration are gated to that engagement. The default is open, because documentation you can read before buying is the most honest sales material available.
Can I evaluate the ledger platform from the docs alone?
That is the intention. The architecture guide explains the event model, the posting invariants and the projection strategy in enough detail for an engineer to judge whether it fits — and to disagree with specific decisions, which is a more useful conversation than a demo.
Do the docs cover self-hosted operations?
Yes — backup and restore, upgrades, monitoring and incident basics, because self-hosted deployment means you operate it. Sovereignty includes the operational burden, and pretending otherwise would be selling the benefit while hiding the cost.
How current are they?
Versioned alongside the platform they describe and changed in the same commit as the code. Documentation maintained separately from code drifts within two releases, which is why it lives in the same repository.
Is there a changelog?
Per platform, with breaking changes called out plainly rather than buried in a list of improvements. A breaking change discovered during an upgrade is worse than one announced loudly a version earlier.