The problem
General task managers encourage accumulation. The Five applies a deliberate constraint: no more than five goals per day. Each goal can be decomposed into subtasks, completed work moves out of the way, and historical days remain available for reflection rather than becoming an endless editable backlog.
The product combines a focused interaction model with multi-user persistence, passwordless email authentication and optional Google sign-in, without a frontend framework or build step.
Architecture
Vanilla JavaScript · installable app shell
Auth · sessions · daily-data API
Users · sessions · days · goals · subtasks
Trust boundary: browser state controls interface preferences only; authenticated server-side sessions remain the authority for identity and daily data, and the service worker never caches authenticated API responses.
Product decisions
- A five-goal ceiling turns prioritization into a product rule, not a suggestion.
- Calendar, chronological History and progress insights expose completed and unfinished days without reloading the page.
- Carrying an unfinished goal forward creates a new record and preserves the original historical day.
- No Procrastination Mode makes past days read-only while keeping their details inspectable.
- One responsive PWA supports browser and installed app modes across Android and iOS/iPadOS.
- Reduced-motion preferences are respected across navigation, goal reordering and the completion celebration.
Security decisions
- Passwordless signup and login use six-digit email codes with a ten-minute expiry and a five-attempt limit; invited users can also sign in with a verified Google identity.
- Authenticated sessions are server-managed, delivered through HttpOnly, SameSite cookies and expire after seven days.
- Raw OTP values and session tokens are not stored directly; hashed representations are persisted.
- Daily-data endpoints require a valid session, enforce per-user ownership and reject cross-site mutations.
- A server-side email allowlist controls demo access; uninvited visitors can submit a rate-limited access request without exposing a denied Google identity to browser storage or the URL.
- The public document root excludes source, secrets and database files, while request limits, security headers, sanitized logging and automated authorization tests harden the application boundary.
Current scope: the current milestone is a hardened, low-traffic multi-user demo, not a general-production service. Its deployment package includes Nginx HTTPS termination, an unprivileged systemd service, Cloudflare-aware rate limiting, health checks, online SQLite backups and rollback guidance. Wider production use would still require distributed rate limiting, stronger account-enumeration resistance, transactional email infrastructure, centralized monitoring, managed secrets, PostgreSQL and a production application runtime.
Evidence status: Project website and engineering case study. The repository includes automated security, multi-user isolation, access-control, deployment and backup-recovery tests; public source code is not currently claimed.