WORKSAASPROTOTYPE
WCD Anganwadi
Digital reporting and documentation for Anganwadi centres — a period's data entered once, with the calculation, versioning and print-ready report done by the system. A private product build, explicitly not a government application.
- Next.js 15
- React 19
- TypeScript
- Prisma 6
- PostgreSQL
- Auth.js v5
- Zod
- Tailwind CSS v4
- Vitest
- Service Worker PWA
System sketch — drawn from this build's own structure, not a screenshot.
About this build
WCD Anganwadi is a multi-tenant reporting and documentation system for Anganwadi centres, built around the promise its own README makes: write less, print less, xerox less, calculate less, compile less. A worker records a period once; the system does the arithmetic, keeps the versions and produces the printable report.
The jurisdiction is modelled rather than hardcoded. A sevika is bound to a centre, a supervisor to a block, a CDPO to a project, a district administrator to a district and the SaaS admin to the whole tenant — and every read is authorised against that chain instead of against the identifiers the caller arrived with.
It is a private product build. Its documentation states plainly that it is not a Government of Maharashtra application, not an official WCD or ICDS system, and not a Poshan Tracker replacement. The same honesty is carried into the data: the entitlement quantities it ships seeded with are marked unverified pending the currently applicable government order.
WHAT THIS IS FOR
- Replaces the register-and-xerox cycle for centre reporting: enter once, submit, print.
- Gives a supervisor and a CDPO the same submitted data without waiting for a compiled file to reach them.
- Keeps an auditable history — revisions, workflow events and evidence attachments per submission.
- Keeps working without signal: an offline entry is queued and replayed exactly once when the connection returns.
WHAT YOU GET FROM IT
- Arithmetic moves out of the worker's hands and into the report template, where a mistake is fixed once instead of on every page.
- A submission is unique per tenant, centre, type, period and revision, so the same month cannot be filed twice by accident.
- Access follows the real hierarchy — centre, block, project, district, tenant — enforced on the server before the role is even consulted.
- Generated reports are traceable: each one records the template version that produced it, and carries that template's own disclaimer.
How it is structured
- 28 Prisma models over PostgreSQL, with the geography chain District → Project → Block → Anganwadi Centre, each centre carrying all four scopes.
- Five roles — sevika, supervisor, CDPO, district admin, SaaS admin — resolved from the database on every request, and a suspended account rejected before it reaches a handler.
- Cross-tenant access is blocked first: a jurisdiction mismatch throws before the role check runs at all.
- Auth.js sessions carry a Google provider plus a credentials dev-login used until OAuth credentials are issued.
- Submissions are unique on tenant, centre, type, period year, period month and revision.
- The offline queue dedupes by idempotency key and retries with exponential backoff, so a replayed sync cannot apply the same submission twice.
- Claims, submissions, evidence, profile changes and sync operations all write to an audit log.
- Middleware guards nine page prefixes and routes a newly signed-in user through onboarding before the application.
What it does
- Centre data entry with automatic calculation
- Monthly reporting with revisions
- Supervisor review and return flow
- Print-ready generated reports
- Evidence attachments per submission
- Claim requests
- Notifications and task assignments
- Offline submission queue with idempotent sync
What the worker does
- Signs in and lands on their own centre's dashboard.
- Enters a period's data once and submits it.
- Sees their submission history and any revision returned for correction.
- Carries on without a connection — the queue holds the entry until it can sync.
What the team uses
- A supervisor works by block: open a centre, read the submission, review it, approve or return it.
- A CDPO sees the project and a district administrator sees the district — the same records at a wider scope, not a separate export.
- Reports are generated per submission and printed from the report view.
- Claims raised by a centre are handled as records with an audit trail rather than as messages.
- Notifications and task assignments live in the system, so work is not tracked in a chat thread.
Structural facts
- Data models
- 28
- Prisma models in the application schema, over 9 enums.
- Jurisdiction levels
- 4
- District → project → block → anganwadi centre.
- Roles
- 5
- Sevika, supervisor, CDPO, district admin, SaaS admin.
- Test cases
- 92
- 74 unit and 18 integration; the integration suites skip without a database.
STATUS
In preparation
Screenshots are withheld because every screen available is populated from the project's own demo seed, which labels itself “DEMO ONLY — Sample Cluster (Not Government Data)” and is filled with placeholder names and @example.com accounts. Real captures go up once the system is running on non-seeded data. The CBE, MPR and THR entitlement figures are likewise unverified against a current government order, so no numbers from them are quoted anywhere on this page.
No public URL. The repository carries no deployment configuration, hosting manifest or remote — the system runs locally against a seeded demo tenant, and the Google OAuth credentials real sign-in would need have not been issued yet.
One message — what happens today, and what you want instead. A straight answer within a day, including when it does not need building.
← All work