Skip to main content
Welcome. This site supports keyboard navigation and screen readers. Press ? at any time for keyboard shortcuts. Press [ to focus the sidebar, ] to focus the content. High-contrast themes are available via the toolbar.
serard@dev00:~/cv

ROI and Maintenance Costs of Requirements as Architecture

Industrial Monorepo Series — Part 6 of 7 1. The Problem · 2. Physical vs Logical · 3. Requirements as Projects · 4. At Scale · 5. Migration · 6. ROI · 7. Inverted Deps

The question isn't whether type-safe requirements are elegant. The question is whether they're cheaper than the status quo. They are — by a wide margin.


The previous five posts described the problem, the solution, the scale characteristics, and the migration path. This post answers the question that management asks: What does it cost, and what's the return?


The Cost of the Status Quo

Before calculating ROI, we need to quantify what the ServiceLocator monorepo costs today. These are conservative estimates for a 15-team organization with a 50-project monorepo.

Developer Time Waste

Activity Frequency Time per Instance Weekly Cost (15 teams)
"Which code implements feature X?" 3-5× per team per week 30 min - 2.5 hours 45-75 dev-hours
Tracing ServiceLocator call chains 2-3× per team per week 20-45 min 20-35 dev-hours
"Is this code dead?" investigation 1-2× per team per week 15-30 min 8-15 dev-hours
Test environment setup (mock ServiceLocator) 2-4× per team per week 15-30 min 15-30 dev-hours
Onboarding: new dev understands 1 feature ~2 new devs per month 2.5 hours per feature, ~5 features 25 dev-hours/month
Total weekly waste 88-155 dev-hours

At a blended rate of $100/hour (salary + benefits + overhead), that's $8,800 - $15,500 per week in developer time spent navigating a codebase that doesn't explain itself.

Annual cost: $458,000 - $806,000.

Defect Costs

Defects from hidden dependencies and cross-team miscommunication:

Defect Type Frequency Cost per Incident Annual Cost
Phantom dependency chain bugs 2-3 per month $5,000 - $15,000 (investigation + fix + deploy) $120,000 - $540,000
DI registration errors (production) 1-2 per month $2,000 - $8,000 $24,000 - $192,000
Cross-team contract mismatches 1-2 per month $3,000 - $10,000 $36,000 - $240,000
Stale test / mock divergence 3-5 per month $1,000 - $3,000 $36,000 - $180,000
Total annual defect cost $216,000 - $1,152,000

Compliance and Audit Costs

For regulated industries (healthcare, finance, automotive):

Activity Frequency Cost Annual Cost
Manual traceability audit 2-4 per year $15,000 - $50,000 per audit $30,000 - $200,000
Audit preparation (developer time) 2-4 per year 80-160 dev-hours per audit $16,000 - $64,000
Compliance remediation 1-2 per year $20,000 - $100,000 $20,000 - $200,000
Total annual compliance cost $66,000 - $464,000

Total Cost of Status Quo

Category Conservative Aggressive
Developer time waste $458,000 $806,000
Defect costs $216,000 $1,152,000
Compliance costs $66,000 $464,000
Total annual cost $740,000 $2,422,000

This is the cost of not having logical boundaries — the cost of a 50-project monorepo where nobody knows which code implements which business feature.


The Cost of Migration

One-Time Costs

Activity Effort Cost
Create Requirements + Specifications projects 1 dev × 1 week $4,000
Set up Roslyn analyzer (basic) 1 dev × 1 week $4,000
Define 8 feature types + ACs 1 dev × 2 weeks $8,000
Create specification interfaces 1 dev × 2 weeks $8,000
Migrate 8 features (implementations) 2 devs × 8 weeks $64,000
Annotate existing tests with [Verifies] 1 dev × 2 weeks $8,000
Cleanup (remove ServiceLocator, distribute Core) 2 devs × 2 weeks $16,000
Total one-time cost $112,000

Ongoing Costs

Activity Effort Annual Cost
Maintain Roslyn analyzer 0.1 FTE $10,000
Review Requirements PR changes ~2 hours/week across teams $10,000
Define new features (incremental) ~4 hours per new feature Included in feature work
Total annual maintenance $20,000

ROI Calculation

Conservative Scenario

Annual savings:  $740,000 (status quo cost eliminated)
Migration cost:  $112,000 (one-time)
Annual maintenance: $20,000

Year 1 ROI: ($740,000 - $112,000 - $20,000) / $112,000 = 543%
Year 2 ROI: ($740,000 - $20,000) / $112,000 = 643% (cumulative)
Payback period: $112,000 / ($740,000 / 12) = 1.8 months

Aggressive Scenario

Annual savings:  $2,422,000
Migration cost:  $112,000
Annual maintenance: $20,000

Year 1 ROI: ($2,422,000 - $112,000 - $20,000) / $112,000 = 2,045%
Payback period: $112,000 / ($2,422,000 / 12) = 0.6 months (< 3 weeks)

ROI Curve

Diagram

Both scenarios show payback within the first 3 months. By month 12, the conservative scenario has saved $608K. The aggressive scenario has saved $2.3M.


Diagram

Defects from hidden dependencies (phantom chains, DI registration errors, cross-team mismatches) drop as features migrate to typed specifications. After month 6, they approach zero — because the compiler catches them at build time instead of in production.

Diagram

Before migration: 2.5 hours to understand one feature (grep, trace ServiceLocator, read Jira). After Sprint 2: migrated features take minutes; unmigrated features still take hours. After Sprint 9: all features are types — 1 minute per feature.

Diagram

Before migration: changing a file in MegaCorp.Core triggers rebuilds of 40+ projects (95 seconds). As code moves from MegaCorp.Core to feature-specific projects, the blast radius of each change shrinks. After Sprint 9: MegaCorp.Core is deleted; changes to a feature project rebuild only that project and its dependents (35 seconds).

Diagram

Starting from 0% (no ACs in code) to 100% (all 37 ACs have [Verifies] tests). The curve is not linear — early sprints migrate the largest features (Order Processing has 8 ACs), creating big jumps.


Total Cost of Ownership: 3-Year View

Year Status Quo (No Migration) With Migration
Year 1 $740K - $2.4M $112K (migration) + $20K (maintenance) + $185K (remaining waste during migration) = $317K
Year 2 $740K - $2.4M $20K (maintenance) = $20K
Year 3 $740K - $2.4M $20K (maintenance) = $20K
3-Year Total $2.2M - $7.3M $357K
3-Year Savings $1.8M - $6.9M

The migration pays for itself within 2 months. Over 3 years, it saves between $1.8M and $6.9M compared to maintaining the status quo.


Intangible Benefits

Some benefits don't have a dollar value but are strategically significant:

1. Recruitment and Retention

Developers prefer working on well-structured codebases. A monorepo with typed requirements, IDE navigation, and compiler-verified traceability is more attractive than a ServiceLocator spaghetti. This affects:

  • Time to fill open positions
  • Offer acceptance rates
  • Developer retention (reduced turnover)

2. Architectural Confidence

With logical boundaries, teams can make changes confidently. "Will this change break something?" has a compile-time answer instead of a runtime prayer. This enables:

  • Faster delivery
  • Bolder refactoring
  • Less fear of touching legacy code

3. Knowledge Preservation

When a senior developer leaves, their knowledge of "which code implements what" leaves with them. With Requirements as Projects, that knowledge is in the type system. It survives any amount of turnover.

4. Regulatory Readiness

For organizations entering regulated markets (healthcare, finance, automotive), the traceability matrix generated by the Roslyn analyzer satisfies audit requirements out of the box. Without it, achieving compliance requires months of manual documentation.


When NOT to Migrate

This architecture is not free. It has costs. Don't migrate if:

  1. The monorepo has < 10 projects. The overhead of Requirements + Specifications + Analyzers isn't justified for small codebases.

  2. There's only one team. The compiler-as-coordination-mechanism is most valuable for multi-team organizations. A single team can coordinate via conversation.

  3. The codebase is being replaced. If the plan is to decommission the monorepo within 12 months, don't invest in migrating it.

  4. There are no cross-cutting features. If each project is a self-contained microservice with no shared business features, the value of cross-project traceability is minimal.

  5. The team doesn't write tests. Without [Verifies] tests, the traceability matrix is incomplete. The architecture still provides value (spec enforcement, IDE navigation), but the ROI is lower.


The Executive Summary

Question Answer
What does it cost? $112K one-time + $20K/year maintenance
What does it save? $740K - $2.4M per year
When does it pay back? 2-3 months
What's the 3-year ROI? 500% - 1900%
What's the risk? Low — incremental migration, no big-bang rewrite
What breaks during migration? Nothing — old and new architectures coexist
Who needs to approve it? Architecture team + affected feature owners
How long does it take? 9 sprints (4-5 months) for 8 features

The monorepo doesn't need microservices. It doesn't need a rewrite. It needs two new projects, a Roslyn analyzer, and 9 sprints of incremental migration. The compiler handles the rest.


Series Conclusion

This series started with a question: does Requirements as Code survive at industrial scale?

The answer is yes — not because it's elegant, but because it's structural. The compiler doesn't care how big the monorepo is. It cares whether the types are satisfied. And types scale.

Post Key Insight
Part 1: The Problem Industrial monorepos grow organically. ServiceProvider becomes the god-object. Nobody knows which code implements which feature.
Part 2: Physical vs Logical DLLs are packaging, not architecture. Physical boundaries answer "where?" — logical boundaries answer "what?" and "why?"
Part 3: Requirements as Projects Two new projects (Requirements + Specifications) create compiler-enforced logical boundaries. Features are types. ACs are abstract methods.
Part 4: At Scale The AC cascade propagates changes across 15 teams through compiler errors. Feature traceability: 1 second, not 2.5 hours.
Part 5: Migration Incremental migration — one feature per sprint, adapter pattern for legacy code, no big-bang rewrite.
Part 6: ROI $112K investment. $740K - $2.4M annual savings. 2-month payback. 3-year ROI: 500% - 1900%.

The requirements project is not documentation. It's not metadata. It's a compilation unit — the most important one in the solution. It's where the business tells the compiler what it wants, and the compiler tells the developers what's missing.

Physical boundaries are packaging. Logical boundaries are architecture. The compiler enforces both. That's what scales.


Previous: Part 5 — Migration: One Feature at a Time

Back to: Part 1 — The Industrial Monorepo Nobody Planned