Before this project, I could build a React component. I could write an Express route. I could query MongoDB. Separately. It was like knowing three languages but never actually having a conversation in any of them. So I decided to build an ecommerce store with React, Node, and MongoDB — a real full stack app, end to end, no tutorial to follow along with and nobody holding my hand.

That decision quietly rewired how I think about software. Years later it's the reason I'm a better DevOps engineer. Here's the honest version of what happened.

The stack, and why the MERN stack made sense

I went with MERN because each piece had a clear job:

  • React for the storefront — the product grid, the cart drawer, the checkout screens.
  • Redux for state management, because a cart, a logged-in user session, and a set of product filters all need to agree with each other at the same time.
  • Node.js with Express for the REST API — every route the frontend calls.
  • MongoDB for the product catalog and order history.

On paper it's clean. Four layers, each one talking to the next. In practice, day one, absolutely nothing talked to anything.

Day one: nothing talked to anything

The frontend rendered beautifully and couldn't fetch a single product. The API returned data in a shape the frontend didn't understand. Auth tokens expired in weird places — you'd add something to your cart, come back two minutes later, and suddenly you were logged out for no reason I could see.

I spent more time debugging the spaces between the layers than writing the layers themselves. And that turned out to be the whole point.

When you build one thing in isolation, the edges are hidden. You mock the API. You hardcode the user. You assume the database gives you exactly what you asked for. Build the whole thing yourself and there's nowhere to hide — the bug is never in one layer, it's in the handshake between two of them.

The features that forced me to grow

This wasn't a demo with three fake products. I built the real thing:

  • Product catalog with search and filtering.
  • Shopping cart with quantity management — add, remove, change amounts, keep it all in sync.
  • A full checkout flow, not a fake "buy" button.
  • JWT authentication — sign up, log in, protected routes.
  • An admin panel for creating and managing products.

Every one of those features touched every layer. Take "Add to Cart." It sounds trivial. But follow it: a click ripples through Redux state, fires an API request, hits the database, and comes back changed — and the UI has to reflect the new truth without a full reload. One button, four layers, and a dozen small ways to get it wrong.

Authentication was the biggest lesson. I used to think of auth as a feature — a login page you bolt on. It isn't. It's a flow that touches everything. Every protected route, every admin action, every cart tied to a real user. Get the token handling slightly wrong in one place and the whole system leaks trust somewhere else.

From understanding pieces to understanding systems

Here's the shift, in one sentence: before this project I understood pieces, and after it I understood systems.

Before, I had React over here, an API over there, a database somewhere in the background. After building the store end to end, I could see the whole organism — how a user action moves through the frontend, into the backend, down to the database, and all the way back, changed at each stop. I understood why each layer exists and, more importantly, where each one breaks.

That's not knowledge you get from a tutorial. Tutorials show you the happy path. They don't show you the token that expires mid-checkout or the filter query that returns the wrong 40 products. You only learn the integration points by living in them.

Why this made me a better DevOps engineer

Years later I moved into infrastructure and DevOps, and the full-stack brain came with me. Because infrastructure is just another layer. A load balancer, a database, a service mesh, a deploy pipeline — same story as the store, one level down. Requests flow through, state has to stay consistent, and the failures almost always live in the seams between components, not inside any single box.

If you've already built all the layers of an application yourself, you know in your bones where things break and why each layer matters. You stop treating the system as magic and start treating it as a set of handshakes you can reason about.

Build one thing end to end

My honest advice: every engineer should build one complete thing at least once. Not to ship it. Not to put it in a portfolio. To rewire how you think.

Pick something with real layers — a store, a booking app, whatever — and build all of it yourself: frontend, API, database, auth. You'll spend most of your time in the messy spaces between the layers, and that's exactly where the growth is. Building full stack changes how you see software. It's worth doing at least once.

What was the project that made you stop seeing pieces and start seeing systems?