Week-by-week capacity planning for small agencies.
CapacityLens makes it easy to see who is busy, available or over capacity, then adjust the plan before schedules become problems.
CapacityLens is a deliberately small, self-hosted resource scheduler for agencies that plan work in weekly blocks.
- Plan clients → projects → activities and people → allocations → time off in one visual schedule.
- View a 1, 2, 4 or 8 week window.
- See daily over-capacity, visible-window Utilisation, and a separate 14-day forward warning.
- Include employees, placeholders and capacity-free external partners.
- Keep accounts isolated with role-based access and a SQLite source of truth.
- Import and export JSON, undo and redo changes, and use keyboard-friendly light or dark themes.
CapacityLens is not a:
- budget, billing or financial planning system;
- timesheet or time-tracking tool;
- hour-by-hour scheduling system;
- project-management suite or CRM; or
- mobile-first scheduling app.
Those boundaries are intentional. CapacityLens is for a clear weekly view of resource capacity, not for managing every part of agency operations.
Agency owners, studio or operations leads, resource planners and project leads who need a shared answer to: “Who can take on this work, and when?”
The demo is editable but temporary. It runs in memory, resets on reload and never stores schedule data in browser storage.
corepack enable
pnpm install
pnpm run dev:demoOpen http://127.0.0.1:5173.
Node 24 and pnpm are required. The pinned Node version is in .nvmrc.
nvm use
corepack enable
pnpm install
pnpm run devThis starts the web app on :5173 and the SQLite API on :8787. Development mode includes sample
data; a fresh production instance starts empty.
For a persistent deployment, start with the self-hosting guide.
| Area | Technology | Purpose |
|---|---|---|
| Web app | React, TypeScript, Vite, Tailwind CSS | The schedule and settings UI |
| Client state | Zustand | UI state, persistence orchestration and undo/redo |
| Shared domain | TypeScript in shared/ |
Types, validation, migrations and scheduling rules |
| API and auth | Fastify and Better Auth | HTTP API, sessions and account authorization |
| Database | Node’s built-in SQLite driver | Persistent server-side source of truth |
| Verification | Vitest, Testing Library, Playwright and axe | Unit, integration, browser and accessibility checks |
| Deployment | Docker Compose or Node 24 | Self-hosted production and development environments |
The browser uses the API in normal builds. Only VITE_CAPACITYLENS_DEMO=1 selects the temporary
in-memory demo adapter.
- Password authentication is the stable self-hosted default. Strict OIDC is first-class; named Google, Microsoft and GitHub providers remain experimental. Hosted deployments are OIDC-only.
- Password mode defaults to breached-password screening and supports optional required TOTP MFA, with fixed/idle session limits, host-only cookies and user-controlled session revocation.
- Optional offline access stores a verified snapshot for up to seven days.
- Offline mode is read-only: it never queues or synchronises edits.
- The SQLite database remains the source of truth.
Read the details in authentication and offline access.
pnpm run gate # client typecheck, lint, tests, coverage and production build
pnpm run gate:server # server/shared typecheck and tests
pnpm run e2e # Chromium demo, database and authentication flowsSee development for cross-browser, mutation and GitHub Actions checks.
- Self-hosting — Docker Compose, environment variables, upgrades and deployment.
- Authentication — password, social and OIDC modes.
- Offline access — device cache behavior and limitations.
- Operations runbook — health checks, backups, restore drills and incidents.
- Privacy — stored data, browser storage and operator responsibilities.
- Development guide — repository map, checks, test data and local workflows.
- Server README — API, authorization, persistence and backup boundaries.
- Security review — threat model, remediations, residual risks and complete OWASP mappings.
- ASVS 5.0.0 ledger — every L1–L3 requirement accounted for.
- Standing decisions — decisions that shape the product and architecture.
- Changelog — released and upcoming changes.
Contributing · Governance · Support · Security policy · Trademarks
CapacityLens is licensed under AGPL-3.0-only. Product names and logos are addressed separately in TRADEMARKS.md.