The Next Chapter

After getting certified to integrate with Metrc, I built a multi-tenant service which allowed me to explore a variety of issues faced by Cannabis companies.

All of the tools and apps were based on real world problems, gleaned from conversations and interactions with people working in Marijuana businesses. Some of these ended up being useful, and others ended up having limited value. Since the entire endeavor provided an endless stream of challenges and puzzles to solve, it was a huge success.

While I have every intent to continue writing software in my spare time, I want to experiment with new architectures and technologies. Migrating the current server and all of it's functionality is a possibility, but would take a lot of effort and time. Since this is my hobby, and something I do for fun rather than profit, I'd prefer bypassing the heavy lifting and getting right to the fun stuff.

So, I've wound down the service. Everything was written so it can run on-premise, or on a company-specific hosted account. There may still be some maintenance work to do, but I'm trying to find alternative solutions for any businesses still needing functionality.

Again, this does not mean an end to writing software to solve Cannabis related problems. It means the freedom to try something new. I've learned I don't want to run my own company. But I do want to continue solving problems and creating solutions. So, I'm not sure what I'll build next, but as long as it's challenging, I'm up for it!

CA evaluation completed

I just completed the CA evaluation for Metrc. While I had hoped the third time would be a charm, and things would go smoothly, it was not to be. I probably spent a total of 4 hours getting through this . . . ouch! I’ll share some of the challenges I ran into, if for no other reason, so that I can learn from it.

To find usable tags, you need to parse several files. However, it’s not obvious what licensee type is represented by each file. This has tripped me up before. The solution here is to use facilities/v1/ to list all license numbers and types.

I initially thought there was nothing populated in the db. After all, last year the sandbox was reset, and there wasn’t enough data to be able to do anything. Without any starting inventory, the API can be really hard to use.

But the problem this time is "API Program Bulletin 17". Since you only get back items which have changed in the past 24 hours by default, initially finding inventory via curl calls makes the system seem empty. I suppose that makes it less likely you’ll stomp on someone else’s data.

Trying to do anything with rooms/v1/ resulted in a “401 Unauthorized” error regardless of which

licensee I tried. I ended up emailing metrc to find “they have been working on some problems” related to rooms. Fortunately, I was given a license number that worked. However, this would bite me later!

I temporarily stumbled over “changegrowthphase” vs “changegrowthphases”. This is not the first time I’ve been bit by this, and it's not a big deal. But still, it was a head scratcher until I realized what was wrong.

The next hurdle was discovering one of the Grower accounts had only 4 plant tags left. Of course, I had used this account to set up strains and items. But without tags, I wasn’t going to get much done. This is where the bulk of my time was spent: first in haphazardly guessing which tags were available, and ultimately in some code to automate finding free tags.

Once I could better analyze tag usage, I switched to another grower license which had many tags available. However, I would soon discover this new licensee was affected by the Rooms issue I ran into earlier. So now I had tags, but no rooms. I tried guessing some room names so I could move product around, but ended up having to ask metrc for a list of room names I could use.

I made a mistake (again) in not reading what should be included in each response. I recorded tags and/or ids as I went, but before I could submit, I had to revisit most of the sections to get other information. For example, some sections require name, date or licensee number. It wasn’t difficult to backfill the data, but would have been more efficient had I captured it right off the bat.

At the end of the evaluation, I had a shiny new tool that lets me check a list of Plant or Package tags and see which are already used. While I’ve built this before (at least for Packages), that was before Bulletin 17, when it was possible to get “allPackages” at once. So I’ve rewritten the tool to work with both types of tags, and to check each individually. This should make life easier during the next evaluation . . . which will likely be for Michigan.

What's the Metrc API good for?

I've been asked repeatedly whether the Metrc API can be used to do various things. It seems reasonable that a "seed to sale" system would provide the ability to track inventory and provide information useful for a number of reporting functions. Unfortunately, I invariably end up being the bearer of bad news.

The Metrc API is a mechanism to report some compliance data to the State. That's it! If you want to use it for anything else, that's your prerogative, but don't be surprised if your project fails. Would you use a screwdriver to drive nails? Cook your Thanksgiving turkey with a bunsen burner? Commute to work on a Big Wheel? You get the idea.

At first glance, you might think the API is poorly designed. Posting data returns a 200, but absolutely nothing else. Fetching data returns only records which have changed in the past 24 hours. The documentation shows a single sample request payload, with no additional information. Terms such as Tag and Label are synonymous, but not interchangeable. Rooms represent an arbitrary area rather than a space which is separated from the rest of the building. And while you can "delete" Items and Strains, you "post" to destroy Plants and Packages.

But if you remember what the API is designed to do, you realize these features are actually benefits. While most API's return at least the identifier of the object created with a "post", this forces your system to hold the response in memory, and then parse it. So, by not returning a payload on success, Metrc is keeping your system light and nimble.

Since you'll need that identifier later, as soon as your "post" completes, you'll need to do a "get" in order to find the new record you've just created. Metrc makes this easier by returning records sorted by "last modified" date, so your record is probably one of the first. Not only does Metrc make it easy to find your new record, by getting the record you can rest assured other threads will now be able to retrieve the record as well. And by limiting the "get" response to only records that have changed in the past 24 hours, your system doesn't have to deal with an abundance of records.

Again, if you decide to use the API for things it was not designed for, you'll end up causing yourself pain. If you want to see all of the Plants or Package a licensee has, you'll need to page through all of the records, again sorted by "last modified" date. Since you only get a 24 hour period for each "get", you'll need to make 30 calls to see anything that's changed in the past month. If the licensee has anything in inventory that hasn't been modified in longer than a month, you'll need to go back farther. If you're trying to get the inventory of a licensee who's been in business for a year, you'll need to make 365 calls, or risk not getting all the relevant data.

The documentation indicates you get records back based on the last modified date. However, there's no information about defaults or what happens if you provide incorrect values. But that's why vendors must be certified! Anyone authorized to use the API must go through training, so the documentation can be more of a "refresher" rather than a "how to" helper. The training also makes things like inconsistent naming, nonintuitive concepts and oddly assembled endpoints a non-issue.

As long as you use the Metrc API for what it's intended to provide, and only what it's intended to provide, you'll be a happy camper. You can think of the Metrc API as a one way door where data goes in. However, once it's in there, don't expect or try to get it back out. You've been warned.

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!!!!

From Problem to Prototype

Growers and retailers in the Cannabis industry have a wide range of software products from which to choose. Wholesalers and processors have much fewer options!

I've had numerous requests for a Quickbooks to Metrc connector. All of these requests have come from wholesalers and/or processors. Many of these same companies expressed an interest in syncing an eCommerce system to Metrc. Some shared concerns and struggles in terms of inventory tracking. Concepts from enterprise resource planning came up in conversations as well. The bottom line is, wholesalers and processors are experiencing pain that software can likely solve. Why shouldn't I be the one to solve it?

The big question is . . . HOW should it be solved? I've explored a wide variety of approaches. Hidden agent processes running on a back room server could continually probe existing systems and ensure the various data sources stay in sync. A POS approach works for retailers, and how cool would it be to build manufacturing control and monitoring systems with Raspberry Pi's?!?!

In the end, I can't see any reason why a good ol' web app isn't the right way to go.³ Obviously it will need to provide a better experience than using the various other systems individually. So, though I'm more of a back end engineer than a user experience artist, I'm working on a front end prototype to demonstrate how a wholesaling and processing solution might work. I'll look for feedback to determine where to go from there.

If you're interested in getting a look at what I'm working on, let me know you'd like to review the prototype. I'd also love to hear any suggestions or ideas you have on what should be included in a software offering for marijuana wholesalers or processors!


1. I guess this is a good learning opportunity?!?
2. There are many other challenges for wholesalers and processors when it comes to ecommerce. Access must be restricted to other licensees (and possibly only to retailers, especially in competitive markets). You can't just leverage the postal service's api to calculate delivery charges. And though banking options are becoming more available, capturing credit card payments can still be problematic. 
3. At least to get started. Even though I'm starting out with a web solution, I'd still love to put together hardware for processing stations. I initially though growing was the only place where Pi's would be useful (http://icodeforfun.com/cannabis), but since processing is essentially manufacturing, there's a lot of potential there too. Give me a Pi, a label printer and a handheld barcode scanner, and I'll show you a packaging station any operator would be happy to oversee.

Solving my own pain first

When I started this adventure, I hoped to find problems faced by Marijuana and Hemp businesses. Any pain point represents an opportunity. However, since getting listed as a verified Metrc API integrator, the primary problem I'm hearing about is the amount of work required to perform all the data input requirements. I didn't find this problem . . . it's finding me! So this is likely something I'm going to spend some time addressing.

During my evaluation, I found myself wishing I had a way to "bootstrap a scenario". For example, repackaging exercises require a starting package. I admit to pillaging packages made by other sandbox users, but remember how cool it would be to have a tool that could create a plant or package at any stage in it's lifecycle. Need a plant ready for harvest? Need multiple plants ready for packaging? Need a package ready to be repackaged? Yes, yes and yes please!

For many of these steps, you'll need to provide tags. While in production, you'll know which tags have not been used (or else you've got really big problems), but in a sandbox or test environment, finding unused tags is kind of like throwing darts in the dark. So step one is to make a tag checker. Nothing pretty, but an easy to use "give me a tag and I'll tell you if it's used" kind of thing.

Next, I'll come up with some common scenarios that might be useful. Creating packages with flower fresh from harvest seems a good start. You'd pass in a plant tag, a package tag and perhaps the amount of product you want. It will create entries starting at planting, through flowering, to harvest and finally into a package. Items, rooms and any other needed data will be picked randomly from existing data. Did I mention this is meant for a sandbox or test environment only?!?

So, this isn't really going to solve any of the problems Cannabis companies are facing. But, it will sure make my life easier. By being able to set up scenarios in a repeatable and reliable way, it will save me time, allow me to concentrate on coming up with solutions for real problems.

The trouble with wholesalers

I've had conversations with several soon-to-be wholesalers lately. They are either still building out their infrastructure, or reworking a previous business to accommodate Cannabis products. All of them plan on being more than simple conduits between growers and processors or retailers, though their visions and approaches all differ.

From a software perspective, it's pretty clear wholesalers are underserved. There are lots of programs for growers and retailers, but few options for wholesalers. Even Metrc's API is missing endpoints for transfer functionality, the main feature needed by these businesses.

Though I've yet to really explore it, I'm sure there is existing software to help manage wholesaling operations. I would even bet there are service providers who can modify the software for Marijuana's unique requirements. However, I would not assume these are user friendly, modern or affordable solutions.

Wholesaling is a natural and necessary service in the Cannabis industry. Once interstate commerce becomes a reality, these companies will become even more vital. I look forward to watching how wholesalers leverage technology within their businesses, and to see whether offerings targeting this niche market start to appear.

Women Grow Rocks!

Wow! Just Wow!

I learned about Women Grow during an initial meeting with a grower. I was assured, despite the name, men were welcome. So, I attended my first networking event, and I'm so glad I did!

The variety of people I met was very interesting. Some were just investigating the industry, trying to find a suitable role. Others had years of experience (despite a "13 year forced sabbatical" in one case). Conversations ranged from small talk to hard core business. The cost of Oregon's new testing requirements and limited growing space discussions reaffirmed and expanded my understanding of some of the challenges faced by producers and processors.

The event included a panel who discussed medical uses of cannabis. Dr. Rachel Knox introduced me to the endocannabinoid system and made me realize how little the medical community as a whole understands how to use marijuana as medicine, and how real and profound a properly prescribed regiment can benefit patients. "Professor P" dispelled the importance of THC and CBD as indicators of a strains profile, opening my eyes to the variety of cannabinoids and terpenes that give each marijuana strain it's unique characteristics. And of course, the panel discussed the importance of keeping pesticides, poisons and big pharma out of Cannabis.

I'm looking forward to the next Women Grow networking event. If you're in the industry, or want to get involved, I highly recommend attending the next event too! I hope to meet you there.

The Big Idea - Cannabis

Last night, I went to an event held by the Oregonian with a panel who discussed the current state of Cannabis in Oregon. It ended up being interesting and informative, with some insights that I hadn't really considered.

Noah Stokes of Cannaguard argued the end of prohibition has lead us not to legalization, but to regulation. And that, Noah argued, is a good thing! Regulation makes product quality, consumer protections and other benefits possible. It also legitimizes the industry, which will eventually help resolve some of the biggest problems facing the industry.

One of the most visible and obvious problems is banking. Forcing marijuana businesses to deal only in cash may be good for Noah's business, but not for the health of the industry. And though there are now a few options, the majority of banks will not work with Cannabis businesses. The panel confirmed many licensees are paying their taxes in cash.

The stigma of pot makes finding space a huge barrier to entry for new licensees. Mortgages are not compatible with weed. The pool of potential landlords is limited to those who own their property free and clear, leaving few opportunities to lease space. Of course, there's always an option to buy . . . but again, the property would need to be bought in full. A couple of questions from the audience made it clear: if you own property outright and are willing to allow your tenants to run a Cannabis business, you'll have a lot of potential renters lining up to talk to you.

Another topic of frustration are the new testing requirements. An audience member explained how his $20 per ounce product is now saddled with an added $14 testing expense, causing him to cease sales. The panel reassured him the entire industry is struggling to absorb the cost of ensuring quality and safety.

Earl Blumenauer, our Oregon congressman and one of the panelists, talked about the "C-change" occurring at the federal level. Recently, a friend and I pondered what changes the end of federal prohibition could bring. While we could forsee several downsides (like Monsanto deciding to get involved), we hadn't considered some of the potential positives. The same friend shared a conversation with a grower concerned Oregon farmers would eventually produce more product than demand could consume. However, the panel suggested the end of federal prohibition will likely make interstate commerce possible. In this scenario, Oregon would be poised to be a major exporter.

While there wasn't any real talk about technological challenges faced by Cannabis businesses, Rob Patridge of OLCC talked about a variety of ways the state is planning to leverage CTS (Cannabis Tracking System) data. The term "seed-to-sale system" came up a number of times.

If there was one message Rob seemed most keen on getting across, it is to visit http://marijuana.oregon.gov for clarification of any of the current, or future, regulations. There was concern by some audience members that several strain names, including some very popular and well known strains, are no longer allowed. While some people might still disagree with the decision, the rational and disallowed strain names are published on the states website.

Though I didn't come away with any major revelations or ideas for "the next big thing", it was a well spent evening. I may not have any additional insight into problems that can be solved by computers, but I definitely have a better understanding of common challenges faced by everyone in the industry.

It's official! I'm authorized to build software that leverages the Oregon Metrc API!!

Got my Production Key today! I am a "validated integrator" for Plants, Harvests, Packages, Sales, Locations, Strains, Items and should be listed in their directory soon! Hmmm. I guess it's time to set another goal . . .

A rocky start with the Oregon Metrc API

Towards the end of August, I received a "Proficiency Evaluation", which is the final step in getting production keys for the Oregon Metrc API. Because this is essentially a test, I'm not going to share any of the questions (or answers). However, this was my first chance to play with the API, so I will share my impressions.

It took me over a month to complete the evaluation. And it wasn't because I didn't invest the time! The initial set of docs I got were . . . well, wrong. A number of the argument names weren't correct (though a few were easily guessable). A few of the endpoints just flat-out didn't exist. Of course, none of these issues are immediately obvious, so each of them wasted a lot of time.

Feeling defeated, I contacted Metrc to explain the problems I was having in completing the test. I can not over emphasize how helpful and responsive Metrc has been (Michelle is my hero and I could not have gotten to this point without her help!). I was pointed to some updated online docs. Much better!!!

However, it still wasn't smooth sailing from there.

To complete the evaluation, I was granted access to a sandbox. I was sent a list of plant and package tags, for a number of different licensees, and the sandbox has some initial data. It eventually occurred to me, not all (or maybe not any) of the data was created by the good folks at Metrc. The sandbox, the credentials, the list of tags . . . everything was shared with everyone else who was trying to complete the evaluation. This makes for some nasty surprises and confusing moments!

The shared tags made it impossible to know which tags had been used and which could be attached to plants or packages. To find usable tags, I ended up looking them up until I got a non-200 response. As time went on, finding unused tags became harder and harder. I'm pretty sure I ended up using the last plant tag for one of the producer accounts.

It would be nice to believe you can create something, like a plantbatch, and walk it through it's lifecycle. But in a shared environment, especially one in which users have no means of communicating with each other, your data can get stomped at any time. I had data change out from under me. Initially I felt a tinge of guilt when I used other peoples objects. But by the end, I was flagrantly harvesting other peoples plants and selling out of other peoples packages.

Overall, the API makes a lot of sense. As long as you understand the Metrc system, figuring out which endpoints to call is pretty intuitive. I like the RESTful approach, and I think this is a pretty good implementation.

There are some rough edges though. There's some inconsistency in some of the endpoints. For example, in one case you "changegrowthphase" and in the other case you "changegrowthphases". You can "destroy" a plantbatch, but individual plants require "destroyplants". And while you tag new plants using a "StartingTag", you find plants with a "Label" (these are the same thing). The part I like least is the difference between shapes of requests and responses. For example, when you create a plantbatch, you give it the "Strain". But getting a plantbatch returns the "StrainId" and "StrainName".

I found there's very limited access to historical data. So, if you change the growth phase on a plantbatch, and later see the strain is different, or it's been harvested (or both in my case), there's really no way (that I could tell) to figure out what happened to the plants. Of course, if you're in an environment with a single licensee, none of this should happen . . . but if you wanted to show the lifecycle of a plant, you're going to have to jump through some hoops.

I was less than thrilled to find successful POST requests always return empty responses. Non-200 responses include pretty good information, but after making a successful call, you just get a 200. This pretty much doubles the number of calls I ended making . . . create something, then go look it up.

Though there were some frustrating moments, all in all this was a pretty fun challenge. By the end of completing the evaluation, I felt pretty comfortable with the API and look forward to actually building some software that leverages Metrc. I'm secretly hoping some details of the API are still a work in progress, but even if it's fully baked, I can envision building a lot of cool integrations.

Current software products specifically for the Cannabis industry

With the rapidly expanding list of players in the Cannabis industry, any attempt to compile an exhaustive list of cannabis software is futile. Even if such a list could be created, it would soon be outdated. 

Still, keeping a catalog of software I encounter may prove interesting. Instead of doing a Web search and relisting the results, I'm only including companies and products I've encountered through conversations or first hand experience. So while this may be of limited value to others, these are the Cannabis related software products that have found me:

Metrc

While it's not the first product I learned about, it seems to hold the most promise as an entry into Marijuana businesses. This is the system the Oregon Liquor Control Commission (OLCC) has selected as Oregon's cannabis tracking system (CTS). It's also what the state of Colorado uses.

Because this is the "official" tracking system in Oregon, I've already started investing in learning to leverage this software. I'm currently a certified third party vendor (TPV) and have begun exploring their API.

MjFreeway

This is the first Marijuana-centric company I encountered. A good friend in Colorado with contacts in the Cannabis industry there, introduced me to this company. At the time, had their product been written in something other that PP, I might have contacted them to see if there were any remote opportunities.

Because MjFreeway is a tracking system, integrating it with other tracking systems seems an obvious opportunity. I have yet to investigate whether it has an API.

Leafly

This same friend that introduced me to MjFreeway also introduced me to Leafly.com. I'm particularly interested in solving business problems, so my interest here would be limited to updating a dispensaries menu from a tracking system or pulling in stats to include in a larger report.

Biotrack

Biotrack was presented to me as the only tracking system used by growers. This is despite having been introduced to MjFreeway prior to this. So, while my source was less knowledgable than he purported to be, Biotrack is clearly widely used. I've heard mixed messages about whether Biotrack already has integrations with Metrc, and have yet to do any of my own research.

Flohub

I was introduced to Flohub recently by a local grower. This seems to be a tracking system targeting both growers and dispensaries. Interestingly, the grower mentioned he has a friend who is working on integrating Flohub and Metrc (despite the Flohub site claiming they have integration built-in).

IndicaOnline

I learned about IndicaOnline from an exasperated hostess at a dispensary. She was trying to enter in new visitors on a particularly busy day. Since I happened to be at the tail end of the rush, I asked her whether her frustration was directed towards the workload or at the software. She indicated it was more at the workload, but wished there was a way to simply scan id cards, instead of having to type the information. I was then able to ask her a bit more about the software, which was IndicaOnline.

I'm in! Sort of . . .

I finally have credentials to get into the Metrc sandbox! Unfortunately, I don't have any documentation other than the this work in progress: http://media.wix.com/ugd/73c73e_e930c713c46f4c08b07e7c2e2d29a2b5.pdf

I've been able to retrieve rooms, plants, items, etc., but that's it. While I can report waste, without any other documentation, I'm left to guess at the endpoints and payload required for other calls.

I'm waiting to see if I can get my hands on better docs. Until then, I can't do much more.

First Test Passed . . . Literally!

In order to gain access to the Metrc API, there are a series of steps one must get through. One of those is to "Attend a Metrc training class and complete the test". Check that step off the list! I am a certified "Third Party Vendor". The next step is to get access to the Metrc API sandbox and start experimenting.

Since I'm not looking to leave my current full time job, I'm doubtful existing software companies hold appropriate opportunities for me. However, I found it very interesting to find the OLCC approved four companies to provide retail sales tracking. I might investigate whether these systems have APIs worth exploring as well.