After WordPress, I pushed deeper into modern web development. Two projects, one with NestJS and one with React, never launched. But they changed how I think about backend structure, frontend complexity, APIs, state, and scope more than any shipped product ever did.
Two projects that never launched
The first was a backend service built with NestJS. The second was a React-driven interface meant to sit on top of it. Neither reached production. Both taught me things I would not have learned from a project that succeeded on the first try.
Failure is useful when you pay attention to why it happened. In both cases, the idea was not fully clear before we started coding. We built features before the problem was defined, and scope grew faster than understanding.
What NestJS taught me about structure
NestJS enforces a modular architecture: controllers, services, providers, modules. At first, it felt like ceremony. But as the project grew, the structure revealed where our thinking was incomplete. Services that crossed too many boundaries. Modules that existed because we thought we would need them, not because we did.
The architecture was not the problem. The problem was that we did not know what we were building well enough to know which modules mattered. Structure helps most when the intent is clear. Without clarity, it just organises confusion.
React complexity without a product
The React frontend was where complexity really surfaced. State management, API integration, routing, caching, optimistic updates; every piece made sense in isolation. Together, they created a combinatorial tax that slowed every change.
- Every new screen needed data from three endpoints
- Every state change had to update the cache
- Every optimisation assumption broke when the data shape changed
Without a live product to validate against, we optimised for problems we might never have had. That is the real cost of building before the idea is clear enough.
Architecture, scope, and the cost of guessing
Those two projects made me more careful. Now I want to see the shape of a problem before I commit to a stack. I want to know which parts are uncertain and which are well understood. I want to build the thinnest version that tests the assumptions.
Not every project needs to launch to be valuable. But every project needs a reason to exist that is sharper than "let us see what happens."