Latest / Tech Leadership with Fexingo: Engineering Managers, CTOs, and Technical Leadership Conversations / How a CTO Uses Cost-to-Serve Metrics to Kill Unprofitable Features
Transcript
- Lucas: Let me ask you something. If you're an engineering leader, do you know which features in your product actually cost you money to operate — and I mean the full cost, not just the initial build? Luna: I'd guess most teams could tell you which features are most popular, but not which ones are burning cash on cloud compute and on-call hours. Lucas: Exactly. That's the gap we're looking at today. There's a concept in operations and logistics called 'cost to serve' — it's the total cost of delivering a product to a specific customer. Some engineering teams are now applying it to individual features. Luna: So instead of asking 'how much did it cost to build the feature,' you ask 'how much does it cost to keep it running every month?' Lucas: Right. And that includes cloud infrastructure, database queries, support tickets, on-call rotation time, even the engineering hours spent on maintenance and bug fixes. When you add it all up, some features that look successful on the surface are actually money pits. Luna: And this is exactly the kind of conversation we love to dig into on this show — practical, data-driven, and a bit contrarian. If today's discussion gives you one concrete tool to take back to your team, we've done our job. Lucas: And we can keep having these conversations because listeners like you support the show directly. There are no sponsors, no ad breaks, no pre-rolls. If you find value in episodes like this, you can help keep it that way at buy me a coffee dot com slash fexingo. No pressure — just a simple way to say the content matters. Luna: Yeah. And it genuinely makes a difference. Now, let's get into how you actually calculate cost to serve for a feature. Lucas: So I spoke with the CTO of a B2B SaaS company — about 200 employees, running on AWS. They had a reporting feature that generated PDF exports of dashboards. It was one of their most-requested features in user surveys. Luna: Classic 'customer love' trap. Lucas: Exactly. Users loved it. But when they ran the numbers, that feature was costing them roughly $40,000 a month in AWS Lambda invocations, S3 storage, and — the killer — support time. Customers would export huge PDFs, the system would time out, they'd open tickets, and engineers would get paged. Luna: Did they know that before they calculated cost to serve? Lucas: Not really. They knew the cloud bill was growing, but they had no way to attribute it to individual features. So they built a simple tag-based system: every AWS resource was tagged with a feature name. Then they pulled costs per tag using AWS Cost Explorer. Then they added support ticket counts and on-call incidents tied to those features. Luna: So it's not just a finance exercise. Engineering has to own the tagging and the incident data. Lucas: Right. The CTO told me the tagging took about two sprints to implement across their main services. But once it was in place, they could see that the PDF export feature had a cost to serve ratio of 1.4 — meaning it cost $1.40 to deliver every $1.00 of revenue it generated. Luna: That's terrible by any standard. A feature that should be profitable is actually losing money. Lucas: Yeah. And the fix wasn't to kill it outright — they were too attached. Instead, they put a hard limit on export size, moved the rendering to a cheaper batch process, and reduced the support workload by adding better error messages. Within three months, the cost to serve ratio dropped to 0.6. Luna: So the metric didn't just tell them what to cut — it told them where to optimize. Lucas: Exactly. And that's the real power. cost to serve isn't about saying 'this feature is bad.' It's about saying 'let's understand the full economics of this feature and then decide.' Luna: I imagine some features are intentionally loss leaders though — like a free tier feature that drives upgrades. Lucas: Absolutely. You have to layer on business context. The CTO I spoke with actually kept one feature that had a cost to serve of 2.0 because it was the primary driver of enterprise deals. The key is knowing the number and making a conscious choice rather than flying blind. Luna: So how do you actually implement this in a practical way? Say I'm a VP of Engineering and I want to start next quarter. Lucas: First, you need a tagging standard for cloud resources. Every Lambda function, every database, every S3 bucket should be tagged with a feature or product area. Use infrastructure as code — Terraform or CloudFormation — to enforce it. Then set up a monthly report that aggregates costs per tag. Luna: What about costs that are shared? Like a shared database. Lucas: That's the tricky part. For shared resources, you either allocate based on usage — number of queries, storage volume — or you accept some level of approximation. The CTO I talked to used a simple approach: they divided shared costs proportionally by the number of feature-tagged resources that used it. It's not perfect, but it's good enough to spot the outliers. Luna: And the support side? Lucas: That's where you need to integrate with your ticketing system. Most support platforms let you tag tickets by feature. Then you calculate the average cost per ticket — including engineer time on-call — and multiply by the number of tickets for each feature. Crash incidents from monitoring tools like PagerDuty can also be tagged. Luna: So it's a cross-functional effort. Finance, engineering, support all need to align on the taxonomy. Lucas: Yes. And that alignment is arguably more valuable than the metric itself. Because once you start talking about cost to serve in weekly engineering reviews, you shift the culture from 'build more' to 'build what's sustainable.' Luna: Have you seen any pitfalls? I can imagine teams gaming the numbers or under-tagging to make features look cheaper. Lucas: That's a real risk. If you tie cost to serve directly to performance reviews, people will find ways to hide costs. Better to use it as a team-level diagnostic, not an individual metric. And audit the tagging periodically. The CTO I mentioned runs a quarterly 'tag scrub' where they fix misattributions. Luna: What about features that are new and haven't accumulated much cost yet? They'd look artificially cheap. Lucas: Good point. You need to look at cost to serve over a rolling 90-day window, not all-time. And for new features, you might compare projected versus actual cost to serve after the first quarter. It becomes a feedback loop for your estimation process. Luna: So the real takeaway isn't just the number — it's the conversation it forces. You have to talk about what each feature is actually costing the business. Lucas: Exactly. And once you have that data, you can start asking harder questions: Should we deprecate this feature? Should we raise the price for heavy users? Should we invest in making it more efficient? Without cost to serve, those decisions are just guesses. Luna: I've seen companies that use cost to serve to decide which features to open-source — if a feature has high maintenance cost but low strategic value, they donate it to the community rather than kill it. Lucas: That's a smart move. It preserves goodwill and reduces internal burden. I've also seen teams use cost to serve data to justify a price increase on a specific usage tier. One company found that their 'unlimited' plan was being used by a small number of customers who triggered massive export jobs — so they introduced a fair-use cap. Luna: All of this ties back to what we said at the top: you can't manage what you don't measure. cost to serve gives you the measure. Lucas: One last thing: if you're a CTO or VP of Engineering listening, you don't need a huge budget to start. Pick your top five features by revenue, manually track their cloud costs for a month, add up the support incidents, and calculate a rough ratio. Even that crude approach will reveal something you didn't know. Luna: And that's the kind of actionable insight we aim for on this show. Next time you're in a prioritization meeting and someone says 'we should build this feature because customers want it,' you can ask: 'And what will it cost us to serve?'