I recently ran an audit on our latest full-stack repo to figure out why "spinning up a new project" felt like such a heavy lift. I counted every file required just to reach a "production-ready" baseline—before writing a single line of unique feature code.

The count was roughly 600 files.

To be clear, I'm not talking about a `create-react-app` sandbox. I mean a compliant, scalable SaaS foundation: Next.js frontend, Node.js/NestJS backend, mobile wrapper, CI/CD pipelines, and enough security config to pass a SOC2 audit.

It sounds ridiculous (and honestly, it feels ridiculous), but when I broke it down, I couldn't find many files I was willing to delete.

Here is where the bloat comes from:

First, the "Configuration Hell" accounts for about 40-50 files alone. We aren't just dealing with `package.json` anymore. It's `tsconfig.json` (base), `tsconfig.build.json`, `tsconfig.spec.json`... multiplied across frontend, backend, and shared libraries. Then add `.eslintrc.js`, `.prettierrc`, `jest.config.js`, `vitest.config.ts`, `nodemon.json`, and the Docker-compose variants for dev, test, and prod.

Then there’s the DevOps and Quality layer. We have roughly 20-30 files for GitHub Actions workflows (lint, test, build, deploy, semantic release), Husky hooks (pre-commit, commit-msg), and pull request templates.

But the real multiplier is the separation of concerns. In a modern monorepo, a "Hello World" isn't just `console.log`. It’s: - A NestJS module (Controller, Service, Module, DTO, Entity, Unit Test, E2E Test). - A Next.js slice (Page, Component, Type definition, API client wrapper). - A shared library entry.

We found that adding a single "minimal" API endpoint usually touches 5-7 files just to maintain architectural standards.

The trade-off is painful. On one hand, this setup handles the things we used to forget: security headers, proper logging, consistent error handling, and type safety across boundaries. It prevents the "spaghetti code" distinct to startups that scale too fast.

On the other hand, the cognitive load of managing a 600-file "empty" project is massive. Updating dependencies becomes a chore because a major version bump in one tool (like ESLint) cascades through forty config files.

I’m curious how others are handling this "starting line" complexity.

Are you accepting the boilerplate as the cost of doing business? Or have you found a way to strip this down without sacrificing the compliance/safety guardrails that enterprise clients demand?

It feels like we've over-engineered the entry point of software development, but I’m not sure what the alternative is for a serious project. We tried going "lean" initially, but spent weeks retrofitting auth and testing harnesses later—which was worse.

Is there a middle ground I'm missing, or is ~600 files just the new normal?

1.	Show HN: Native app to scaffold and build Cursor-ready Next.js projects(vibecodingstarterkit.io) 1 points by dpitkevics 170 days ago \| 1 comment
2.	Caliverse – Bodyweight Fitness mobile app(caliverse.app) 1 points by dpitkevics 4 years ago \| 0 comments
3.	New calisthenics mobile app for all the people sitting in the office all day(apps.apple.com) 1 points by dpitkevics 6 years ago \| 0 comments

user:	dpitkevics
created:	August 30, 2019
karma:	1