Nevada certification obtained; Open Source library released

Over the past few months, I've had very little time to do any programming that wasn't directly related to my day job. However, with the upcoming holidays, and the Q4 priorities at work coming to completion, I've finally been able to have some fun.

Up until now, I've had no reason to get certified to use the Metrc API anywhere outside of Oregon. 

However, I have some friends in Michigan who are going through the licensing process and want to leverage the API, so I plan on helping them get through certification (whenever training and evaluations are available). Partially to refresh my memory on what's involved in getting certified, partially because one of the local processors I work with has expanded, and partially because I couldn't think of a reason NOT to, I decided to go through testing for Nevada. At the same time, I started the process for California too.

Fortunately, Nevada doesn't require going through training for vendors who have already completed it in other states. California does require it (at least right now). Michigan is still concentrating on getting licensees up and running, so it's unclear on what will be required for third party integrators. I'm sure they'll all require passing the evaluation test, regardless of certification status in other states.

The Nevada evaluation was done in the Colorado sandbox. I ran into some issues with sales endpoints which may have been differences between Nevada and Colorado feature sets, but after contacting Metrc, I was provided with a workaround which let me complete that section. So, now I'm certified in Oregon and Nevada. Besides California and Michigan, I don't really have plans to get certified in other states, but I may change those plans in time.

As I wait for additional testing to be available, I've decided to revisit some of the code I've written for the Cannabis industry and share it. One of the biggest surprises developers discover when first working with the Metrc API is the responses for POST calls. When you create something, you might expect the API to return the newly created object. Or at least the id of the object. But sadly, that's not what you get. A response code of 200 and an "OK" signals success, but doesn't really help you produce a meaningful user experience. So, after posting, you end up having to GET the active objects and fishing for what you just created.

Every vendor has had to reinvent this POST/GET dance, and while they may want to keep theirs tightly guarded, I've decided to share mine. I believe it's the first open source library for the Metrc API. Covering mostly Processor related functionality, I'll build out other parts as time allows. Since it's open source, it's absolutely free for anyone to use, copy, change, sell . . . whatever. Of course, without Metrc API production and user keys it's useless, but licensees and third party integrators can use the project to jump start their own creations.

Being different is making Washington State look bad

Colorado and Washington were first, and each took their own unique paths when developing regulations. When Oregon legalized recreational Marijuana, the program was more like CO than WA. WA just seemed to do things "differently".

When Washington decided to change their CTS (Cannabis Tracking System) from BioTrackTHC, again they decided to ignore what other states were doing. They did not like the idea of requiring specific RFID tags or labels. While I understand not wanting to dictate how licensees run their businesses, I don't understand how you expect to have true traceability if you don't enforce how product is tracked. The first rule of data is: garbage in, garbage out. Instead of telling licensees how to track Cannabis, you leave them to their own devises, which is bound to result in inconsistencies and inaccurate reporting.

The demand to leave tagging an open ended affair forced Franwell to pull their proposal (even though Metrc was originally selected as the CTS replacement). So instead of Metrc, Washington State ended up going with MJFreeway. MJFreeway was the first seed-to-sale tracking system I learned about, but since that time, issues have plagued the company. To top it off, the BioTrackTHC contract has expired, but MJFreeway isn't ready. So now there is no traceability system in Washington State for the time being. I guess inconsistencies and inaccurate data are no big deal . . . especially when you're running with NO data.

Love it or hate it, Metrc is the standard for state traceability systems at the moment. Colorado, Oregon, Alaska, Maryland, Nevada, Michigan . . . and now California . . . the grand price of legalized recreational Marijuana! Sure there's some downside: a user interface that feels like it was built a decade ago, an API with many missing capabilities, RFID tag requirements, and on and on. But the system is relatively stable, and they have experience to not only provide a platform, but to help states build compliance programs with a baseline, workable system.

I feel sorry for all the Washington State licensees who are struggling right now. The state did you no favors by avoiding the need to tag your Marijuana!

Why won't I commit to working in the Cannabis industry?

As I've said, I'm not willing to give up my day job to pursue working in the Cannabis industry full time. During the day, I'm leading the effort to build our "number one priority". Despite a recent wave of coworker departures, crazy aggressive deadlines, ever shifting scope, and conflicting directives, it's an almost impossible goal I feel compelled to win. While it's extremely fulfilling work, it leaves me little time to write code for the Cannabis industry.

Recently, I spent some of that free time to participate in the Metrc API Advisory Group. The group will meet regularly with a goal of making recommendations regarding training, verification and support of API users. A separate group recommends improvements to the overall Metrc system, however the API users were not shy about sharing their desire for API changes. It was reassuring to hear how many others would like the ability to post transfer data, get response data instead of just a 200, access package history, and similar issues I've long said were missing from the API. It was also interesting to meet people who have taken the leap into full time Cannabis software work.

There's a bit of an internal struggle happening in my head. If others are able to write software full time for Marijuana related businesses, why can't I? Is it fear? Is it laziness?

I don't think so. It's that I want to write code. Sure, for my day job I still have to write documentation, design new features, architect systems, train/mentor junior developers, and more, but all of that is centered about building working software. I don't have to worry whether I'm building the right thing, only that I'm building it in the right way. The decisions of what to build, how to market, who to sell it to, and so on, is someone else's problem. They just pay me to deliver "the thing". That's freaking awesome!

Though I've really enjoyed working with Cannabis companies so far, I've come to realize I'm doing a lot more than just building software. I've had no trouble finding people who want solutions, so I haven't had to do any marketing or advertising. And since I don't charge anyone¹, there's no accounting to do. So it would seems all that's left to do is build software.

But that's not the case. Very few businesses I've had contact with have a clear cut idea of what they want built. Those that do generally describe systems which may seem modest, but in reality are massive in scope and complexity. While these are the systems I want to build, the people who can envision these solutions have businesses to run, and can not "drive the bus". That means I'm left to figure out the actual problem they're trying to solve, and discover ways to alleviate the pain in the quickest, lowest effort approach possible. That's a lot of work to do in order to find software to build; especially because there can be non-software solutions which are better suited to solving the problem.

Does this mean I'm going to stop looking for software to write for the Cannabis industry? Heck no! I'm currently building a workflow solution that tracks and analyzes processing activities, both as an inventory control system, and a system to identify opportunities in increase efficiency and decrease waste. Now, instead of trying to design a marketable product, I'm going to build it because it's a fun project that could actually help people run their pot businesses. No promises and no pressure. And no more trying to figure out how I can turn this into something to replace work that I love.

Who knows. Maybe some day I'll run into a Marijuana entrepreneur who has been dreaming of building an ERP or Automation system for Cannabis Processors. Maybe one of the brave souls who have already taken the leap into the industry full time will one day have a position available that suits me. But until then, I'm going to stick with doing full time software development, and spending my free time building software because I like to build software, not because I want to build a business.


¹ though I have accepted a couple of small donations to get a server up and running

Some of the tools I've written to interact with Metrc

As is usually the case, I haven't had nearly as much time as I'd like to write software for the Cannabis industry. Challenges at work have been meaty and sticky enough to require some real thought, which is both a blessing and a curse. It's great to get paid to solve programming puzzles for a living, but that doesn't always leave a lot of gas left over for the really fun stuff.

It's been just over half a year since I got certified to use the Metrc API. In that time, I've found time to write some interesting tools. And since I'm treating my work for Marijuana businesses as a hobby rather than a side hustle, I figured I'd share some information on what I've created up to this point.

While I have a lot of bits and pieces, there are two tools that are complete enough to have some production value. Both of these communicate with Metrc in real time and use Metrc as the only storage mechanism (look Ma, no database!). They're both essentially "pretty wrappers" for data entry tasks that are tedious to do in the Metrc UI. They also serve as examples of how custom forms can be created to expedite and reduce errors while entering compliance data.

The first tool is a Strain and Item Manager. As you might expect, this tool provides the ability to add, update and delete Strains and Items. But it also provides information on relationships between Strains and Items. And it shows inventory of each individual Item.

Upon opening, the licensees Strains are provided in a scrolling selector (which is a little Jquery plugin I put on my github page: https://github.com/toddrun/JqueryScrollSelector). Scrolling to a Strain opens another scroller with all the children Items. Scrolling to an Item opens a table of all the Packages for that Item, including conversions of the total weight into a variety of units of measurement.

The second tool is a Package Manager. The intent is to allow splitting, combining or just repackaging any existing Package. This was originally three separate tools, but I eventually decided to make a single interface for all three activities.

No matter what you want to do with the tool, you'll start with one or more existing Packages. You'll also need one or more unused Packages (which at this point, will just be unused Metrc RFID tag/labels). Upon opening, you're presented with a way to move part or all of one Package into another:

While you'll have to enter the "New Package" Metrc Tag value, the rest of lets you pick from your live Metrc data:

This makes it easy to take part of a Package and put it into another Package. But, what if you want to take three Packages, extract concentrate, and label the new Package of concentrate? Or, what if you want to split the Package into several smaller Packages, like converting the concentrate into batches of brownies? There are handy "+ Add" and "- Minus" buttons for this purpose.

Note the buttons won't let you have multiple Existing Packages AND multiple New Packages at the same time. This is intentional, and is designed to reduce errors. Likewise, until you have the minimum information required, there is no way to submit the form. Of course, once you can submit the form, the data goes directly to Metrc. Compliance done!

Again, these are just a couple of the tools I've put together since getting certified. I make them available for free to any licensee who wants to use them. And this is just the start. I look forward to building much more in the future. But for now . . . back to my real job!

The sad state of Cannabis software offerings

It kills me I don't have the time and resources to create an application that address the needs of the "middle market". Mid-sized wholesales, processors and producers just don't have access to the solutions they need.

To illustrate, here are some excerpts from messages I've received recently:

We need a robust inventory management system and I don't love any of the existing software providers

we switched from (company one) to (company two) with the rec flip, but so far (company two) is leaving a lot to be desired

I have talked to several of the software companies out there in the industry and I find that they are REALLY expensive and often are relying on the customers to test their beta software at a huge cost

The worst part about getting message like this has nothing to do with not being in a position to capitalize on the opportunity. It's knowing these businesses are in pain, and I don't have the ability to help. I'm hoping that some of the tools I've developed will reduce this pain, but there's so much more that needs to be done.

I'm starting to realize the market has 3 distinct types of players. There are companies small enough that spreadsheets and text files can provide all the tracking needed. There are the big players who can afford $50K - $100K per year ERP systems. But the companies in the middle are the ones who are most in need of help. These are companies that produce enough product each month that spreadsheets alone don't cut the mustard, but thousands of dollars per month cut too deep into their profit margins to be sustainable.

I still can't quit my day job. But clearly, spending my spare time trying to produce tools for a vastly underserved clientele will eventually result in a win-win situation!

Sometimes, starting over is the best thing to do.

I love that warm fuzzy feeling you get when you've been working on a feature and the code feels smooth and natural. With fewer lines than you expected, without being overly terse, and without resorting to complexity, you just know the code is "right".

But sometimes you struggle. Ideas in your mind don't translating into clean structures. And the more you forge ahead, the less you like what you're producing.

It's never fun to throw out work, especially when it represents weeks worth of effort. However, sometimes you can't refactor your way to quality. At times like this, starting over is the way to go.

Customer Driven Development for Cannabis Companies

When I decided to dedicate my spare time to building things for the cannabis industry, I had no idea what to build. I wanted to make something businesses would want to use. I had plenty of ideas, but no clue which of those ideas, if any, had any merit.

Now, I have a better idea of something that's wanted. I'm still far from knowing all the details of what it is I'm building¹, but it's becoming clearer. I've been asked to provide several custom solutions, but I'd rather not treat each as a separate side project. I'm sure I could make a good chunk of change doing that², but I'd rather build something . . . well . . . bigger. I'm shooting for a simple to use, robust and fast application that's able to address specific scenarios in a flexible way. How hard can that be ;)

The only way to do this is with customer input. So far, I've been able to provide demos, but that's it. Soon, I should be able to get a few early adopters up and running. It's bound to still be extremely rough, a bit buggy, and not so pretty. But people using it means even more feedback!!! I can't wait!


¹ Since software evolves, details are often elusive, but this is especially true at the beginning. Many software projects have failed from people thinking they understood all the details, and later discovering their assumptions were wrong.
² Lest my employer sees this: I'm not changing for any work I've done so far. However, I do owe a debt of gratitude for donations that will cover initial hosting costs! THANK YOU!!!!