The Real Cost of Building: Opportunity Cost Nobody Tracks

General
1

Everyone calculates development costs. Almost nobody tracks what didn’t get built while we were building.

I want to share a painful story from our Series B journey that completely changed how I think about build vs buy decisions.

The 6-Month Analytics Build

We decided to build a custom analytics and reporting system. The reasoning seemed sound:

  • Amplitude would cost $80K/year at our scale
  • Our engineering team could build it in “3-4 months”
  • We’d have exactly the features we wanted
  • We’d own our data and avoid vendor lock-in

The build took 6 months (surprise). The team delivered exactly what we asked for. The CFO loved the cost savings story. Everyone celebrated.

What Actually Happened

During those 6 months:

Our competitors shipped:

  • Advanced workflow automation (the #1 customer request)
  • Enterprise SSO integration
  • A mobile companion app

We shipped:

  • A custom analytics dashboard our internal team uses
  • Zero customer-facing features for 6 months

Market perception consequence:

Our main competitor started being positioned as “the innovative leader.” We became “the reliable but slow alternative.”

That perception shift didn’t happen because we built bad products - it happened because we went dark on customer-facing innovation for half a year.

The Compounding Effect of Delay

Here’s what most ROI calculations miss: Being 6 months behind on features doesn’t mean you’re just 6 months behind.

When competitors ship enterprise SSO in Q2:

  • They start closing enterprise deals in Q3
  • Those customers become references in Q4
  • By Q1 next year, they’re “the enterprise-ready solution”
  • When we finally ship SSO in Q4, the narrative is “catching up” not “leading”

The market positioning damage compounds. Being 6 months late on a strategic feature can mean 12-18 months to recover market perception.

The True Cost Equation

The real cost of that analytics build:

  • Direct cost: $180K in engineering time (6 months, 3 engineers)
  • Opportunity cost: $2M+ in deferred revenue from delayed enterprise features
  • Market positioning cost: Immeasurable but significant
  • Competitive moat erosion: Our competitors built advantages while we built internal tools

Compare to:

  • Amplitude cost: $80K/year = $40K for those 6 months
  • Features shipped: 3 major customer-facing capabilities
  • Revenue impact: Positive

The Framework That Would Have Saved Us

Strategic Resource Allocation:

  • 80% of engineering resources on differentiation and revenue drivers
  • 20% maximum on enabling infrastructure
  • If a build doesn’t qualify for the 80%, question whether to build it at all

The Pitch Deck Test:
If this capability wouldn’t appear on a slide in our Series C pitch deck as a differentiator, we shouldn’t build it.

Analytics dashboard? Not on the pitch deck.
Industry-specific workflow automation? Definitely on the pitch deck.

Cost of Delay Calculation:
For every major feature we defer, estimate:

  • How much ARR are we losing per month of delay?
  • How many customer conversations are we losing?
  • What competitive positioning are we giving up?

The Brutal Honesty We Need

Most “strategic” build decisions are actually “not invented here” syndrome. Engineers want to build interesting things. Product leaders want perfect solutions. Nobody wants to admit we’re building because it’s more fun than buying.

But fun doesn’t compound into competitive advantage. Shipping customer value does.

The question isn’t “Can we build this?” The question is “What are we NOT building if we build this?”

What frameworks are you using to quantify opportunity cost in build vs buy decisions?

2

David, this is the conversation finance and product need to have more often. Opportunity cost is the hardest number to quantify but often the most important.

Let me share how we’ve started tracking this systematically.

Revenue-Weighted Cost of Delay

We now require every build proposal to include:

Feature Revenue Estimate:

  • What ARR could this feature enable if shipped today?
  • How many deals are blocked waiting for this?
  • What’s the monthly revenue impact of delay?

Example from your analytics case:

  • Enterprise SSO was blocking ~$150K MRR in pipeline
  • 6-month delay = $900K in deferred ARR
  • That $900K loss makes the $80K Amplitude cost completely irrelevant

The WSJF Framework

We’ve adopted Weighted Shortest Job First (WSJF) prioritization:

WSJF = (Business Value + Time Criticality + Risk Reduction) / Job Size

For your analytics example:

  • Business value: Low (internal tool)
  • Time criticality: Low (no customer deadline)
  • Risk reduction: Medium (data ownership)
  • Job size: Large (6 months)
  • WSJF score: ~2

For enterprise SSO:

  • Business value: High ($900K blocked ARR)
  • Time criticality: High (losing deals now)
  • Risk reduction: High (competitive disadvantage)
  • Job size: Medium (3 months if bought Okta, 5 months if built)
  • WSJF score: ~15

The numbers make the decision obvious.

The Build Tax

Every build decision has three costs:

  1. Direct cost: Engineering time (what people calculate)
  2. Opportunity cost: Revenue/features deferred (what people miss)
  3. Maintenance tax: Ongoing 20-35% annually (what people underestimate)

For your $180K analytics build:

  • Year 1: $180K direct + $900K opportunity cost = $1.08M total
  • Year 2-5: ~$50K/year maintenance + opportunity cost of future builds
  • 5-year total: ~$1.3M

Amplitude 5-year cost: $400K

The gap is $900K - and that doesn’t even count the competitive positioning damage.

What’s Working

We now require:

Monthly “What Didn’t Ship” Review:
Every month, we list the top 3 features that didn’t ship and estimate their revenue impact. Makes opportunity cost visible.

Build Budget:
Engineering gets a quarterly “build budget” - limited number of infrastructure builds allowed. Forces prioritization.

Revenue Per Engineer Metric:
Track ARR per engineer. When that ratio declines, it usually means too many non-revenue builds.

David, your pitch deck test is brilliant. I’d add: If the CFO can’t explain how this build impacts Series C valuation, don’t build it.

3

This hits so close to home it hurts. Our startup made the exact same mistake.

We built custom EVERYTHING. Admin dashboards, analytics, customer communication tools, you name it. The engineers loved it - challenging, interesting work. I loved designing it - beautiful, cohesive experience.

Meanwhile, customers were begging for core product improvements.

The Result

Competitors with UGLY off-the-shelf internal tools but BEAUTIFUL core products won. We had beautiful internal tools nobody saw and a core product that fell behind.

David, your “pitch deck test” is perfect. I’d add a designer’s version: “Will customers see this?”

If customers never see it, embrace the ugly SaaS aesthetic and move on. Save your design and engineering craft for what customers experience.

What I Ask Now

  1. Will this be in a demo?
  2. Will this appear in our marketing?
  3. Will customers talk about this feature?

If all three are “no,” buy it and redirect that energy to customer-facing value.

I wish I’d learned this lesson earlier. Maybe we’d still be around.

4

David, this is why product-engineering alignment is so critical. From the CTO seat, I’ll add what’s working for us.

Protecting the Team From Itself

Engineers WANT to build. It’s more interesting than integrating third-party tools. As CTO, part of my job is saying “no” to passionate engineers who want to build everything.

We implemented “Build Credits” - each quarter, engineering gets 2-3 infrastructure build slots. Everything else must be customer-facing.

Forces the hard conversations: Which builds truly matter strategically?

The Success Story

Last quarter, team wanted to build custom monitoring. I redirected them to Datadog ($100K/year cost).

That freed 2 engineers for 4 months. They shipped features that drove $5M in new ARR.

Datadog vs $5M revenue? Easy choice.

The Leadership Challenge

Keeping senior engineers engaged WITHOUT building unnecessary infrastructure is hard. What’s working:

  • Complex customer-facing features get the best engineers
  • Architecture reviews for bought tools (keeps technical challenge high)
  • “Integration excellence” as a valued skill

Velocity without direction is chaos. That’s the CTO’s job - ensuring speed points toward customer value.

5

Adding the engineering management perspective - balancing team morale with business outcomes.

The Morale Factor

Engineers joined us to build interesting things. When we buy everything, some get frustrated feeling like “integration engineers.”

BUT - building the wrong things creates worse morale when the company struggles.

Our 70-20-10 Rule

  • 70% Buy/Integrate: Standard infrastructure, use best-in-class tools
  • 20% Strategic Build: Core differentiators, customer-facing innovation
  • 10% Innovation Time: Experiments, internal tools, technical debt reduction

This keeps engineers engaged while maintaining focus on business outcomes.

The Build Decision Framework

Before approving any build, I ask:

  1. Will this be on our demo slide in 12 months? (Product impact)
  2. Can we maintain this as team changes? (Sustainability)
  3. What customer-facing work gets deferred? (Opportunity cost)

If it fails any test, we buy.

The Results

Better retention (engineers work on meaningful challenges), better business outcomes (shipping customer value), better architecture (mixing best-of-breed tools with custom differentiation).

The key insight: Senior engineers actually appreciate strategic focus more than building everything.