Total Lifetime Revenue Loss in Case of Delays in Development of a Product

Medical Devices

12/7/2025

Motivation

This project calculates the total revenue of a product sold on the market in an:

• ideal case (no delay in development), and
• delayed case (delay in development),

to showcase what impact deficiencies in the product, or in the product documentation, have when regulatory bodies reject a submission of a manufacturer for market clearance of a medical device.

The code is available in my GitHub repository, together with documentation, see https://github.com/DirkMueller8/DelayedTotalRevenue

Input and output

Input to the software is:

1. Length of the ramp-up time period (in weeks)
2. Length of the maturity plateau time period (in weeks)
3. Peak revenue (in units of currency/week)
4. Delay (in weeks)

Output of the software is:

1. Total lifetime revenue of an ideal case
2. Total lifetime revenue of delayed case
3. Absolute loss as a result of the delay
4. Relative loss as a result of the delay (in %)

Where the idea came from

In a presentation [1] of a MedTech symposium organized by Vector Informatik GmbH, the impact of delays on the total sales volume in medical device projects was highlighted. Another source [2] confirmed that the delay does not merely shift the whole (ideal) curve to the right: it also diminishes the peak revenue.

A delay to market cannot be compensated by a steeper ramp-up time. Moreover, because of the loss of the state of the art due to competition at a fixed point in time, the decline happens at the same time as in the ideal case. Hence, the financial impact is negatively affected by two effects modelled in this software:

• less time to sell the product
• smaller peak revenue

Other effects not modelled in this software:

• opportunity cost of prolonged team allocation
• revenue generated later in time -> Net Present Value is reduced (higher financing costs)

Example case

In this example, I assume the following:

1. Length of the ramp-up time period: 104 weeks (2 years)
2. Length of the maturity (plateau) time period: 416 weeks (8 years)
3. Peak revenue: 200.000 Euro/week
4. Delay: 12 weeks (3 months)

This means the product - in the ideal case - is on the market for 12 years.

This comparatively small delay, typical for the time of a resubmission of documents to the regulatory body, results in a relative loss of 11,5% in lifetime revenue!

Technical description

The code was written in C# 13 and .NET 9.0, and implemented as a command-line application.

Components and responsibilities

• Program - CLI entry point; orchestrates input/output and calls the calculator
• IDelayCalculator - abstraction for calculation operations (enables substitution and testing).
• DelayCalculator - concrete logic: input validation and calculation helpers (ComputeIdealPieces, ComputeDelayedPieces, ComputeLosses)
• CalculationResult - immutable Data Transfer Object (DTO) that carries computation outputs
DelayedTotalRevenue.Tests - unit and integration tests (exercise DelayCalculator and Program)
• .github/workflows/dotnet.yml - CI pipeline that builds and runs tests.

How this reflects clean‑code (SOLID) principles

SOLID design principles in C# are basic design principles. SOLID stands for Single Responsibility Principle (SRP), Open closed Principle (OSP), Liskov substitution Principle (LSP), Interface Segregation Principle (ISP), and Dependency Inversion Principle (DIP).

Robert C. Martin compiled these principles in the 1990s, supported by his great book "Clean Code" [3]. These principles provide us with ways to move from tightly coupled code and little encapsulation to the desired results of loosely coupled and encapsulated real business needs. This fosters maintainability, scalability, and long-term software quality.

Single responsibility principle

Each class has one focused role (DelayCalculator does calculations; CalculationResult only holds data; Program handles I/O).

Open closed principle (OSP)

IDelayCalculator lets new implementations be added without modifying callers.

Liskov substitution principle (LSP)

The abstraction (IDelayCalculator) is paired with a concrete DelayCalculator that adheres to the interface contract (same signature, documented preconditions/exceptions, and consistent return semantics).

Interface segregation principle (ISP)

This principle is fulfilled by exposing a narrow IDelayCalculator interface with only the Calculate(...) contract while keeping validation and helper methods private inside DelayCalculator, so callers depend only on the minimal API they need.

Dependency inversion

High‑level code depends on the IDelayCalculator abstraction, not the concrete DelayCalculator.

Small, focused methods

ValidateInputs, ComputeIdealPieces, ComputeDelayedPieces, ComputeLosses improve readability and testability.

Other items improving the code quality

Readability & naming

Descriptive names and XML docs make intent explicit; public API documented via summaries and tags.

Testability

Logic is decoupled from Console so unit tests can exercise behavior in isolation; integration tests capture Console.Out when needed.

Fail‑fast validation

ValidateInputs enforces preconditions consistently.

Test-driven development

Non‑breaking option by adding functionality

The idea is to first write a unit test that defines the input and expected output e.g. for the impact of a product recall on the total revenue. Then run the test and have it fail. Next, add a dedicated method on DelayCalculator (e.g., CalculateWithRecall(...)) and run the unit test; keep IDelayCalculator unchanged.

Alternative (if recall must be part of public contract)

Add an overload to IDelayCalculator and update implementations.

How to plan testing

Add tests in DelayedTotalRevenue.Tests, run locally via dotnet test, then CI will validate on push. It is important to keep the public API stable. Hence, adding new methods, instead of changing existing signatures, supports the testability and maintainability of the software. Add a unit test per behavioral change and a small integration test when the CLI is extended.

Documentation (README + Mermaid)

Keep documentation close to the code and repository, so architecture and intent remain synchronized.

Summary

It’s always rewarding to practice semi-professional coding through examples that clearly illustrate specific problems touching on the medical device business.

References

[1] Bernd Schleimer (TÜV Rheinland), presentation at Vector Medical Engineering Symposium 2025 (Karlsruhe, Germany), https://medical.vector.com/engineering-symposium-2025

[2] Whitepaper "Kürzere Time-to-Market", published by Product Manage Mentor, https://www.produktmanagementor.de/pm-ressourcen/

[3] Martin, Robert C. Clean Code: A Handbook of Agile Software Craftsmanship. Upper Saddle River, NJ: Prentice Hall, 2009

Go back