5 months of building, zero users

I spent five months building a project that never launched. It wasn't because the idea was bad. It wasn't because I ran out of time. I killed it myself, one architectural decision at a time.

The irony is thick. I was building a code generator to help developers ship faster. A tool that would eliminate boilerplate so you could focus on what matters. Meanwhile, I was drowning in my own boilerplate, adding complexity that would never serve a single user.

Let me tell you what went wrong.

What I was building

The idea was simple. Developers waste hours setting up the same full-stack structure over and over. Project scaffolding, database schemas, API endpoints, authentication, forms, data tables. The same patterns repeated across every new project.

What if you could design your data model visually, configure your tech stack, and download a complete production-ready monorepo? No more spending the first week of every project writing boilerplate.

The workflow would be straightforward. Pick your stack (Next.js, Express, Drizzle ORM). Design your database schema in a visual ERD editor. Define relationships between tables. Configure which fields appear in forms and data tables. Click generate. Download a working full-stack application with authentication, type-safe APIs, and everything wired up.

I even recorded a demo video showing how it worked. The product was real. I had a domain, jsfullstack.dev. Everything was ready except for one thing: users. Zero users.

The first commit landed on August 3, 2024. I was excited. The vision was clear. I just needed to build it.

The architecture that ate itself

Here's where things went sideways.

Instead of building the simplest thing that could work, I started thinking about scale. What if thousands of users hit this at once? What if I need to iterate on the backend without touching the frontend? What if I want to share types between services?

So I split the application into separate frontend and backend services. Next.js for the frontend. Express for the backend. Already more complexity than I needed, but it felt professional.

Then I discovered ts-rest, a library for type-safe REST APIs. Beautiful. Now I could share API contracts between frontend and backend. But that meant creating a separate package for those contracts. And another package for shared types. And another for data mappers. And another for shared components.

Four packages in a monorepo just to keep things "organized." Each with its own build step. Each with its own dependencies. Each slowing down my development loop while I waited for TypeScript to compile across all of them.

But I wasn't done.

The infrastructure rabbit hole

The application needed to generate code and let users download it. Simple enough. Generate files, zip them, send the download. But what if the files are large? What if the server runs out of memory during generation?

So I added AWS S3. Now generated projects would upload to the cloud, and users would get presigned URLs to download them. Enterprise-grade file handling for a product with zero users.

Then came Docker. I couldn't just run Node on a server like a normal person. I needed multi-stage builds. One stage for building packages. One for the backend. One for the frontend. Each optimized for production with different base images.

But wait, how would I orchestrate these containers? Docker Compose felt too simple. What if I need rolling deployments? What about health checks and automatic restarts?

Docker Swarm it is. With Traefik as a reverse proxy for automatic SSL certificates from Let's Encrypt. Now I had a production-grade orchestration system managing two containers that could have run perfectly fine on a $5 VPS.

I wasn't building a product anymore. I was building infrastructure.

The observability that observed nothing

At some point, I decided I needed proper logging. Not just console.log, but real structured logging with Winston. But where would these logs go? They needed a home.

Enter Loki and Promtail. A log aggregation stack used by companies processing millions of events per day. For my application that processed exactly zero events from real users.

I spent days configuring Promtail to ship logs to Loki, writing dashboards that would help me debug issues that didn't exist yet. The logging infrastructure was more complex than the actual application logic.

Premature everything

The hits kept coming.

Users should have choices for authentication, so I implemented both GitHub and Google OAuth before validating that anyone wanted to use the product at all. Two OAuth providers, two sets of credentials, two integration points to maintain.

I needed to make money eventually, so I integrated Lemon Squeezy for payments. Webhook handlers, subscription management, premium feature flags. All built before a single person had expressed interest in paying for this thing.

The database schema kept growing. Every feature needed more tables. Each table perfectly normalized, each relationship carefully defined. A relational masterpiece serving no one.

The frontend accumulated 51 dependencies. The backend had 42. I used Konva for canvas-based ERD rendering when SVG would have been simpler. I added DND Kit for drag-and-drop when a basic implementation would have worked.

Every technical decision was defensible in isolation. Together, they formed an unmaintainable monument to over-engineering.

What I should have done

Looking back, the path was obvious.

Or better yet, I should have used Laravel. Laravel is batteries included. Authentication, database migrations, queues, file storage, everything works out of the box. You don't assemble pieces together like in the JavaScript ecosystem. You just build your product.

Next.js with API routes could have worked too. A single application, no separate backend, no shared packages, no monorepo complexity. But honestly, the JavaScript full-stack experience still feels like batteries assembled rather than batteries included. You spend time picking libraries and wiring them together instead of building features.

SQLite for the database. Not because PostgreSQL is bad, but because SQLite requires zero configuration and would have been more than enough for validating the idea.

Railway or Cloudflare for deployment. One git push, automatic deploys, SSL handled. No Docker, no Swarm, no Traefik. Let someone else manage the infrastructure while I focus on the product.

No payment integration until people were asking to pay. No multiple OAuth providers until one wasn't enough. No observability stack until there was something to observe.

Ship something ugly but functional in two weeks. Show it to people. See if anyone cares. Then add complexity only when the product demands it.

Instead, I spent five months building for scale that never came, optimizing for problems I never had, and engineering solutions for users who never existed.

The lesson

I've read all the advice about starting simple. I've nodded along to essays about premature optimization. I thought I understood it.

But understanding isn't the same as doing. When you're in the thick of building, every addition feels necessary. Each architectural decision seems reasonable. The complexity creeps in gradually, and you don't notice until you're drowning in it.

The real lesson isn't "don't over-engineer." Everyone knows that. The lesson is that over-engineering feels productive while it's happening. You're writing code. You're solving technical challenges. You're building something impressive.

But impressive to whom? Not to users. They don't care about your Docker Swarm configuration or your type-safe API contracts. They care about whether your product solves their problem.

I built a code generator to eliminate boilerplate while drowning in my own. The irony isn't lost on me.

Next time, I'll build less. Ship faster. Add complexity only when users are banging down the door asking for features that require it. The best architecture is the one that lets you get your product in front of people quickly enough to learn if it's worth building at all.

This project taught me that lesson the hard way. Five months of work, sitting in a repository, serving as a reminder that good engineering isn't about building impressive systems. It's about building the right thing, as simply as possible, and putting it in the hands of real people who can tell you if it matters.