Why MedTech Software Slows Down as It Scales (While Amazon and Google Continue to Release Quickly)

Why MedTech Teams Slow Down as Software Grows and What Better Architecture Looks Like

Randy Horton

Published on: April 10th, 2026

When Growth Starts to Feel Like Friction

In MedTech, software rarely breaks all at once. It becomes harder to change.

As systems grow, features that should be straightforward take longer than expected. Teams hesitate before making updates.

Decisions stall because the impact of a change is unclear.

At the same time, companies like Amazon, Google, and Microsoft continue to scale their platforms while releasing updates continuously.

MedTech systems slow down as they become more complex. Big Tech systems do not.

The difference is not the pace of innovation. It is how the systems are built.

What looks like cross-functional friction often has a simpler cause.

It is usually the architecture.

That is the focus of Orthogonal’s upcoming webinar, Cloud-Native Architecture for MedTech (What You Can Learn from Amazon). The session looks at why platforms slow down as they expand and what separates teams that keep moving from those that gradually lose momentum.

In a recent conversation previewing the webinar, CTO Larkin Lowrey explained why many MedTech platforms become slower and riskier as they grow.

The Real Cost of Monolithic Systems

Larkin described what happens as systems grow without clear boundaries.

Over time, codebases become tightly interconnected. Engineers refer to this as “spaghetti code,” where changes in one area quietly affect many others. As a result, every update carries more uncertainty than expected.

That uncertainty shows up in ways leaders recognize:

More coordination is required for even small changes
Slower release cycles
Increased risk when deploying updates

The system becomes sensitive. A slowdown in one area can drag down performance elsewhere. A defect in one component can have wider consequences than expected.

At that point, adding features is no longer the challenge. Changing anything safely is.

How Modular Architecture Changes the Pace of Execution

Larkin offers a simple way to think about the alternative.

When multiple people work on the same section of a jigsaw puzzle, progress slows. When work is divided into clear sections, more people can contribute without interference.

Modular architecture applies that same principle to software.

It allows teams to:

Move in parallel without constant coordination
Contain the impact of changes
Scale development without increasing fragility

The result is not just cleaner systems. It changes how teams work day to day, especially as the system grows.

Architecture as a Lever for Regulatory Velocity

In regulated environments, architecture also shapes how quickly teams can deliver.

One of the more practical insights Larkin shared is how modular systems allow teams to separate software by risk level. If a small portion of the platform carries the highest level of concern, it does not have to dictate the pace of everything else.

“We’re not letting that 5% slow down the other 95%.”

This is especially relevant for connected devices and SaMD platforms. When high-risk functionality is isolated, teams can iterate faster on lower-risk components without compromising control where it matters most.

Instead of compliance slowing development across the board, it becomes more targeted and manageable.

Why Cloud Forces a Shift from Control to Resilience

Cloud infrastructure introduces a different constraint.

In traditional environments, teams validated a fixed configuration and tried to keep it unchanged. In the cloud, that assumption no longer holds. Infrastructure is updated continuously, often without direct visibility.

Larkin describes the shift as moving from point-in-time validation to continuous assurance.

This requires a different approach:

Expect change rather than trying to prevent it
Design systems that can tolerate variability
Monitor continuously and respond when needed

This applies beyond the cloud. It also shows up in mobile and BYOD environments, where devices and operating systems are constantly changing.

Stability no longer comes from freezing the system. It comes from building systems that can handle change without breaking.

Automation Creates Consistency, Not Just Speed

Automation is often framed as a way to move faster. In practice, its value is just as much about consistency.

With infrastructure defined as code, teams can recreate environments exactly. That makes it easier to test, validate, and diagnose issues without guesswork.

For organizations operating under regulatory oversight, this consistency supports more reliable validation and faster resolution of problems when they arise.

When Technical Debt Becomes a Cost Multiplier

When delivery slows, a common response is to add more engineers or increase infrastructure capacity.

Larkin points out that this can mask the real issue.

In systems with significant technical debt, teams spend much of their time working around the architecture instead of building new capabilities. Developers are “fighting the system” rather than delivering value.

The result is a compounding cost problem:

Larger teams are required to maintain the same pace
Higher infrastructure spend without proportional output
Longer timelines for delivering customer-facing improvements

In some cases, companies spend five to ten times as much to produce outcomes similar to those of teams with simpler, cleaner architectures.

Focus on What Actually Differentiates the Product

One of the more direct takeaways from the discussion is where not to spend time.

Capabilities like authentication, data storage, and monitoring are not sources of competitive advantage. Cloud providers already deliver these at scale, with stronger security and reliability than most teams can achieve internally.

Building them yourself adds cost and complexity without adding value.

The better approach is to rely on managed services for these foundational components and concentrate internal effort on what differentiates the product, such as clinical logic, workflows, and user experience.

How to Scale Without Increasing Complexity

MedTech companies are under pressure to expand software capabilities, connect devices, and deliver updates more frequently.

The challenge is doing that without slowing down or increasing risk.

This webinar looks at how architecture decisions influence that outcome. It shows how modular, cloud-native systems support faster iteration, reduce unnecessary coordination, and help teams maintain control in regulated environments.

If your platform is getting harder to change, this session will help you understand why and what to do next.

Join the Webinar

If your team is building SaMD, connected devices, or software-enabled medical solutions and finding that development is slowing as systems grow, this session will walk through a more effective way to structure your platform.

You’ll learn how to:

Use modular architecture to reduce coordination overhead and speed up delivery
Isolate higher-risk functionality so it doesn’t slow down the rest of the system
Shift from point-in-time validation to continuous assurance in cloud environments
Apply automation to create repeatable, testable systems that support regulatory needs
Focus internal teams on differentiated capabilities while leveraging cloud-managed services

If your roadmap feels harder to execute than it should be, or if adding features is becoming more expensive and riskier over time, this webinar will give you a clearer framework for moving forward.

Save Your Seat