What EHS Software Actually Costs (Beyond the License Fee)

A few weeks ago, I took my son fishing. He’d found a pond tucked down in the woods and wanted to check it out, so we turned off onto a little dirt road. The first stretch was littered with potholes, some of them eight inches deep. I was crawling along at 5 miles an hour, genuinely worried about bottoming out. Then the dirt turned to gravel. Bumpy, but I could get up to 15.  

And then, for the last stretch down to the water, the road was paved, and we were cruising.

I've thought about that road a lot since. Stretch the metaphor a bit, and it’s exactly what buying and standing up lab software feels like. Some vendors put your scientists on that pothole road and hope they just tough it out. Most people don't tough it out. They give it a shot, decide it’s not worth the suspension damage, turn around, and don’t come back.

If you’re the director or VP who signs off on an EHS purchase, your job is to figure out, before the contract is signed, which road you’re buying. The license fee alone won't tell you.

In fact, the license fee is the wrong starting point

The most common mistake I see buyers make is opening the conversation with "Just tell me what the license costs. We'll figure out if it's a fit."

I evaluate software regularly myself, and I never start there, because I know the risk that comes with it. The questions I ask first are different:  

• Here's the problem we're trying to solve. Is this a good fit?

• How long does it historically take for a company of our size, with our needs, to stand this up and get it live?  

• Is custom work needed?  

• Are services, support, and consulting included in that fee, or am I going to discover a cap on support hours three months in?

And most importantly:

• Will my team actually use it?

That last one matters more than people think. A low license fee is often low because something was taken out: the implementation timeline that nobody commits to, the pre-built configurations that don't exist, the support that turns out to be outsourced. You can absolutely get the cheap license. What you’re really paying for is the privilege of helping that vendor figure it out on the fly, and figuring it out on the fly is tremendously expensive.

And it doesn't stop at the vendor's invoice. Add your own IT security requirements and the fees to plug whatever holes the license doesn't cover. Add the internal resources: the meetings, the brainstorming sessions, the hours your IT, legal, and lab operations people sink into a stalled rollout. I hear it constantly from teams who chose the low bid and call us six months later:  

‍"Everything you said about the hours of meetings, it's happening."

People wave this away with, "We're already paying those salaries, so we don't track it." That's a line-item view of a business decision. The right question is what the impact is on the whole organization, not whether one budget row looks good.

If scientists don't use it, you might as well spend $0

The number one question I hear from scientific organizations is "Will our scientists and researchers actually use this?" And it really is the right question. I cannot tell you how many projects I walk into where a quarter or a third of the scientists are using the existing system, and the rest are being pushed and enforced into it.

Because if the users don't adopt the technology, then what was the point of any of it? If the license fee is X and you're getting nothing out of it, you may as well have not invested in it in the first place.

I said something at an event recently that I stand by: forcing your scientists to change the way they work won’t make it easier for them to adopt something new.

Sure, you could push for a change, and once in a while that works. Or you could involve them in the process, set clear goals, help them understand why things are changing, and the good it does for them. Choosing the latter route shifts your efforts towards the 30% of digital transformations that end up succeeding down the line.

Scientists who’ve been let down by a poor system will scrutinize every piece of the next one, and they should. They were handed something that hurt them instead of helping them. The software has to genuinely reduce their administrative burden, and someone has to explain the why.

Get both right and the usual three-way friction between scientists, operations, and the safety/compliance team starts to melt away. Get either wrong and you're back on that pothole road.

So, when you evaluate vendors, evaluate for adoption. Ask other organizations in the community about what their experience was. Did they get quick adoption? What was the speed to value? Those answers predict your outcome far better than the quote does.

The customization trap

Here's a pitch that sounds great in a demo:

"We'll customize whatever you want."

And here's why that should sound the alarm bells right away: to get a vendor to build exactly what you need, you have to communicate the problem, the desired solution, and the requirements with near-perfect clarity, then sit in the feedback loop of building, testing, and re-testing until it's right.

‍Most software providers will tell you that's not a heavy lift. That’s just not true. It is a very heavy lift, and people underestimate all the things it consumes: time, cost, resources, expertise. Not to mention the opportunity cost that your organization loses by not spending time on other critical projects.

I watched one organization choose a vendor who promised all the development they asked for, on a timeline of under one year. When we crossed paths again around two and a half years later, the project was still in testing. Small groups were piloting pieces of it, but the people who were supposed to be in the system doing their jobs still weren't there.  

Think about the lost data and lost value across nearly three years of "almost live." We’re talking direct financial losses to your organization here, all of which need to be factored in before you make your decision.

Larger organizations will always need some custom work, and that's fine. The question to ask is how much of the system needs to be custom-built and custom maintained, because every custom workflow is also a maintenance commitment after go-live.  

What you want underneath is a platform that is configurable, one that adapts to your environment without being rebuilt from scratch for every new requirement.

The cheapest option might just end up costing you the most

Here’s a common pattern I’ve come across during procurement meetings. Three vendors are in play, all with their credibility and trust at stake. Someone points to the simplest thing to measure and says:

"This one is cheapest and on the call. They promised they can do everything the other two can."

Vendors will breeze through a demo, glaze over your requirements with a "Yep, we can do that," and leave out the parts that still need development under the hood. If a vendor guarantees a timeline, ask them to put their money where their mouth is: write it into the contract that if they don't deliver, you don't pay. Watch how the conversation changes.

Because here's the math on the downside. Say the cheap option saves you 10 or 20%. If adoption fails and you have to switch, every dollar you put into that license is gone. A 10% saving that becomes a 100% sunk cost means you could have run the better vendor for 5-7 years and still not lost as much.  

The shortest turnaround I've seen is a team that pulled the plug six months in. The longest stuck it out for two full years before admitting the system had never properly stood up. In the short term, "I put $10,000 back in the budget" is an easy thing to celebrate internally.  

When it unravels, your name is attached to it. And the strongest defense against this is both boring and effective: a written business justification.

A good business justification takes cost and flips it into a quality and risk conversation

And that's where leaders actually operate. Here are the vendors in play, here’s the one we recommend, and here’s why, across speed to value, adoption likelihood, risk, internal resource demands. Finally, here’s our take on whether this partner can scale with us for the next decade.

No organization plans to stay the same size for ten years. Your vendor has to be able to grow and change with you, and if you're not confident that they'll still be your partner ten years out, any energy you'll pour into standing them up isn't worth it.

I've typed out this story on a Mac. If I wanted the lowest cost machine, I wouldn’t be looking at Apple. I'm looking at reliability, quality, and speed, because I want to do my best work on it. Multiply that logic across hundreds or thousands of people who will touch your EHS system every week. An incremental gain per person adds up fast. An incremental loss adds up faster.

None of this means cost doesn't matter. It just means rethinking cost as your total cost of ownership. First, whittle the field down to the vendors who can genuinely deliver the experience and the outcomes you need. Once you’ve got your list of qualified vendors, that’s when price comes into the picture.

Get to that paved road and stick to it

Back at that pond, my son and I had a great afternoon, and the drive out on the paved stretch took no thought at all. That's the standard, or at least, it should be. When you stand up new software, your scientists should come out of the gate on pavement: moving, effective, no friction, no wondering whether the whole thing will bottom out.

Every dollar you didn't spend on implementation, support, and adoption is a pothole you're asking your scientists to drive over. They’ll try it once, maybe twice. Then they'll turn around and go home, and you'll be left holding a license fee for an empty road.

So, before you sign, ask the question the cheapest bidder hopes you won't. Not, "What does the license cost?" but rather:

"What will it cost us to get every scientist on to the paved road, and how fast can you get us there?"

The vendor who answers that one honestly, in writing, is the one worth paying for.