Meta Description: Most engineering teams don't know their true ROI. Here's why measuring software economics matters — and why it's harder than it looks.**
The $60,000 Question
Here's a scenario that plays out in engineering organizations every day: Your team spends three weeks building a feature that serves 2% of your users. With a typical all-in engineering cost of €100,000 per year, that's roughly €60,000 of investment for a minority of your user base.
Was it worth it?
If you're like most engineering leaders, you don't know. You have a gut feeling. You have some usage metrics. You have a vague sense that "the sales team said they needed this." But you don't have a number — or even a method for generating one.
This is the core thesis of the discussion around software team economics: Most engineering organizations are flying blind when it comes to understanding the financial impact of their work.
The Optimization Trap
The seductive argument goes like this: If every feature decision were made with clear ROI calculations, organizations would make better decisions. A €60,000 feature for 2% of users is easy to evaluate against a €60,000 feature for 20% of users. Armed with this data, engineering leaders could reallocate resources to high-impact work and eliminate waste.
There's truth to this. In the zero-interest-rate era, companies hired aggressively, shipped aggressively, and worried about efficiency later. That era is over. Companies that can't connect engineering output to business outcomes are in trouble.
But there's a trap here.
What Gets Measured Gets Managed (And Sometimes Broken)
The first problem is attribution. Software doesn't exist in a vacuum. Your company ships 10 features in a quarter, revenue goes up $1M, and you land a new enterprise contract that uses all of them. How much of that revenue belongs to Feature #7?
Every team will attribute the entire win to themselves. The alternative — revenue that disappears without explanation — is politically unacceptable. So you end up with sum-of-parts greater than the whole, and metrics that no one trusts.
The second problem is the measurement burden. If every feature needs a dollar value attached, who does the calculation? Product managers become analysts. Engineers spend time setting up measurement baselines for work that hasn't shipped yet. The meta-work of justifying work starts to rival the work itself.
The third problem is the most insidious: innovation doesn't have a clear ROI when you start.
The Innovation Paradox
WhatsApp was built by 30 engineers serving 1 billion users. But WhatsApp in 2010 didn't have 1 billion users. It had a few thousand. At what point in that journey did the feature work of those 30 engineers become "worth it"?
If you measured strictly by short-term ROI at every step, you might have killed the project six months in. The features that matter now — end-to-end encryption, cross-platform sync, minimal data collection — were long-term bets that looked like waste when they were built.
This is the paradox: The most valuable engineering work often looks like waste until it becomes indispensable.
The Missing Layer: Baseline Before Optimization
There's a sensible middle ground that gets lost in the "bean counters vs. pampered artists" framing.
The problem isn't measurement itself. The problem is measuring without baselines. Consider a DevOps engineer who automates a manual task that cost every developer 2 hours per week. That's 80 hours saved per week for a 40-person team. But what do those engineers do with the extra time?
If they use it to ship more features, the ROI is clear. If they take longer lunches, the ROI is zero. The difference isn't about the automation — it's about whether the freed-up capacity has a place to go.
As one commenter put it: "Profile before you optimize and the return on investment calculates itself." Most organizations skip the profiling step. They don't measure what happens now, so they can't measure what happens after.
The 3-5x Rule
There's a rule of thumb that circulates in engineering leadership: A feature needs a 3-5x return on investment to be worth building. The math is simple: Building a feature costs €60,000. If it generates less than €180,000 of value, you're losing money.
But here's what this rule misses:
Lifetime value vs. first-year value. A feature might cost €60,000 to build but generate €20,000 annually for five years. That's a 4x return, but if you measure strictly in year one, it looks like a failure.
Capability building, not just features. Some work doesn't generate revenue directly but enables revenue-generating work. Infrastructure platforms, developer tooling, security hardening — these are investments in capability.
Option value. A feature for 2% of users might unlock an adjacent market segment. That 2% might be a beachhead for a much larger opportunity.
The Role of AI in All This
The original discussion that sparked this thread included a provocative claim: AI agents can replace much of what engineering teams do today, at lower cost, with different trade-offs.
The counter-arguments were equally strong: AI-generated code becomes unmanageable technical debt. Agents can't reason through unfamiliar systems at scale. You still need a human to fire and sue.
But the deeper question isn't "Will AI replace engineers?" It's: "How does AI change the economics of software production?"
If AI can ship a 95% clone of Slack in two weeks (as the original article claimed), what does that mean for teams spending years building products from scratch? The value of engineering has always been more than lines of code per hour. But as the cost of code drops, the value of everything else — product judgment, user empathy, strategic thinking — rises.
What Actually Matters
Here's what the most productive engineering teams actually do:
They focus on problems they care about. One commenter put it best: "The only thing that matters is whether the people on the team care deeply about the product." Teams that don't care have a productivity ceiling no amount of process can fix.
They build in increments. Shipping 10 major features in a quarter makes attribution impossible. Shipping one feature every week makes it clear what landed and what didn't.
They understand the business. Engineers who know how their company makes money — not just "we sell software" but "we sell to HR directors at 500-person companies with specific compliance needs" — make better decisions.
They accept uncertainty. Not every feature will succeed. Not every infrastructure investment will pay off. The goal isn't to eliminate uncertainty — it's to take calculated bets and learn from the results.
A Framework, Not a Formula
Here's a practical framework for thinking about engineering economics, short of full financial modeling:
Measure the things you can. If you're building something, know the baseline. How long does this take now? How many users touch this? What's the current failure rate?
Know your multipliers. A €60,000 feature for 2% of users might be worth it if that 2% represents your highest-value customers. A €60,000 feature for 50% of users might be a waste if those users don't pay.
Distinguish between capability and output. Infrastructure that makes everyone 10% faster is different from a feature that drives direct revenue. Measure them differently.
Track learning, not just outcomes. Did a feature fail because the market wasn't there, or because the execution was wrong? That's valuable data either way.
Keep the meta-work minimal. If calculating ROI takes longer than building the feature, you're optimizing the wrong thing.
The Bottom Line
Engineering organizations are flying blind — but maybe that's okay up to a point.
The extreme of no measurement is waste: teams working on things that don't matter for users who don't care, with no accountability for results.
The extreme of hyper-measurement is paralysis: every decision requires a business case, every feature needs a revenue forecast, every engineer becomes a part-time analyst.
The middle ground is pragmatic: Measure what you can, accept what you can't, focus on problems worth caring about, and trust that the outcomes will follow.
The €60,000 question isn't whether that feature for 2% of users was worth it. The question is: Did you learn something that makes the next decision better?
FAQ
Q: How do I measure ROI for engineering work? A: Start with baselines. Measure before you change. For features, track adoption, retention, and revenue impact. For infrastructure, measure time saved, error reduction, or developer satisfaction. But accept that some value is unmeasurable — like team morale or strategic option value.
Q: What's the 3-5x rule for engineering ROI? A: It's a heuristic that a feature should generate 3-5x its cost to be worth building. If building costs €60,000, the feature should generate €180,000-€300,000 of value. But this rule misses long-term value, capability building, and option value — so use it as a filter, not a law.
Q: How does AI change software team economics? A: AI lowers the cost of code generation, which changes the relative value of engineering skills. As code becomes cheaper, product judgment, user empathy, and strategic thinking become more valuable. Teams should focus on what AI can't do: understanding problems deeply, making judgment calls, and building relationships with users.
Q: Should every feature need a business case? A: No. Hyper-measurement slows down innovation. A better approach: quick business cases for major bets, lightweight ROI tracking for routine features, and space for experimental work where the value is learning, not revenue.
About the Author: Arkin is a software engineer and startup founder building Orbits Studio. He writes about engineering economics, startup strategy, and the intersection of technology and business. Find him at arkin-dev.com.