Written by Jim Young, who ran an 8(a) certified environmental consulting firm from 1992-2015 prior to cofounding XForms.

Picture the scene

Orlando, Florida in June 2005 at 6:15pm at the FedEx shipping center next to the Orlando airport. It had just stopped raining buckets about an hour earlier.  Steam slowly rising off sidewalks and roads as the wetness of the ground evaporates.  Loud jet noises in the background, as FedEx planes take off.

And me, sitting down on a cooler, frantically jotting down monitoring well IDs, dates, times, and lab analyses to run on a 3-part chain-of-custody (CoC) form while another field tech pulls out sampling containers out of slushy ice and calls out well IDs as I write.  As much as I could, I’d write down using block letters, trying to avoid illegible hand writing and hand cramps. Drips of water and sweat land on the paper form, with a looming deadline to drop these damn coolers off before the cutoff for Next Day Air.

Not to mention the other field techs hustling, bubble-wrapping glass jars, ensuring that the sample bottles are accounted for and calling out well IDs, re-affixing soaked-wet labels that are sliding half-off the bottles, using massive amounts of shipping tape, while filling out the FedEx shipping forms.


Field work is hectic

Suffice it to say, the end of the day prepping samples for shipment is a hectic time of the day for a field tech.  All of us 4 field techs were tired from an entire day battling the sun, and then the rain, finding wells in overgrown grass, sometimes using a metal detector to find them.  Most times having to bail out stagnant water accumulated around the flush-mount well sump.  For some wells, having to figure out how to take off a well cover with rusted bolts, or trying to make sure you are sampling the right well that’s listed on the map because the old site map doesn’t illustrate any of the new surroundings.

And then there’s equipment malfunctions.  As a field tech, you have to be quick on your feet, McGyver-ing things that go wrong.  Because no matter how much you plan a field event, shit will inevitably go wrong.  I don’t think I’ve ever been on a field event where something didn’t go wrong.  It’s like a natural expectation.  You run out of field supplies.  A pump breaks.  An instrument gives you obviously erroneous readings despite having been calibrated right before the field event.  Snakes show up.  Yes snakes.  Or bees.  In a well. How do you sample a well that has a hornet’s nest next to it?  Did you bring wasp killer spray?  If you use that, will it impact the well sampling lab results?




The seed for solving the paper CoC pain

All of that field work pain is one thing.  It has to be done, and you mitigrate that pain as best as you can.  Regardless, the work itself has to be done.  However, having to deal with those paper chain of custody forms at the end of a long, tiring day while trying to beat the dropoff deadline is another thing.  It’s more stressful than you think. If you make a mistake on one of those forms, that mistake will have to be explained in the report. If the writing is illegible, the lab might record it as a different well ID.  Well ID OLD-36-15A is not the same as 01D-36-15A.  Well ID MW-3S is not the same as well ID MW-35.  And if you ship things out on a Friday for Saturday delivery, you take a chance that FedEx will screw up and actually deliver the cooler on Monday, rendering those samples useless due to temperature compliance failure.  This happens so often that we would merely avoid shipping on Fridays altogether, and just keep the cooler iced down in a hotel room.  But that doesn’t always work because some lab analyses have really short holding times.  I could go on and on about all the nuances of field work. But on with the story….

That got me to thinking…why the f*** are we having to fill out these dumb 3-part paper forms in the first place?

Those were the thoughts I was having waaay back in 2005.  But those were mere thoughts about a field work problem.  After a large field event, I’d forget about that paper chain of custody problem.

Life went on, working on more Navy and USACE projects, managing field crews, reviewing reports, QA’ing the analytical data, and then dabbling more and more in software tech after purchasing the Adesso source code in May 2008.

Around 2009 I started mocking up some screens about what a digital chain of custody form would look like.  But it wasn’t until the fall of 2011 that I got serious about it and really dove deep into designing it.  It was around this time that I learned how to use Balsamiq, which was at least an order of magnitude easier to use than the previous mockup software I tried.  I think I spent a solid 2 months designing screens.  I even came up with a name and registered the domain: ezCoC.com.  More on this horrible name later in the story.

Here’s a few of the original mockups.  Remember, this was in 2011, when Facebook was king and when I had grandiose ideas for this tool, like connecting a community of environmental field techs and labs together.

ezCoC development cycles

I hired a software development team from Pune India called Epicomm to make this tool a reality.  Epicomm had already built a bunch of stuff for my company over the years, and there was a high level of trust there.  Because of my grandiose ideas, I had them use SQL Server as the datastore instead of Adesso, the tool my firm had acquired in 2008.  And I had them build fields in a way that would make it easier for localization into other languages.  Like I said, I had these grandiose ideas…yea…I know better now 🙂

Over time, the idea morphed a bit, with screens and workflow changing here and there.  We even had the idea of using custody seal stickers, so that sample shipment receiving technicians at the lab could identify what was in the cooler before even cracking the cooler open.  And a way for field techs to reach out to labs they hadn’t used before but were on the “ezCoC network”.  Thinking about it today, all of that elaborate, wishful thinking for a comprehensive end-to-end tool that both labs and consulting firms would somehow embrace really sounds kinda silly now.  But hey…we had these grandiose ideas of what tech could do to improve the domain we were passionate about, just like we saw it do in all sorts of other industries.


On the sample shipment side (i.e., the lab), we had an entire lab receipt section in the system, where a lab tech could enter sample receipt information like whether or not the temperature in the cooler was within acceptable limits, whether there was some sample breakage, etc.

And we even had a mobile app in both the iOS and Google Play stores. This was in 2012-2013.

Eating our own dogfood

The system had its usual set of technical problems and bugs.  But when you are out in the field, as I mentioned at the beginning of this story, you don’t have time for problems and bugs.  Things have to work.  Because when they don’t, you have to figure out alternates.

So to fully test it well, we used it in-house on a Camp Lejeune project.  This was a drinking water supply well sampling project that consisted of sampling 46 or so drinking water supply wells that served the military base.  While considerably simpler than sampling monitoring wells, the lab analyses suite was huge, so much so that a sample from a single well would fill an entire cooler with sample containers.  VOCs, SVOCs, pesticides/herbicides, hexavalent chromium, sulfate/sulfide, munitions, chloride, chlorate, priority pollutant metals, PFAS…you name it, we analyzed for it.



Adoption Problems

We ran into a lot of problems trying to get adoption of ezCoC.  What seemed like a simple thing…replacing those horrid 3-part chain of custody forms with an electronic version…turned out to be a massive uphill battle.  And it seems many field crews didn’t hate CoCs as much as I did.

Technical problems and bugs

Early releases did not work well enough, especially in offline mode.  Initially we ran into issues too often to make using it on critical projects not a viable thing.  Like I mentioned previously, in the field there’s no time to test things, learn things, or McGyver things.  And we were introducing a somewhat buggy tool to replace a tried-and true alternative: paper.  In Camp Lejeune, for example, there is no cell signal in many areas of the giant base.  So whatever you use has to work in offline mode without a hitch.  Otherwise you potentially lose data.  And if you lose data, chances are good that you will have to come back and re-do the work you already did, a very costly endeavor.

Low field user adoption

Field users didn’t want to learn anything new if it meant more work for them.  They also didn’t want to use their personal phones on company projects.  Remember that this was 2012-2013 timeframe.  Now, if it meant less work, they’d be receptive, but the ezCoC system we designed was too elaborate.  It wasn’t as “ez” as the name implied.  Too many steps…too much info to enter, and like I mentioned, it had some technical problems in the early releases.  Also, most field techs were under the impression that a paper CoC copy just HAD to accompany the coolers, so printing paper in the field was something to tackle as well, eliminating half the reason to use this tool in the first place.

Low lab receptiveness

Labs simply weren’t that interested in introducing a change to their cooler/sample receipt processes, even if that introduction would potentially solve some pain points for their customers.  It was too disruptive to accomodate a few folks using a system while also following their usual workflow for everyone else.  They also expected a paper CoC to be in each cooler, despite having that information presented to them on a computer screen by simply looking at the ID on the custody seal on the outside of a cooler.  Each lab also had their own way of doing things, and there was an air of “not invented here” attitude preventing most software from entering their space.

In the end, the lack of lab adoption was probably the key insurmountable problem for ezCoC.

Lessons learned

Market not ready for change

In the early 2010’s, the environmental consulting market at the time wasn’t ready for this technology, despite the proliferation of mobile phones and “there’s an app for that” TV campaigns. Field techs were happy enough filling out paper CoCs and considered the filling out of them as not a big problem, unlike me who despised those forms.  Labs especially were not ready for change.  Ironically, they are now—in 2024— introducing their own versions of electronic CoCs.

Grandiose and elaborate systems have a high likelihood of failure

This was painful to learn. I spent months and months designing what I considered a really cool end-to-end system that could connect the field tech to the lab and back to the project manager in the consulting firm.  The system would solve several pain points, including notification to the lab that a shipment was on its way, short turnaround time notifications ahead of cooler receipt, notification back to the user that the cooler was received, ability to view the contents of a cooler without even having to crack the cooler open, and even ability to reduce double-entry of the info on the lab side via integrations into their LIMS.

However, as I have painfully learned, building a giant elaborate system is subject to a ton of issues….too much complexity, biting off more than you can chew, assumptions that don’t pan out, and pushback from the very stakeholders you thought you could help solve a problem for.

It’s best to build small, simple systems and get those in the hands of users right away, so that you can test your assumptions without having to spend gobs and gobs of money and time.

Stay away from 2-sided marketplace ideas

Uber, Airbnb, and others have done it.  But it’s really hard to pull off.  If you like pain, go ahead and try to build a 2-sided marketplace. However, a word of caution: its a really really difficult and costly journey to success.  Read “The Cold Start Problem” by Andrew Chen before undertaking an idea that has more than one side of stakeholders.

Partner with an entity with influence

In late 2013, we were fortunate enough to have partnered with Promium, makers of a popular laboratory information management system (LIMS) in use in over 300 environmental labs. Partnering with Promium provided needed resources, marketing muscle, new ideas, and a back door to enter labs via use of their ElementLIMS software.

One idea that came from this partnership was to change the name of the product from ezCoC to EnviroChain, a welcome change, considering that outside of the environmental industry, CoC was generally pronounced “caulk”.

Despite the name change, for reasons cited earlier, in the end, the renamed “EnviroChain” failed to gain enough traction.  Mostly because this idea was a decade too early for an industry somewhat set in its ways.  After a solid 8 years of trying pretty hard, everyone involved grew tired, and the expenditures in time and money were too vast, ultimately landing at “too much squeeze for the juice”.  By then, the underlying technology used to build ezCoC/EnviroChain also got long in the tooth and bypassed by more modern technologies.  Not to mention a highly complex codebase.

Applying these lessons to XForms

I no longer have illusions of grandeur, of changing an entire market.  That’s like near impossible, even if you have deep domain knowledge of an industry.  I also stay away from designing elaborate and all-encompassing software systems intended to handle every use case or scenario under the sun.

Instead, at XForms we’ve learned these lessons, and focus on simplicity. Small ideas, simple systems, small incremental changes. As the saying goes, less is more. Less complexity and smaller systems.  Fewer stakeholders to convince, and tech so simple you don’t need a user guide to figure it out. Also, compassion and understanding for the field techs, who are already ridiculously busy trying to do their job under strenuous circumstances.  Bottom line: build for the 80%, not 100%, and keep it simple.

What a simplified electronic chain of custody form in XForms looks like

No illusions of grandeur here…just one of many form templates built for Mid-Atlantic Associates, a small environmental consulting firm in Raleigh. They use XForms for their environmental field work. We built two different eCoC form types for their XForms account:

  • CoC Analog: A super simple form, where the field tech takes a picture of a filled-out paper CoC, enters a few basic details like lab name and # of samples…basically a picture of a paper CoC, but with the added benefit of storing it in a database engine and pushing it elsewhere via integrations.
  • CoC Digital: A more comprehensive, fully digital CoC with a nice-looking printed CoC format.

Here’s an example of the output type for MAA’s digital CoC.  Yup…still having to output paper, which is ironic.  But that’s only because labs insist on it. As a matter of fact, when I mentioned to Pace National in Mt Juliet TN that we could automatically email the CoC to them the day before the shipment arrives, they said “no, we don’t want that…and make sure you put a paper CoC inside each cooler”.  This conversation happened in 2021.

Imagine if we would have asked the lab to scan a QR code to view the CoC…their heads would explode.


Improvements to the above can be done in various ways…for example, by using QR codes…drop a piece of paper with a QR code into the cooler and when the lab tech cracks the cooler open, they scan that QR code and voilá! the electronic CoC.  Integrations into lab LIMS systems using RESTful APIs can also help.  But then again, these are environmental labs that we are talking about.  That will be a very hard sell, even in 2024.

So the big lesson here is that these sorts of fundamental changes in processes and workflows take time, mostly because change is hard.  Humans don’t like change.  And just because you think your idea is awesome and would help solve a customer’s pain points, it doesn’t mean that that customer is ready for that change. So keep your illusions of grandeur in check. Stick to bite-size changes.  That’s probably the biggest lesson learned for us.

Want to give XForms a try?

Click/tap the button below.