HackerNews中文版

我们最近对一个标准的5人团队在构建B2B SaaS应用程序时的工程时间分配进行了深入分析。结果相当令人沮丧：我们大约花费了960小时（按年计算）在“设置”任务上——环境配置、身份验证流程、基于角色的访问控制（RBAC）、持续集成/持续交付（CI/CD）管道和数据库搭建——在构建出一个真正能够区分产品的独特功能之前。我分享这个是因为我觉得我们对网络开发中的“设置税”已经麻木。我们认为这只是做生意的成本，但当你审视经济状况时，这简直是一场灾难。问题不仅仅在于“编写模板代码”。更在于随之而来的决策疲劳和集成成本。即使使用现代框架，我们发现对于一个标准的CRUD应用，约80%的工程工作投入在“商品层”上——每个SaaS都有的东西，但没有客户愿意为此付费。只有20%的精力投入在独特的业务逻辑上。我们尝试通过增加人手来解决这个问题，但这只增加了协调的开销。因此，我们尝试了一种不同的方法：不是使用AI来编写代码片段（类似Copilot），而是让它一次性生成整个架构基础。我说的是完整的代码库结构、Docker配置、身份验证集成、API网关——所有那些乏味的80%。我们的目标是反转这个比例。希望能达到70%的时间用于功能开发，而只有30%用于粘合代码。我们初步的运行结果表明这种方法有效，但有趣的是其背后的数学原理。从20%的功能关注转向70%的功能关注并不是线性改进。这是对功能开发速度的3.5倍提升。虽然生成的总代码行数可能相似，但实际投入生产的“有价值”代码量却大幅增加。显然，这里存在巨大的权衡。首先，最初你得到的是一个非常通用的架构。如果你需要一些新颖或专业的东西（比如高频交易或深度技术），这种方法就无济于事。它仅适用于“标准网络应用”的模式。其次，存在“黑箱”基础设施的真实风险。如果团队不理解生成的身份验证流程，当它不可避免地出现故障时，他们无法进行调试。我们必须严格执行治理，以防止这变成生成的“意大利面条”。第三，我不确定这种效率是否能长期保持。维护始终是最大的杀手，而不是第一天的设置。我们还没有进行足够长的时间来观察生成的基础是否比定制的更快腐烂。我很好奇其他人是怎么看的： - 还有其他人跟踪“首次功能所需时间”吗？ - 你的基础设施/模板代码与实际业务逻辑的比例是多少？ - 内部开发平台（IDP）是否真的为你解决了这个问题，还是只是把维护成本隐藏在了其他地方？感觉我们正处于一个奇怪的拐点，“从零开始”对于标准软件来说变得经济上不负责任，但替代方案又感觉像是在作弊。

查看原文

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.

告诉HN：我们分析了我们的开发时间。80%仍然是基础设施的“搭建”，而不是功能开发。