Pragati
If everyone could see the whole board, most status meetings wouldn't need to
exist. So here, everyone sees the whole board.
For reviewers: Solo-built work-management platform in production at Alembic Pharmaceuticals (5 teams, ~40 users). ~62k lines TypeScript, 294 unit tests, 5 E2E specs. Key decisions: no AI on scoring paths, hand-rolled auth, append-only audit trail, single permissions table for UI + API.
Run your own in ~10 minutes — free tiers end to end, first account created
in the browser:
The full path — including using it solo, e.g. tracking an exam with a hard
date: docs/SELF_HOSTING.md.
Live app — look around with a demo
account, nothing to set up:
These are public demo accounts on a public demo workspace — don't put anything
real in them. Details: docs/DEMO_ENVIRONMENT.md.
60 seconds, in motion
What it is
Project and task management for teams, built on one question: why does a
contributor only get to see their own slice? There's no good reason — so here
they don't. Everyone gets a view of everything moving in their team, plus a
truly private personal space nobody else can see, admins included. Born in
pharma quality work, so every change is recorded and nothing is quietly
deleted; the model itself works anywhere. Invite-only — there is no public
sign-up. Request access at
pragatialm.vercel.app/request-access.
| Role | What they see |
|---|
| Contributor | Their tasks, their day, and private personal projects invisible to everyone else. |
| Team Lead | Their teams, projects and tasks; assigns work; tracks progress. |
| Admin | The whole workspace, user management, the audit log. |
How the product thinks
These aren't features so much as defaults:
- The board is the product. Overdue, blocked, due, owner. Everything else
is optional chrome.
- Think at a whiteboard, not in a deck. A full-page drawing surface, in
the main nav for every role, private to its owner.
- Celebrate finished work. A toast when a task closes. Confetti when a
phase closes. A surprise when the whole project clears.
Engineering at a glance
Solo-built, in production. These numbers come from the repo itself — npm test, find, git log — not from a pitch:
| |
|---|
| ~62,000 lines of TypeScript | 93 API route handlers |
| 19 Mongoose models | 294 unit tests + 5 end-to-end specs, all green |
| 675+ commits of real iteration | Typecheck · lint · test · build gated on every push |
Decisions worth a closer look — each one started by questioning a default:
- No AI on any decision path. The obvious move is "add AI." Rejected: the
triage, slip-risk, and forecasting engines (
src/lib/ai/*) are plain,
deterministic, unit-tested code. You can't debug a model weight; you can
debug a line.
- One permissions table drives both the UI and the API.
src/lib/permissions.ts is the single source of
truth, imported by both sides — so what a role sees and what it can do can
never disagree.
- A natural-language quick-add with zero dependencies. Type "Ship the QA
report urgent tomorrow" and a small, fully tested parser
(
src/lib/quickAddParse.ts) extracts the
date, the priority, and a clean title. No library needed.
- Early warning, learned per person. Open work likely to miss its date
gets flagged before it does — from each person's own delivery history, every
score traceable to a line of code
(
src/lib/ai/slipRisk.ts).
flowchart LR
Browser["Browser (client components)"] -->|httpOnly JWT cookie| Edge["Next.js route handler / RSC"]
Edge -->|validateSession| Auth["lib/auth + lib/jwt"]
Edge -->|await connectDB| DB[("MongoDB / Mongoose")]
Edge -->|Zod validate| Validations["lib/validations"]
Edge -->|logOperation| Audit[("Audit log\n(append-only)")]
Edge -->|serialize| Browser
Reads go straight from server components to the data layer; every change flows
through a validated route handler and lands in the audit trail. Deep dive:
docs/ARCHITECTURE.md · how it scales:
docs/SCALING.md.
This is the beginning of the README. Read the rest at the original. Read the full README ↗
