Tell HN: We analyzed our dev time.80% is still infrastructure'setup',notfeatures

We recently did a deep dive into our engineering time allocation for a standard 5-person team building a B2B SaaS application. The results were pretty depressing: we spent roughly 960 hours (annualized) on "setup" tasks—environment config, auth flows, RBAC, CI/CD pipelines, and database scaffolding—before we built a single unique feature that actually differentiated the product.

I’m sharing this because I think we’ve become numb to the "Setup Tax" in web development. We assume it's just the cost of doing business, but when you look at the economics, it’s a disaster.

The problem isn't just "writing boilerplate." It's the decision fatigue and integration cost that comes with it. Even with modern frameworks, we found that for a standard CRUD app, about 80% of our engineering effort went into the "commodity layer"—the stuff that every SaaS has, but no customer pays for. Only 20% went into the unique business logic.

We tried to fix this by throwing more bodies at it, but that just increased coordination overhead. So we tried something different: instead of using AI to write code snippets (Copilot style), we used it to generate the entire architectural foundation at once. I'm talking about the full repo structure, the Docker configs, the auth integration, the API gateways—the whole boring 80%.

The goal was to invert that ratio. To get to a point where 70% of our time is on features and only 30% on glue code.

The results from our initial runs suggest it works, but the math is what’s interesting. Moving from 20% feature focus to 70% feature focus isn't just a linear improvement. It’s a 3.5x multiplier on feature velocity. The total lines of code produced might be similar, but the amount of valuable code shipping to production skyrockets.

Obviously, there are massive trade-offs here.

First, you end up with a very generic architecture initially. If you need something novel or specialized (like high-frequency trading or deep tech), this approach is useless. It only works for the "standard web app" pattern.

Second, there's a real risk of "black box" infrastructure. If the team doesn't understand the generated auth flow, they can't debug it when it inevitably breaks. We have to enforce strict governance to stop this from becoming generated spaghetti.

Third, I'm not sure if this efficiency holds up long-term. Maintenance is always the real killer, not day-one setup. We haven't been doing this long enough to see if the generated foundations rot faster than bespoke ones.

I'm curious what others are seeing:

- Does anyone else track "time to first feature"? - What is your ratio of infrastructure/boilerplate vs. actual business logic? - Have internal developer platforms (IDPs) actually solved this for you, or did they just hide the maintenance cost elsewhere?

It feels like we're at a weird inflection point where "starting from scratch" is becoming economically irresponsible for standard software, but the alternative feels like cheating.