Quantity Is the Path to Quality

“You don’t get to quality by aiming for it. You get there through quantity.”

Everyone has heard the phrase: “Quality over quantity.”

Sounds wise. Sure.
In a world full of noise, we want signal.
In complex systems, we want fewer, better solutions.

But in my experience with LIMS implementations, quality doesn’t come instead of quantity.

It emerges from it.

The Perfection Trap

In lab informatics projects, the pursuit of quality can become its own trap.

• Endless planning.
• Gold-plated requirements.
• Bloated specs no one reads.
• Delays because “we need to get it right.”

But here’s the truth: you won’t know what “right” looks like until you’ve built the wrong thing a few times.
That’s not failure. That’s the process.

I've argued in the past that, "Good Enough, is Great". Read about here.

The Real Formula: Iteration + Feedback

What people call “quantity” is often just doing the reps.

• Building version 1, demoing it, hearing crickets.
• Building version 2, demoing again, getting slightly warmer.
• Version 3? That’s when people start nodding.

It’s not random trial and error. It’s deliberate iteration with feedback loops.
And this is where Naval’s version of mastery hits home:

“It’s not 10,000 hours. It’s 10,000 iterations.”

Speaking of Naval, check this article out if you'd like to hear why I think every LIMS implementation is a start-up.

Quantity Reveals What Quality Actually Looks Like

In many LIMS projects, the “quality” we think we’re aiming for is just a guess.
A persona. A workflow diagram. A BRD.

But when users see a working demo, things change:

• “Oh, I didn’t realize I needed to track that.”
• “Wait, that dropdown needs 5 more options.”
• “Actually, this doesn’t match how we do things in the prep room.”

No amount of planning will uncover those insights like three quick iterations will.

But What About Bad Reps?

A fair question:

“If you do something wrong 10,000 times… aren’t you just reinforcing bad habits?”

Absolutely—if you’re iterating in a vacuum.

But that’s not what we’re talking about here.
This isn’t brute force. It’s iteration with feedback.

Each cycle in a LIMS implementation should close with:

• A user seeing it.
• A conversation about what worked.
• A clear adjustment before the next pass.

That’s what makes the reps useful.
You’re not practicing the wrong thing—you’re testing, correcting, and refining.
Deliberate iteration is what turns quantity into quality.

Stop Aiming. Start Looping.

If you’re leading a LIMS implementation, the most powerful move isn’t to plan longer.
It’s to build faster, test earlier, and loop more often.

Every iteration is a vote for clarity.
Every feedback loop is a correction toward quality.

Don’t wait for quality to show up. Create the conditions where it can emerge.