DEV Community: VATSRAJ PARMAR

The Daily Habit That Actually Fixed My Team Visibility Problem

VATSRAJ PARMAR — Mon, 24 Aug 2026 06:38:22 +0000

A few months ago I moved from a pure dev role into coordinating a team of 8 people — still writing code myself, but now also responsible for knowing what everyone else is working on, day to day.

The problem showed up almost immediately: I had no idea what my team was actually doing on any given day unless I asked them directly. Slack messages got buried. "Quick status check-ins" turned into 20-minute conversations that derailed everyone's focus. By the time something was actually blocked, I'd usually find out a day or two late — right when a client asked why it wasn't done yet.

The fix wasn't a tool, it was a habit

I didn't reach for new project management software. I built one habit: a daily consolidated report, same format every single day, no exceptions.

It's simple on paper — one sheet, one row per team member, color-coded by status (on track / at risk / blocked), a short one-line note on what they're working on, and a red banner at the top if anyone hasn't submitted their update yet.

That's it. No new app to learn, no login for anyone else, just a five-minute daily input from each person and a five-minute review from me.

Why this worked when ad-hoc check-ins didn't

It made silence visible. If someone didn't submit, the red banner at the top made that immediately obvious — not buried in a scroll of messages, not something I had to remember to chase. The absence of an update became as informative as the update itself.

It's asynchronous by default. Nobody has to be in a meeting for this to work. People fill it in when they naturally hit a stopping point, not on my schedule.

It's boring, which is the point. The format never changes. Nobody has to think about how to report, just what happened. Decision fatigue kills habits like this fast — remove every unnecessary choice and it actually sticks.

It surfaces patterns you can't see day-to-day. A week of these reports side by side shows you things a single day never will — who's consistently blocked on the same dependency, whose "at risk" tasks never actually resolve, where the real bottleneck in your process is.

What I'd tell someone starting this from scratch

Keep the format rigid at first, even if it feels too simple. The temptation is to add more columns, more nuance, more categories — resist it for at least a few weeks. A habit that's slightly too simple still gets used. A habit that's perfectly comprehensive but takes 15 minutes to fill in gets skipped the first busy day, and once it's skipped once, it's much easier to skip again.

The report doesn't need to be smart. It just needs to happen every day, without fail, until checking it becomes as automatic as checking email.

I Modeled a Relational Database in Notion (No Code) to Kill My Spreadsheet Chaos

VATSRAJ PARMAR — Fri, 21 Aug 2026 09:46:56 +0000

As a developer, I default to building things — but not every problem needs a custom app. My client work was scattered across a spreadsheet for invoices, a doc for project notes, and a notes app for task lists. None of it talked to each other. Every status update meant updating three places by hand.

The fix wasn't code. It was applying actual database thinking — foreign keys, relations, one-to-many — to a tool I'd been using like a glorified to-do list: Notion.

The problem with flat lists

Most people use Notion databases as flat tables. A "Clients" list. A separate "Projects" list. No connection between them. That's the Notion equivalent of denormalized data — duplicate info everywhere, no single source of truth.

The fix is the same one you'd reach for in Postgres: relations.

Modeling it like a schema

I mapped out four entities, the same way I'd sketch a schema before writing migrations:

Clients (1) ──< Projects (many)
Projects (1) ──< Tasks (many)
Clients (1) ──< Invoices (many)
Projects (1) ──< Invoices (many)

In Notion, this becomes relation properties — each database gets a field that points to rows in another database. Set it up as a two-way relation, and opening a client automatically shows every project, task, and invoice tied to them. No manual lookups, no copy-pasting a client name into three different sheets.

The four databases

Clients — contact info, status (Active/Paused/Past), industry. The "root" entity everything else relates back to.

Projects — relates to Clients. Adds status, deadline, budget, priority. This is where a Kanban view (grouped by Status) actually earns its keep — dragging a card from "In Progress" to "Review" feels like a real workflow, not just checking a box.

Tasks — relates to Projects (which relates to Clients, so you get the chain for free). Due dates, priority, assignee.

Invoices & Payments — relates to both Clients and Projects. This was the one I initially got wrong — I first related it only to Projects, then realized I wanted to filter "everything owed by Client X" without going through the project layer. Two relations, no downside.

Views matter as much as the schema

Once the relations exist, the same underlying data supports wildly different views:

Table — the full spreadsheet-style view, for bulk editing
Board (Kanban) grouped by Status — for daily workflow
Calendar grouped by Deadline — for "what's due this week"

This is the part that took me longest to appreciate: the data model is the hard part. Once it's right, views are nearly free.

Where this ended up

I turned the finished structure into a template — four connected databases, pre-filled with sample data so the relations are visible immediately instead of staring at empty tables. If you want the ready-built version instead of wiring up the relations yourself, I packaged it here: Client & Project Tracker — Notion Template.

Either way — if you're a freelancer or small agency juggling client info across too many tools, the fix probably isn't a new app. It's modeling the relations you already have data for.

Building JWT Authentication + Role-Based Access Control for MERN Apps

VATSRAJ PARMAR — Thu, 20 Aug 2026 11:00:13 +0000

If you've built more than one or two production apps, you've probably written auth + RBAC from scratch more times than you'd like to admit. Here's the pattern I keep coming back to — JWT access + refresh tokens, httpOnly cookies, and role-based route protection on both the frontend and backend.

This post walks through the core pieces. At the end I'll link a ready-to-use starter kit if you'd rather not rebuild this from scratch every time.

The problem with "just use localStorage"

A lot of tutorials store the JWT in localStorage and call it done. The problem: any XSS vulnerability on your site can read localStorage and steal the token. httpOnly cookies can't be read by JavaScript at all, which closes that attack surface.

The tradeoff is a bit more setup — so let's go through it.

1. The User model, with roles baked in
`// models/User.js
import mongoose from "mongoose";
import bcrypt from "bcryptjs";

export const ROLES = ["admin", "manager", "user"];

const userSchema = new mongoose.Schema(
{
name: { type: String, required: true, trim: true },
email: { type: String, required: true, unique: true, lowercase: true },
password: { type: String, required: true, minlength: 8, select: false },
role: { type: String, enum: ROLES, default: "user" },
refreshTokenHash: { type: String, select: false },
},
{ timestamps: true }
);

userSchema.index({ role: 1 });

userSchema.pre("save", async function (next) {
if (!this.isModified("password")) return next();
this.password = await bcrypt.hash(this.password, 12);
next();
});

userSchema.methods.comparePassword = function (candidate) {
return bcrypt.compare(candidate, this.password);
};

export default mongoose.model("User", userSchema);`

A couple of things worth noting:

select: false on password and refreshTokenHash means these never come back in a normal .find() — you have to explicitly .select("+password") when you need them. One less way to accidentally leak a hash in an API response.
The role field has an enum — Mongoose will reject anything outside your defined roles at the database level, not just in your app logic.

2. Generating access + refresh tokens
`// utils/generateTokens.js
import jwt from "jsonwebtoken";
import crypto from "crypto";

export const generateAccessToken = (user) =>
jwt.sign({ sub: user._id.toString(), role: user.role }, process.env.JWT_ACCESS_SECRET, {
expiresIn: "15m",
});

export const generateRefreshToken = (user) =>
jwt.sign(
{ sub: user._id.toString(), tokenVersion: crypto.randomUUID() },
process.env.JWT_REFRESH_SECRET,
{ expiresIn: "7d" }
);

export const cookieOptions = {
httpOnly: true,
secure: process.env.NODE_ENV === "production",
sameSite: "strict",
path: "/api/auth",
maxAge: 7 * 24 * 60 * 60 * 1000,
};`

Short-lived access token (15 min), long-lived refresh token (7 days), different secrets for each — if one leaks, the other stays valid independently.

3. The RBAC middleware itself

This is the part that actually enforces roles:
// middleware/roleMiddleware.js export const authorize = (...allowedRoles) => { return (req, res, next) => { if (!req.user) return res.status(401).json({ message: "Not authorized" }); if (!allowedRoles.includes(req.user.role)) { return res.status(403).json({ message:Access denied. Requires role: ${allowedRoles.join(" or ")}, }); } next(); }; };

Usage:
router.get("/reports", protect, authorize("admin", "manager"), getReports);

The key design decision here: roles are checked server-side, always. Your React app can (and should) also hide admin-only UI from regular users, but that's a UX nicety — the actual security boundary is this middleware. Never trust a frontend route guard alone.

*4. Don't forget: never trust the client on registration either
*
This one's easy to miss. If your registration endpoint accepts a role field straight from the request body, anyone can sign up as an admin:

`// DON'T do this:
const user = await User.create({ name, email, password, role: req.body.role });

// DO this instead — hardcode new signups to the lowest privilege:
const safeRole = "user";
const user = await User.create({ name, email, password, role: safeRole });`

Promotion to admin/manager should only happen through a separate, already-authenticated admin-only endpoint — never at signup.

5. Frontend route guards

On the React side, a simple wrapper component keeps unauthorized users out of role-gated pages:

`// components/ProtectedRoute.jsx
import { Navigate } from "react-router-dom";
import { useAuth } from "../context/AuthContext";

const ProtectedRoute = ({ children, roles }) => {
const { user, loading } = useAuth();

if (loading) return

Loading...;
if (!user) return ;
if (roles && !roles.includes(user.role)) return ;

return children;
};

export default ProtectedRoute;`

<Route path="/admin" element={ <ProtectedRoute roles={["admin"]}> <AdminPanel /> </ProtectedRoute> } />

Again — this is UX, not security. The real gate is the backend middleware.

6. Auto-refreshing expired access tokens

Fifteen-minute access tokens mean your users would get logged out constantly without this piece. An axios interceptor handles it silently:
// utils/api.js api.interceptors.response.use( (res) => res, async (error) => { const original = error.config; if (error.response?.status === 401 && !original._retry) { original._retry = true; const { data } = await axios.post("/api/auth/refresh", {}, { withCredentials: true }); setAccessToken(data.accessToken); original.headers.Authorization =Bearer ${data.accessToken}; return api(original); } return Promise.reject(error); } );

The refresh token lives in an httpOnly cookie, so this request automatically includes it — no manual token juggling on the frontend.

Wrapping up

That's the core of it: short-lived access tokens, httpOnly refresh tokens, server-enforced roles, and a frontend that stays in sync without constant re-logins.

If you want the fully wired version of this — rate limiting, refresh token hashing in the DB, paginated admin user management, and a working React UI — I packaged it as a starter kit: MERN Auth + RBAC Starter Kit. Drop it in, connect your MongoDB URI, and you've got working auth in about 10 minutes instead of rebuilding all of this from scratch.

Happy to answer questions about any of the above in the comments.