Dharmakarma — KN Swami

the long view

Religious texts are the original distributed system. Copied by hand for a thousand years, fragmented across temple lineages, lost a paragraph at a time when a generation forgets to pass them on. The Vedas survived because Brahmin families memorized them with mnemonic redundancy that put modern error-correcting codes to shame. The Karmakanda — the practical liturgy of how to actually do a Vedic ritual — has had a rougher run. It's mostly in the heads of senior priests, scattered across handwritten notebooks, mismatched between regions, and quietly disappearing as fewer young people enter the priesthood.

Dharmakarma is one priest's project to put what survives into one place that doesn't depend on one person's memory.

what's in it

The app is an iOS library covering:

• Sanskrit source texts — the Dharmasastra (the dharmic legal-philosophical canon) and the Karmakanda (the ritual procedure manuals) — with side-by-side English and Nepali translations.
• Step-by-step ritual guides for life events: weddings, last rites (Antyeshti), thread ceremonies (Upanayana), daily worship (Sandhyavandanam), specific homas and yajnas.
• Authentic mantras, each verified against multiple lineages rather than published from a single source. Where lineages diverge — and they do — both versions are shown with attribution.
• Audio recitation for mantras that have a specific meter (chhanda) where pronunciation matters more than the written form would suggest.

The vision is closer to "Wikipedia of Karmakanda" than "ebook" — but with editorial guarantees a Wikipedia model can't make. Every entry has a named priest who vouches for it.

a three-surface product

The product ships in three pieces, each pointed at a different audience:

• A mobile app for the priest at a ritual, the devotee on a pilgrimage, or the student following along on a phone in a quiet corner of a temple.
• A web reader for desks, classrooms, and the institutional user — temple offices that catalogue and cross-reference texts.
• A backend that curates the canon and feeds both clients from one source of truth.

All three talk to the same content store, so an entry edited by the editorial team appears in mobile and web within a beat.

my role

I owned the backend by myself. That meant the data model, the API, the editorial pipeline, the auth and roles, the search, the file/media handling, the export tooling, and the deploys. I worked alongside the mobile and web teams to define contracts, review their PRs, and unblock the trickier integration points — but the server side, top to bottom, was mine.

what kind of problems

A digital library for ritual texts isn't a "post a CRUD app and call it done" project. The problem shape was the interesting part:

• Multilingual content as a first-class citizen. Each entry exists in Sanskrit (Devanagari), English, and Nepali. They aren't translations of one another in the loose sense — they're parallel canonical forms, each with its own attribution, and the API has to expose them as one record without flattening any of them into a "primary" language.
• Editorial review, not crowdsourcing. Every entry has a named priest who vouches for it. That constraint flows into the data model (attribution is a column, not a nice-to-have) and the workflow (drafts go through review before they're published; previously-published entries can be revised with version history).
• Offline-first reading on the client side. The mobile app is designed to work inside temples and homes where signal is weak or absent. The backend's job is to make that practical — content has to be downloadable in coherent chunks rather than streamed page by page, updates need to be small deltas rather than full re-pulls, and the API has to behave well under flaky reconnection patterns.
• Search across scripts. A user typing "wedding" in English, "बिहे" in Nepali, or "vivāha" in transliterated Sanskrit should find the same entry. That requires a multi-key search representation on the server and a normalization pipeline that treats Devanagari, transliterated Sanskrit, and English as comparable inputs.
• Long-form export. Some users want printable PDFs or EPUBs of a ritual procedure they can carry. The backend handles export at request time, so the printable artefact reflects the latest reviewed text rather than a snapshot from whenever the app was last updated.

what supporting the apps looked like

The mobile and web teams were earlier in their careers than I was, and the integration touch-points (auth, real-time updates, media uploads, offline sync) are exactly where less-experienced devs get stuck. So the support work was concrete:

• Contracts before code. I wrote OpenAPI for every endpoint and walked it through with both teams in review before either started building. The mobile and web sides could mock against the spec while I built the real endpoint, so neither was waiting on me.
• Pair-debugging on the live flows. The first time the mobile app tried to do a real-time content sync end-to-end, things didn't behave the way the model suggested they would. We sat together with the network panel and the server logs side-by-side until the model and reality agreed.
• Code review with reasoning. Not "change this to that" — "change this to that because…" People grow from explanations, not rubber stamps.
• Off-loading triage. I trained the leads on each side how to read the server logs and the editorial workflow state so that production issues from their side could be triaged without escalating.

the stack, in shape

• Backend: Node.js with a typed HTTP layer, a relational database with an ORM, real-time updates via WebSocket, S3-backed media, push-notification fan-out, and an export pipeline for downloadable artefacts.
• Web reader: A modern React/Next.js front end aimed at long-form reading — typography matters more here than anywhere else.
• Mobile app: Flutter, talking to the same backend, with offline-first storage so the app keeps working in airplane mode.

what stays with me

Two things from this project that I think about often:

1. Religious software has surprisingly modern requirements. Multilingual content, careful typography, attribution metadata, editorial review, offline-first, downloadable exports. If you can build a respectful religious-text product, you can build almost any content product.

2. Trust is the product. Nobody opens this app to find out whether a mantra is authentic — they open it because the editorial process behind the app is trustworthy. The code is the wrapper. The named priest at the bottom of every entry is the product.

If you're someone who wants the texts themselves, the App Store link is the start.