Your Frontend Is the Product, Not a Skin on the Backend

Most full-stack advice tells you to nail the backend first, then sprinkle on a frontend at the end. I think that's backwards. If you're building anything users touch, the frontend is the product. The API is plumbing. I'll defend that with a concrete scenario, not a vibe.

Imagine you're a solo full-stack developer building an internal analytics dashboard for a 40-person logistics company. You've got six weeks. You pick the MERN stack — MongoDB, Express, React, Node — because it's one language top to bottom and you already know JavaScript. Good. Now here's where most people lose the plot: they spend week one on auth middleware and database schemas, and week five frantically wiring up tables that look like a 2009 admin panel.

Start With the Screen, Not the Schema

I'd flip the order. Sketch the dashboard's three core screens first. What does the dispatcher actually need to see at 7 a.m.? Probably a list of late shipments, a map, and a single number — on-time percentage. That's it. Once you can name the screens, the API design almost writes itself, because a full-stack app is just the frontend and backend talking through APIs: the browser makes a call, the server returns a response (usually JSON), and the frontend renders it (MDN Web Docs).

React is a good fit here because it lets you build the UI out of components — small pieces you combine into screens and pages (React official documentation). For this dashboard, you'd have a ShipmentRow, a StatusBadge, and a FilterBar. Nothing exotic. The win is that when the client asks for a new column, you change one component, not five templates.

Quick tip: before you write a single API route, write the JSX that consumes it. If the props feel awkward, your endpoint is wrong.

State Is Where Solo Developers Bleed

The dashboard has a filter for date range, a search box, and a selected shipment. Three pieces of state. A beginner puts each one in a different component and then spends a day passing callbacks up and down. Don't. React's own guidance is blunt: as an app grows, be intentional about how state is organized, because redundant state is a common source of bugs, and when two components must always change together you lift the state to their closest common parent and pass it down as props (React official documentation).

So in this scenario, the selected shipment lives in the dashboard page component. The row just receives it. The filter bar owns its own inputs because nothing else cares. That one decision saves you from the classic bug where the badge says "delivered" but the detail panel still shows "in transit."

For simple toggles, useState is fine. When the filter logic gets gnarly — six checkboxes interacting — reach for useReducer so the update rules live in one function instead of scattered across handlers (React official documentation (Hooks)).

The Backend Should Be Boring

Node.js with Express is the default choice in a MERN setup, and it's a fine one. Node ships a large standard library including HTTP, HTTPS, file system, crypto, and streams modules, plus a built-in test runner (Node.js official documentation). For a dashboard with maybe 200 requests per minute, you will never stress this. Don't reach for Kubernetes. Kubernetes is a portable platform for managing containerized workloads with service discovery, self-healing, and horizontal scaling (Kubernetes official documentation) — and it is completely unnecessary for an internal tool with 40 users. I've watched teams burn two sprints on a cluster to serve traffic a single $20 VM could handle.

One thing you should do: pick an Active LTS release of Node for production. Node versions spend six months in Current status, and LTS releases typically get critical bug fixes for a total of 30 months (Node.js official documentation (releases)). If you ship on a Current release, you're volunteering to upgrade under pressure.

Data Modeling Follows the Screen

Because we designed screens first, the data model is obvious. Shipments live in MongoDB as JSON-like documents, which lets you model data the way your application code uses it (MongoDB official documentation). That matters here: a shipment document can nest its scan events as an array, and your React component can render that array directly. No join, no ORM mapping layer.

But — and this is the part that bites people — add an index on the field you filter by. Without an index, MongoDB must scan every document in a collection to return query results, and each index you add slows down writes because every insert has to update it (MongoDB official documentation (indexes)). For a dashboard that filters by status and sorts by updatedAt, two indexes are plenty. If you later need that on-time percentage, use an aggregation pipeline — stages that filter and group documents, passing output from one stage to the next (MongoDB official documentation (aggregation pipeline)).

Accessibility and Performance Are Frontend Work, Not Polish

This is the hill I'll die on. Accessibility gets scheduled last and then cut. But a huge amount of accessible web content comes down to using the correct HTML element for the correct purpose (MDN Web Docs). A <button> instead of a clickable <div>. A real <table> with headers for the shipment list. That's a ten-minute decision that saves a rewrite.

Performance is the same story. Lazy loading marks resources as non-blocking and loads them only when needed, which shortens the critical rendering path (MDN Web Docs (Web performance)). Your dashboard doesn't need the map library on first paint. Load it when the user opens the map tab. Set a performance budget — a limit that prevents regressions — and hold the line on it (MDN Web Docs (Web performance)).

Warning: don't ship a dashboard that only works on your 27-inch monitor. Responsive design means layouts that work across screen sizes and resolutions, using fluid grids, fluid images, and media queries, with breakpoints defined in relative units rather than the exact sizes of a specific device (MDN Web Docs). Dispatchers use phones. That's not an edge case.

TypeScript and Tests: The Cheap Insurance

If you're solo on a six-week build, TypeScript is the highest-leverage thing you can add. It's a static typechecker — it runs before your code runs and verifies that types are correct (TypeScript Handbook (Introduction)). That means the API response shape you assumed in your React component gets checked against what the server actually returns. For a dashboard with a dozen fields per shipment, this catches the typo where you wrote shipmentId instead of shipment_id at compile time instead of at 6 p.m. on launch day.

For tests, Jest is the pragmatic pick: it runs tests in parallel in their own processes, runs previously failed tests first, and generates coverage with the --coverage flag (Jest official documentation). Its mock functions let you erase a real implementation and assert how it was called — perfect for testing that your API client hits the right endpoint without standing up a server (Jest official documentation (Mock functions)). You don't need 90% coverage on an internal tool. You need the filter logic and the date math covered.

My takeaway: treat the frontend as the product and the backend as infrastructure that serves it. Design the screens first, let them dictate your API and your data model, keep state lifted and boring, index what you filter, and spend your TypeScript and Jest budget on the parts a user will notice breaking. If you do that, a six-week solo build ships something a dispatcher can actually use at 7 a.m. — which was the whole point.

Sources

• MDN Web Docs (web development) - https://developer.mozilla.org/en-US/docs/Learn_web_development
• React official documentation - https://react.dev/
• Node.js official documentation (releases) - https://nodejs.org/en/about/previous-releases
• MongoDB official documentation (indexes) - https://www.mongodb.com/docs/manual/indexes/
• MDN Web Docs (Web performance) - https://developer.mozilla.org/en-US/docs/Web/Performance
• TypeScript Handbook (Introduction) - https://www.typescriptlang.org/docs/handbook/intro.html