How this demo is built, and how I would build yours
The job post lists what the application needs. This page shows where each item is in the demo, the decisions behind it, and how the real project would run.
What you asked for, and where it is
A responsive web app with Next.js, React and TypeScript
Next.js 16 with the App Router, React 19, and TypeScript in strict mode throughout.
A clean interface with Tailwind CSS
Tailwind CSS 4 with one set of brand tokens. Change the colors in one file and the whole app follows.
Core features and reusable components
Buttons, form fields, dialogs and notifications are written once and reused on every screen.
Backend APIs and a database
REST endpoints backed by Postgres. Every schema change is a SQL migration kept in the repository.
User authentication
Email and password accounts with session cookies. Access is enforced next to the data, not only in the interface.
Works on desktop and mobile
Layouts are designed for phones first. The board works by touch, mouse and keyboard.
Deployed to Vercel
Deployed from the repository. Database migrations run as part of every deploy.
Clean, maintainable code
Business rules live in one layer shared by pages and the API, covered by automated tests.
How the pieces fit
Requests travel down through four layers. Each layer has one job.
Browser
Pages, forms and the drag-and-drop board
Next.js on Vercel
Server-rendered pages and the REST API
Service layer
Business rules and ownership checks
Postgres
Users, projects and tasks
One place for the rules
Pages and API endpoints call the same service functions. Each one takes the signed-in user's id and filters by it, so there is no route to the data that skips the check.
One definition of valid input
The same schema validates a form in the browser and the request on the server. The two cannot drift apart.
The frame loads first
Navigation and page layout are prepared ahead of time and appear immediately. Personal data streams in a moment later instead of holding up the whole page.
Nothing to install
Without a database address the app runs on an embedded Postgres, so anyone can clone it and start it with one command. Production uses hosted Postgres with the same SQL.
How I would run your project
The same steps whether the application is a tracker like this one or something else entirely.
Agree on the first version in writing
A short list of screens and features, and an equally clear list of what waits for later. This is the scope we both work from.
Put a live URL up at the start
An almost empty but real deployment, so you follow progress by clicking through the app rather than reading status reports.
Build one complete slice at a time
Each feature is finished across database, API and interface before the next begins, and is deployed for you to try.
Hand everything over
The repository, setup instructions, documented environment variables and passing tests. You own all of it.
What this demo leaves out
These are deliberate omissions that keep the demo small. Which of them your application needs is part of the scope conversation.
- Teams, invitations and roles
- Password reset and email verification, which need an email provider
- Live updates between two open browsers
- A dark theme
The quickest way to judge all of this is to use the app.