Project Management System

The Problem

A service-based company needed control over every project they ran. Without a dedicated system, work was spread across spreadsheets, messages, and memory. No single source of truth, no visibility into what was on track or falling behind.

The goal: build a platform that gives the team one place to manage projects, track progress, and stay aligned across every engagement.

What I Built

A full-stack project management system with Next.js as both frontend and backend, deployed on Vercel with a PostgreSQL database. The interface was built with Tailwind CSS and shadcn/ui: clean, functional, and fast to iterate on.

The architecture was intentionally simple:

• Next.js API routes handled all backend logic, no separate server, no context switching between codebases
• Vercel PostgreSQL for persistent storage, colocated with the frontend in the same deployment ecosystem
• shadcn/ui for consistent, accessible components that didn't require building a UI system from scratch
• Monorepo structure: frontend and backend lived together, making iteration fast and deployment straightforward

What Stopped It

The project didn't ship. Here's an honest breakdown of why.

Perfectionism over progress. I kept refining individual features instead of shipping working versions. A single feature could consume days, not because it was complex, but because it wasn't exactly right yet. The rest of the system waited.

Under-explored tooling. I leaned too heavily on manual approaches when better tools existed. Not knowing what I didn't know was a real bottleneck, and I wasn't moving fast enough to close the gap.

Team misalignment. Working with a team that had diverging priorities created friction that compounded over time. Conflicting interests slowed momentum in ways that no technical fix could address.

POC that came too late. By the time there was something concrete to show, the company's interest had shifted. The business window had closed while we were still building.

What I Took From It

This project changed how I approach every project since.

Ship at 80%, not 100%. A working feature that's live beats a perfect feature that never ships. "Good enough to show" is a legitimate milestone, not a compromise.

Explore tooling constantly. I now make it a habit to look at what's new every week. The landscape moves fast, and staying current isn't optional. It's how you avoid building the hard way when an easier path exists.

One builder, clear support roles. A project like this needs one person driving the build. The adjacent work (how to sell it, how to onboard users, how to keep stakeholders aligned) matters enormously, but it shouldn't compete with engineering time. Separate the roles.

The POC is the deal. A working prototype often carries more business value than the finished product. Ship the POC fast, get the signal, then decide whether to build the rest. Momentum is fragile. Protect it by showing something real as early as possible.