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 anyone1, 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.
1 though I have accepted a couple of small donations to get a server up and running
Sunday, July 30, 2017
Saturday, April 29, 2017
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!
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:
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.
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!
Wednesday, April 12, 2017
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!
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!
Tuesday, April 4, 2017
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.
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.
Sunday, January 29, 2017
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 building1, 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 that2, 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!
1 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.
2 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!!!!
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 building1, 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 that2, 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!
1 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.
2 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!!!!
Saturday, December 3, 2016
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.3 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.
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.3 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.
Saturday, November 19, 2016
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.
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.
Subscribe to:
Posts (Atom)