Should you build or buy your digital pathology IMS?

November 18, 2025

For IT leaders, informatics teams, and lab directors evaluating whether to develop an in-house image management solution

‍

At some point in almost every serious digital pathology program, someone raises the build question.

Usually it surfaces after a frustrating experience with a commercial IMS that didn't deliver on its promises, or during a procurement process where the available options feel like imperfect fits, or when an IT team with genuine software engineering capability looks at the feature list of an enterprise IMS and concludes: we could build that.

It's a reasonable instinct. The organizations asking this question are typically sophisticated — they have technical talent, they understand their own workflows better than any vendor does, and they've seen what happens when you inherit a platform that wasn't designed for your specific needs. The appeal of specialized, fully controlled internal software is real.

So is the gap between the appeal and the reality.

This article makes the case for why building an in-house IMS almost always costs more, delivers less, and creates more long-term risk than selecting the right commercial platform — and gives you the framework to stress-test that conclusion against your organization's specific situation.

Why the build option looks attractive

Before addressing why build rarely works out, it's worth being honest about why it looks compelling.

You know your workflows better than any vendor. Commercial IMS platforms are built for a broad market. They make design decisions that reflect the needs of many customers, which means they inevitably don't perfectly reflect the needs of any single one. An internal build, in theory, could be designed exactly for how your lab works — no compromises, no workarounds, no features you don't need crowding out the ones you do.
You want control over the roadmap. Commercial vendors set their own priorities. Features you urgently need may sit in a backlog for months or years. An internal build means you decide what gets built next and when.
You have technical talent. Many research institutions and large biopharma organizations have substantial software engineering capability in-house. The question of whether you can build is often easier to answer than whether you should.
You're concerned about vendor dependency. If a commercial vendor gets acquired, pivots its product strategy, or exits the market, you're exposed. An internal build eliminates that single point of failure — or appears to.

These concerns are legitimate. They're also addressable through the right commercial platform selection, vendor evaluation, and contractual arrangements. But they're worth taking seriously rather than dismissing, because the labs that end up building in-house often do so because their commercial IMS experiences haven't given them reason to trust the alternative.

What building an IMS actually requires: the challenges

The feature list of an enterprise IMS looks, on paper, like a tractable software engineering problem. A web application, a storage layer, an image viewer, some metadata management, access controls. Teams with strong full-stack engineering capability reasonably estimate they can cover this scope.

What that estimate tends to undercount — significantly — is the domain-specific engineering complexity that makes digital pathology image management fundamentally different from most enterprise software development.

Whole slide image streaming is a hard problem

Whole slide images are not served like ordinary web content. A single image can contain billions of pixels organized in a pyramidal tile structure, designed to support smooth, high-performance zoom and pan across a range of magnification levels. Streaming this efficiently in a browser — without making users wait for tiles to load, without consuming excessive bandwidth, without degrading under concurrent multi-user load — requires specialized image server infrastructure and client-side rendering logic that has taken commercial vendors years and substantial engineering investment to optimize.

Building a viewer that pathologists consider acceptable for daily use is not a weekend project. Building one that performs well at enterprise scale, across a range of whole slide image formats from different scanner vendors, with support for specialized modalities like multiplexed immunofluorescence, is a multi-year engineering program.

Format support is a moving target

The whole slide image format landscape is fragmented and proprietary. Every major scanner vendor produces images in its own format — SVS, NDPI, SCN, MRXS, CZI, QPTIFF, and others — each with its own compression schemes, metadata structures, and quirks. Supporting these formats reliably, handling edge cases and version variations, and keeping pace as scanner vendors update their formats requires ongoing engineering attention that has nothing to do with building new features.

Open-source libraries like OpenSlide provide a starting point for format support, but they are not a complete solution. Production-grade format handling at enterprise scale requires additional engineering on top of available open-source foundations, and active maintenance as formats and libraries evolve.

Compliance infrastructure is not bolted on

For labs with GLP, GCP, or 21 CFR Part 11 obligations, compliance is not a feature — it's an architectural property. Audit trails that satisfy regulatory requirements need to capture the right events at the right granularity, store them in a tamper-evident way, and be exportable in formats that satisfy auditors. Access controls need to operate at the study and case level, not just the file or folder level. Electronic record and signature workflows need to meet specific regulatory standards.

Building this correctly from the ground up requires regulatory expertise alongside software engineering expertise — a combination that is genuinely rare. Getting it wrong has consequences that extend beyond the software: a system that fails a GLP audit because its audit trail doesn't meet documentation standards is not just a technical problem.

Equally important: commercial IMS vendors with validated compliance infrastructure have already produced the validation documentation packages — IQ, OQ, PQ — that regulated labs need to demonstrate system validation to auditors. An in-house build requires producing that documentation internally. The engineering effort to build the system is only part of the compliance burden.

Integration maintenance is an ongoing obligation

An IMS that doesn't integrate with your LIMS, your scanners, and your analysis tools is not much of an IMS. Building those integrations is one engineering investment. Maintaining them as vendor APIs change, as new scanner models are released, and as analysis platforms update their interfaces is a perpetual one.

Commercial IMS vendors maintain integration libraries as a core business function. Their survival depends on keeping those integrations current. An internal team maintaining a bespoke IMS has no such forcing function — integration maintenance competes with feature development, security patching, performance work, and whatever else the IT roadmap demands. Over time, integrations drift. Manual workarounds accumulate. The system that was designed to eliminate manual processes gradually reintroduces them.

The total cost of an in-house build

Build-versus-buy analyses often compare the upfront cost of commercial licensing against an estimate of internal engineering effort. That comparison systematically understates the true cost of building in-house:

Initial development. A production-grade IMS — with performant image streaming, multi-format support, compliance infrastructure, and integrations — requires a dedicated team of experienced software engineers for two to four years at minimum before it reaches feature parity with established commercial platforms. The fully loaded cost of that engineering team, including salaries, benefits, and infrastructure, is substantial.
Ongoing maintenance. Software doesn't maintain itself. Security vulnerabilities need patching. Format support needs updating. Performance needs tuning. Infrastructure needs managing. Integrations need maintaining. The internal team that built the system is the team responsible for all of this — indefinitely. The "build" cost is not a one-time investment; it's a commitment to an ongoing operational budget.
Opportunity cost. Every engineer working on an internal IMS is an engineer not working on the problems that are actually core to your organization's mission. For a biopharma, that might be computational biology tooling. For a CRO, it might be client-facing capabilities or LIMS enhancements. The question isn't just "how much does the IMS build cost?" — it's "what don't we build because we built this instead?"
Compliance documentation. As noted above, the validation documentation required for regulated environments is a significant output that must be produced alongside the software itself. This work is typically unfamiliar to software engineering teams and requires specialized expertise to complete correctly.
‍User experience debt. Commercial IMS platforms have invested years in understanding how pathologists actually work — in optimizing viewer performance, navigation patterns, keyboard shortcuts, study organization workflows, and the dozens of small decisions that determine whether a platform feels fast and intuitive or slow and frustrating. An in-house build starts from zero on this dimension. Reaching the UX quality of a mature commercial platform takes longer than most build estimates anticipate, and the gap in user experience during that period has real productivity costs.

What in-house builds typically look like in practice

The pattern that emerges across organizations that have attempted in-house IMS development is remarkably consistent.

Year one and two: Strong initial progress. The core viewer works, basic storage and organization is functional, the team is energized. The internal solution handles current needs and there's optimism about the roadmap.
Year three: The backlog of feature requests has grown faster than the team can address it. Format support for a new scanner model has been waiting for six months. A LIMS integration that was scoped for Q2 is still in progress. Pathologist feedback on the viewer is mixed — it works, but it's slower than they'd like and lacks several capabilities they've come to rely on in other tools.
Year four and beyond: The system is increasingly characterized by what it doesn't do. Integration with a new analysis platform is blocked on engineering bandwidth. A compliance audit has surfaced gaps in audit trail documentation. The team that built the original system has partially turned over, and institutional knowledge about certain architectural decisions is fragmentary. Leadership is beginning to ask whether the investment is still justified.

This is not a hypothetical. It is the pattern that emerges when organizations attempt to build and maintain specialized enterprise software in a domain that is not their core business. Digital pathology image management is a hard, domain-specific problem — and the commercial vendors who specialize in solving it have years of investment and iteration that an internal build must replicate before it can compete.

When does building make sense?

The case against building is strong, but it's not absolute. There are circumstances where internal development is a legitimate approach:

Highly specialized, genuinely novel workflows that no commercial platform addresses and that represent a meaningful competitive advantage worth protecting. If your organization has developed a proprietary imaging modality or analytical approach that requires specialized infrastructure, and if that infrastructure is core to your competitive differentiation, building may be justified.
Internal tools that complement rather than replace a commercial IMS. Building internal tooling that extends a commercial IMS through its open APIs — custom reporting dashboards, bespoke workflow automation, proprietary analysis integrations — is a different calculus from building an IMS replacement. This approach captures the benefits of internal development (customization, control, roadmap ownership) without taking on the full burden of maintaining core infrastructure.
Research prototypes and proof-of-concept systems. Academic and research environments that need experimental infrastructure to explore new approaches — and that don't have compliance obligations or production scale requirements — have more latitude for internal development. The risk profile is different when the consequences of failure are a failed experiment rather than a disrupted clinical or regulatory workflow.

What these exceptions share is specificity: they involve building something genuinely novel, or building at the edges of a commercial platform rather than replacing it. They don't involve building a production-grade enterprise IMS to replace commercial alternatives that are built specifically for that job.

The right question isn't "can we build it?" — it's "should we?"

Technical capability is rarely the binding constraint. Organizations that ask the build question have usually concluded that they can build an IMS. The more useful question is whether that's where the engineering investment should go.

Specialized commercial IMS platforms have been maturing for over a decade. They have accumulated engineering investment — in image streaming performance, format support, compliance infrastructure, integration libraries, and end-user experience — that would take years and significant resources to replicate. The gap between a mature commercial platform and a year-one internal build is measured not in features, but in the accumulated learning of thousands of hours of pathologist feedback, edge cases encountered in production, and infrastructure performance tuning under real-world load.

The labs that have tried to close that gap internally have largely concluded that the effort wasn't worth it — not because their engineers weren't capable, but because building and maintaining specialized enterprise infrastructure is a full-time business, and running a pathology lab (or CRO, or biopharma research function) is a different one.

The decision to buy a commercial IMS isn't a concession to technical limitations. It's a strategic choice to focus internal capability on the problems that actually differentiate your organization — and to let a vendor whose entire business depends on solving the image management problem do exactly that.

Evaluating the commercial alternative rigorously

If the conclusion is to buy rather than build, the quality of the commercial platform selection matters enormously. A poor commercial IMS — one that doesn't integrate with your systems, doesn't support your scanner formats, or doesn't meet your compliance requirements — will reignite the build conversation faster than anything else.

The evaluation criteria that matter most are covered in detail in our IMS Evaluation Checklist, but the headline priorities for organizations that have seriously considered building are:

Integration openness. Does the platform offer documented, stable APIs that let you build the custom integrations and extensions your workflows require? An IMS with open integration architecture gives you the customization benefits of building without the maintenance burden.
Format and scanner breadth. Validate format support against every scanner in your current and anticipated environment before committing.
Compliance documentation. For regulated workflows, ask for the validation documentation package upfront. The quality and completeness of that documentation is a direct indicator of how seriously the vendor takes regulated environments.
Roadmap transparency. A vendor willing to share their product roadmap and engage on your specific feature priorities reduces the "we control our own roadmap" argument for building.
Vendor stability. A commercial platform is only a better long-term bet than an internal build if the vendor is likely to be around and investing in the product. Evaluate financial stability and market position alongside product capabilities.

‍

Wondering how PathcoreFlow addresses your specific workflow requirements?
Talk to a solutions expert →
‍Download the IMS Evaluation Checklist →

‍

This article is part of Pathcore's digital pathology resource hub. For related reading, see:

‍