The Unit Economics Nobody Talks About in Fitness-Tech Diligence: Dev Cost Per Feature

Most diligence memos on fitness-tech deals spend pages on CAC, LTV, churn cohorts, and TAM slides — and maybe a single line item on "technology." That's a gap. For a product-led fitness app, the dev org isn't overhead, it's the factory. And the metric that actually predicts whether that factory scales cleanly or eats the next round isn't burn rate. It's cost per shipped feature, tracked over time.

Nobody puts this in a pitch deck because it's unflattering. A founder's burn rate looks fine in aggregate right up until you notice that feature velocity has quietly halved while headcount doubled. That's the number diligence teams should be pulling, and almost never do.

Why "burn rate" hides the real problem

Burn rate tells you how fast cash is leaving the account. It says nothing about what's coming back out the other end. Two startups can have identical $180K/month dev spend and wildly different outcomes: one ships a wearable integration, a redesigned onboarding flow, and a nutrition module in a quarter; the other ships a partial rewrite of the same login screen because the original was outsourced cheaply and is now unmaintainable.

The fix is a simple ratio: total quarterly dev spend divided by shipped, revenue-relevant features (not bug fixes, not internal tooling — customer-facing capability that moves a retention or conversion metric). Track it over four quarters. A flat or improving cost-per-feature curve is one of the cleaner tells that a technical team is compounding rather than treading water.

The onshore/offshore delta is bigger than most memos assume

Fully loaded US engineering cost for a mid-level mobile developer typically lands somewhere in the $130K–$180K annual range once you include benefits, tooling, and management overhead. Offshore and nearshore delivery models — India, Eastern Europe, Southeast Asia — routinely quote blended hourly rates in the $25–$50/hr band for comparable output, which on a fully loaded basis can run to roughly a third of the US figure, sometimes less.

That delta shows up directly in the cost-per-feature number, but it's not free money — it comes with real tradeoffs diligence teams should actually underwrite rather than wave away:

• Communication overhead. Time zone gaps add latency to every decision loop. A founder who's used to same-day answers from an in-house team will feel this immediately with a fully offshore vendor.
• Governance quality varies enormously. The offshore development market ranges from milestone-driven shops with dedicated PMs and support SLAs to loosely managed contractor pools where scope creep is the norm. This is where most of the variance in outcomes actually lives — not in the hourly rate.
• Domain specificity matters more in fitness than in generic SaaS. Wearable API integration (HealthKit, Google Fit, BLE device protocols) and health-data handling aren't commodity skills. A cheap generalist shop without fitness-specific delivery history will often cost more in the long run through rework.

The startups getting this right tend to run a hybrid model: a small in-house core (product, senior architecture, compliance ownership) paired with an offshore or nearshore execution layer for feature throughput. Shops like Dev Technosys, along with a handful of comparable US-facing offshore firms, have built their positioning specifically around that hybrid — local-style project governance layered on offshore cost structure — precisely because that combination is what closes the communication-overhead gap without giving up the cost delta.

A framework for underwriting the tech line item

For anyone actually running diligence on a fitness-tech asset, here's a more useful set of questions than "how much do you spend on engineering":

1. What's the trailing four-quarter cost-per-feature trend? Flat or declining is good. Rising while headcount is flat is a red flag — it usually means technical debt is compounding.

2. What percentage of the roadmap is genuinely revenue-facing versus maintenance? Healthy consumer fitness apps should be spending the majority of dev cycles on retention and monetization features, not firefighting. A ratio that's inverted — more maintenance than shipping — is a sign the codebase or the vendor relationship needs a hard look before the next check gets written.

3. Is the vendor relationship structured around milestones or open-ended time-and-materials? T&M billing without fixed milestones is where cost-per-feature quietly balloons, because there's no natural checkpoint forcing scope discipline.

4. How much of the wearable/health-data stack is owned versus dependent on a single vendor's institutional knowledge? If the only people who understand the HealthKit integration work for an outside shop with no documentation handoff, that's a key-person risk on the vendor side, not just the founding team.

5. What does the support SLA actually look like six months post-launch, not at kickoff? Sales calls always sound the same. The real signal is whether a bug reported in month seven gets the same response time as one reported in week two.

What this means for valuation conversations

None of this should be a dealbreaker line item on its own, but it belongs in the model. A fitness-tech company with a disciplined cost-per-feature trend and a well-governed hybrid dev model can plausibly sustain a higher feature-shipping cadence per dollar of burn than a comparable competitor running an all-in-house US team — which matters directly for how much runway a given raise actually buys, and how credible the 18-month roadmap in the deck really is.

Conversely, a startup that's all-in on a single offshore relationship with no documented governance, no fixed-milestone structure, and no visibility into cost-per-feature trends is carrying a form of operational risk that rarely gets modeled explicitly but shows up eventually — usually as a surprise rebuild six to twelve months after the check clears.

The unit economics conversation in fitness-tech has mostly been about the consumer side: CAC, LTV, retention curves. The next round of diligence sophistication in this vertical is going to be on the production side of the business — how efficiently the product itself gets built. That's a much more useful predictor of runway reality than burn rate alone, and it's sitting right there in every fitness-tech cap table, mostly unexamined.