Back to projects

Daily Team Board — A Shared Daily Work Log

A board where everyone on the team logs in, writes what they did today, watches the whole team's board update near-realtime, and can look back at any past day. Sessions are HMAC-signed by hand rather than pulling in a full auth library.

  • PostgreSQL
  • Next.js
  • TypeScript
  • Neon
  • SWR
  • Framer Motion

The problem

A five-person team wanted to see what everyone did each day without holding a standup every morning and without scrolling back through a chat where other messages bury the updates.

A small problem, but with firm requirements: other people's updates must appear almost immediately without a manual refresh, and any past day must be viewable.

What I built

I chose two-second polling with SWR over WebSockets. For five people, running and maintaining a WebSocket server buys a difference users cannot perceive at this scale — take the simpler option until a real constraint forces the complex one.

For auth I signed the session cookie with HMAC using Node's own `crypto` and enforced it in middleware, rather than installing a full auth library for five users checked against one table. Writing it myself is what made me actually understand what a signed cookie does and does not protect against.

Architecture

Next.js App Router + TypeScript → Neon Postgres via `@neondatabase/serverless`.

The client uses SWR with `refreshInterval: 2000`. `middleware.ts` guards the board route, verifies the signed cookie, and redirects to login when it fails — while the login page and API routes perform their own checks rather than delegating everything to middleware. Cards animate in with a framer-motion stagger.

My contribution

Built entirely by me — schema, seed data, auth, middleware, API routes, and the full UI.

Challenges and trade-offs

Deciding what not to build. I started toward WebSockets and backed out to polling, because at five users nobody can tell the difference while the maintenance cost clearly differs. I think this was the right call, and it is the kind of decision people commonly get wrong because the more modern option is more appealing.

Writing auth by hand without making it fragile. A signed cookie proves its contents were not tampered with, but it does not make sessions revocable. I knew that limitation when I chose it, and it is acceptable at this team size — unlike the portfolio site, where I added a `session_version` column to revoke every session at once, because there the admin can edit everything on a public site. Different constraints deserve different answers.

Result

The team uses it as intended: log in, write today's work, watch everyone else's updates arrive without refreshing, and pick any past date to review — replacing the scroll back through a chat where other messages bury the updates.