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.

12 points | by thesssaism 12 hours ago

4 comments

  • ativzzz 8 hours ago
    It seems like your priorities are backwards. CI/CD is meant to keep your product stable, there's no point if there's no product to keep stable. DB scaffolding & proper environment config is meant to help you maintain velocity & allow for the proper dev/staging/prod pipeline for testing & scale up to meet your customer needs. But there's no velocity to maintain and no scale to meet.

    Auth flows are important for enterprise customers, but just use an existing off the shelf library for oauth/SSO. Depending on your customers, this is a feature. If you mean auth flows between your own services, then you've overengineered it.

    Basically none of the things you've listed are as important as having features that attract customers. Those things you build afterwards for stability and velocity.

    I'm biased, but in 2026 I would just use a Ruby on Rails monolith with Postgres. You don't even need to containerize it until the stack becomes too complex to run locally.

  • aristofun 9 hours ago
    Unfortunately only Ruby on Rails world seems to systematically care about devx and infra friction. Others just got used to throwing more money and people on it.
  • phone_book 11 hours ago
    Did you explore any of the libraries or frameworks that are meant to bootstrap a SaaS with all of the batteries included?
  • the__alchemist 6 hours ago
    Try Rails or Django.