Scalable Isn’t Just a Buzzword: 3 Steps to Future-Proof Your Lab
Scalable gets thrown around a lot in lab informatics conversations, often as a stand-in for “good or “modern”. Laboratory Informatics Consultant Amanda Kailher asked Team KC consultants Xandria Kovacic, Angel Kleiman, and Haley Gallagher what scalability means to them, what it really means in practice, and where they've seen it go wrong.
Their answers all point to the same conclusions: Scalability isn't a feature of an ELN or LIMS; it's a set of decisions you make early, or pay for twice.
What does 'scalable' actually mean?
It’s tempting to think of scalability as a task to predict the future and build the system for what the lab will look like in two years. Our team pushed back on that framing directly.
As Xandria put it: "Scalable does not mean predicting the future; it means anticipating potential changes and choosing solutions that will be the least painful to evolve over time."
For a director evaluating a system investment, this reforms the ROI question. You're not trying to find a system that matches the forecast; you're looking for a system (or data model!) with flexibility for when the forecast turns out to be wrong. “Does this fit our current process?” is still an important question, but “what would it cost us in terms of time and money, to change this if we had to in 18 months?” is just as important.
Angel framed it similarly, acknowledging that the science is going to keep changing means creating a solution that is "flexible enough to evolve, to handle larger amounts of data and age well without having to overhaul the whole system.”
The distinction is what matters. You're not trying to guess the future correctly; you're trying to make sure that whatever the future turns out to be, your system can bend toward it instead of breaking.
Anticipating change means designing decision points, a permission structure that can grow as new team members or new teams are created, and a workflow that can absorb a new instrument without a rebuild.
1.Standardize your data model before you scale
Data models tend to fail quietly at first. Usually in two directions. A table works fine for a handful of samples, a handful of parameters, a handful of use cases. The trouble starts when growth exposes assumptions nobody knew they'd made.
Over-specification: Angel pointed to one common failure mode: building tables that are too specific too early. "A data model where every table in the system was extremely specific to one type of sample or unit operation.” It works until “every time they work on a sample that falls in between, they spin up a new entity or material table for it.” Until the schema is essentially unusable by anyone outside the person who built it. This is a knowledge continuity risk as much as a technical one. Institutional understanding of the schema and how it evolved to look like that, lives in one person’s head. Introducing liability for countless datasets if that person leaves.
Over-generalization: The opposite failure mode is just as common, and maybe more familiar: one table that keeps absorbing everything. Haley Gallagher described it this way: "Early on, speed and flexibility matter most. The team just needs to record a few parameters across processing steps, so they start with a single result table. As the research questions evolve, that table keeps growing organically to cover every step.” Over time, a data model built to capture dialysis breaks when a lab moves to TFF, without planning for it in the initial dialysis build.
Xandria added a governance-related challenge that surfaces as organizations mature: reconciling data generated externally versus internally. Her example? In-house vs. vendor-synthesized oligos. “An oligo remains an oligo” but inconsistent schemas make the two impossible to compare cleanly.
She also noted that even a technically sound schema can fail if it's not built with the end user in mind: "As throughput increases, issues often arise with data entry rather than the data model itself. The underlying schema might be sound, but we may need to find creative ways to reduce the burden on users." particularly for high-volume workflows like NGS sample prep.
What this means operationally:
Create data models that suit categories rather than instances: Buffer exchange vs Dialysis. Oligo vs. Vendor Oligo.
Set (and follow through with) data model review, rather than reviewing reactively once something breaks
Treat data entry burdens as a design criterion, not an afterthought.
A good data model isn't the most specific one, and it isn't the most generic one either. It's one that reflects how the science actually changes as a team scales, built with enough structure to stay usable, and enough flexibility to stop being rebuilt from scratch every time something new comes through the door.
2.Define permissions and roles early
Permissions rarely feel urgent until they suddenly are. Teams that start with open access because it's fast and frictionless often don't realize that's a liability until the organization, and its regulatory obligations, have already outgrown it.
Xandria put it plainly: "One of the greatest challenges is realigning team expectations, especially if they are accustomed to elevated system permissions. Organizations that began with open permissions during their early, smaller stages may only realize it is a problem later on.” Angel echoed this, and added that it's not just about locking things down: "it's the data governance conversations that come out of it." Restricting a role often surfaces the fact that ownership and approval authority were never formally defined.
Loosening permissions carries its own risk, too. As teams grow and introduce superusers, Angel noted, "those can be just as painful because now you're letting people edit templates and other pieces, so you really need them well trained to keep things in sync between tenants."
Whether a lab is tightening or expanding access, the principle is the same: permissions are a governance decision, not just a technical setting. Getting ahead of that conversation, before growth forces it, makes it a planning exercise instead of a crisis.
3.Document technical workflows now, not later
A flow diagram is a governance asset, not a nice-to-have. Scalability isn't only about structure and access controls. It's also about whether anyone besides the person who built the system can explain how it works.
Angel described how much easier the process is when a client arrives with a scientific or business flow diagram already mapped out. It shows “how their product is made, what teams it moves through, and where it gets tested for scale up.” Giving our team a head start that can often skip whole discovery calls.
For any team, the ROI of creating the documentation early is direct. An undocumented workflow means knowledge is concentrated in specific individuals, meaning any change, evaluation, or audit request has the added steps of hunting down the ‘who knows what’ of the workflow. Although this problem doesn’t announce itself as prominently on a smaller team, once work starts to separate and teams start to grow, silos rapidly follow.
The cost of waiting
Every example above shares the same shape: a decision that felt reasonable at a small scale created real friction at a larger one. None of these are failures of intent. They're what happens when short-term speed and long-term flexibility aren't weighed against each other early enough.
Haley Gallagher summed up the real payoff of getting ahead of it, describing a transition she watched happen firsthand: "We saw this recently with a client, it took real convincing to break the steps into manageable pieces, but the payoff was a far more flexible and robust system, right as the team shifted from asking 'what are we making' to 'how do we make it.'"
A data model rebuilt after years of exceptions costs more than one designed with governance in mind from the outset.
The actual test of scalability is not whether a system was built for a future you correctly predicted, but whether it lets your team keep asking better questions as the science moves forward. Standardizing your data model, defining roles and permissions, and documenting your workflows now doesn't just prevent rework later. It's what allows a lab to keep growing without growing out of its own systems and it’s the lowest-cost point at which these type of decisions will ever be made
Why this is hard to see from the inside
Every pattern in this post is easier to spot from outside the organization. Teams close to a system stop seeing the workarounds they’ve built around it. When people are responsible for both running the science and making the infrastructure work underneath it, blinders go on to the extra steps, the permission nobody remembers granting, and the 10 fields no one remembers adding to that table.
This is where a vendor-agnostic, technically and scientifically fluent second set of eyes earns its cost back. A system health check is the fastest way to find out where your lab sits on these three fronts before growth forces you to notice. Contact us to get the conversation started.
