TaskFlow Pro
Project and task management with boards, sprints, and team workload views
Every product here started with a question, and TaskFlow Pro started with: how hard would it be to project and task management with boards, sprints, and team workload views? The answer turned out to be 'harder than a weekend, worth more than a year' — and the result is a full-stack platform built on the patterns documented in the blog.
A production-grade SaaS platform designed from the ground up around a real workflow. The project started as a question — 'why is this still done in spreadsheets?' — and grew into a full product with authentication, billing-ready features, admin tooling, and an architecture that survives real users. Built with the modular MVC structure from this portfolio's architecture articles: thin routes, service layers for business rules, and repositories behind every database call.
Features
- Role-based access with owner, admin, and member permissions on every resource
- Full-text search across entities with filterable, sortable, paginated tables
- Server-side rendered pages with progressive enhancement for instant interactivity
- CSRF-protected mutations, rate-limited auth, and audit logging on sensitive actions
- Responsive glassmorphism UI shared with the rest of the portfolio's design system
- Dark mode with a persisted theme preference and reduced-motion support
Architecture
The codebase follows the five-layer pattern documented in the blog: routes stay thin and declarative, services own business rules, repositories own all database access, and views receive only pre-shaped data. Every module is scaffolded from the same template, which means a new resource type — say, client statements — is a repository, a service, and a thin route following an existing shape.
Key Technology Decisions
| Decision | Choice | Alternative Considered | Why This Won |
|---|---|---|---|
| Data store | MongoDB with Mongoose | PostgreSQL | Document shape matches screen shape; schema evolves weekly |
| Rendering | Server-side EJS | React SPA | Instant first paint; content-first product; minimal JS |
| Styling | Tailwind component layer | CSS modules | One glass design system across three portfolio products |
| Auth | Session cookies + CSRF | JWT | Server-owned sessions with HttpOnly cookies; revocation by default |
| Deployment | PM2 cluster + Nginx | Serverless functions | Zero-downtime reloads on one well-understood box |
undefined
Real-World Impact
The platform's most demanding moment came during a shared-account stress test: forty concurrent users hammering the same workspace while a background job recalculated team metrics. The indexed queries and the caching decorator absorbed the load without a single timeout, and the latency percentiles barely moved. The incident report from that day is two lines long — because nothing broke, and the monitoring data proved it.
Measured Results
- Dashboard queries optimized from 40 per render to 1 indexed query per table
- P95 page render under 400ms on a mid-range phone, 4G connection
- Zero-downtime deploys on every release via PM2 rolling reloads
- Audit trail covering every sensitive action with request IDs
Frequently Asked Questions
What makes this production-ready rather than a demo?
Everything an operator needs exists: health endpoints, structured JSON logs, rate limits, CSRF protection, audit trails, encrypted backups, and a CI pipeline that builds, tests, and deploys without human steps.
Why MongoDB instead of a relational database?
The screens are document-shaped: every page renders one entity plus its embedded summaries. The schema evolves weekly, and the versioned-migration pattern handles evolution without downtime. PostgreSQL would be chosen the day complex relational reporting becomes the product.
How does the design system stay consistent?
The Tailwind component layer — glass-card, glass-panel, glass-chip, glass-input — is shared across the portfolio's products, so every page is assembled from the same vocabulary by construction, not by discipline.
What was the hardest part to build?
The permission model. Every resource is owned, shared, or public, and ownership checks must run server-side on every route. The solution is a small middleware that verifies ownership before handlers run, and it has been bug-free since the third week.
Is the codebase structured for growth?
Yes — new modules copy an existing template, which is why the architecture article calls it 'survivable growth'. Each resource type is an independent module that can be deleted without touching its neighbors.
Conclusion
If you are building something similar, the lesson of TaskFlow Pro is to invest in structure before scale. The boundaries, indexes, and automation that make it resilient were decisions made early — and every later feature inherited their benefit.