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.
Saturday, December 3, 2016
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.
Friday, November 11, 2016
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.
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.
Saturday, November 5, 2016
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.
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.
Tuesday, October 25, 2016
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.
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.
Friday, October 7, 2016
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 . . .
Thursday, September 29, 2016
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.
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.
Friday, August 5, 2016
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.
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.
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.
Thursday, July 21, 2016
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.
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.
Monday, June 20, 2016
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.
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.
Saturday, June 11, 2016
Converting failure into motivation
There's goes another failed side project!
This one went from really promising to utter disaster over the course of a few days. There were so many warning signs and red flags I should have seen. Lack of clear vision (no business or marketing plan), disorganized priorities (going public prior to having any revenue), and complete lack of experience of software products or development were all there . . . and I choose to ignore or rationalize them away. While it sucks to spend hours and hours working on software that will never see an audience, in hindsight, I'm glad it fell apart before money got involved.Even though we parted bitterly, I hope "the company" goes on to become profitable. Therefore, all I'll say about the application is it targeted the cannabis industry. It was pretty data heavy and had some interesting challenges to solve. Fortunately, I've learned a lesson from previous side projects that applied here:
Projects that are fun to program will never end up being a total waste of time
Since I don't want to be prejudged as "a stoner", I've been reluctant to open up about my desire to work in the cannabis industry. I feared being associated with pot might cost me an employment opportunity in the future. But this project made me realize:
I don't want to work for a company who views marijuana negatively
I don't expect my employer to allow lighting up at work (despite having refrigerators full of beer). But if being associated with a marijuana related business is a reason not to hire me, then it's probably best I don't work there. In fact, a job where I can get fired because a pee test says I've consumed THC in the past month is a job I don't want. Consider what would happen if employers fired every employee who had consumed alcohol in the past month . . . that would make for a pretty empty office!
So instead of hiding the fact I'd like to be involved in this newly formed industry, I'm going to dive in (at least with my spare time). My first goal is to gain access to the Metrc API. I'm not sure exactly what I'll do after that, but I'll cross that bridge later. My employment status won't change, nor will any of my activities affect my day to day work. But I'm hopeful ability to write custom solutions that leverage the API will provide entry and exposure to cannabis businesses.
One reason the project failed was "the company" had a complete lack of understanding or experience in software. They thought knowledge of the cannabis industry was enough to develop a successful software product. And while I tried to provide guidance, an inability/unwillingness to accept principals like agile and iterative development made creating an MVP like chasing butterflies. I like working with people who have nothing but a good idea, but now I've learned:
You must know how the software will be profitable before you start coding
Notice I said "be profitable" instead of "make money" or "generate income". Maybe your goal isn't to make money. If the goal is to reduce the time spent repackaging production batches in Metrc, figure out how much time you expect will be saved. If you're starting or joining an open source project, determine what you expect to get out of it. If you want the project to feed you, you'd better figure out how it's going to spin off cash before you start planning features for your MVP.
Finally, while it's important to agree what will happen if the project succeeds, it's just as important to decide what will happen if it fails. Waiting until things are crumbling around you is too late! I learned a valuable lesson, and while I wish I had never made the mistake, I'll try to keep it in mind in any future work:
Agree upfront what will happen to the code if it's determined it will not become profitable
When the project melted down, I reacted impulsively. We didn't have any agreements in place, much less one that covered what would happen to the code if a disagreement surfaced. The hardest part of the whole ordeal was being accused of being dishonest and disingenuous. In an attempt to prove I had nothing but good intentions, I zipped up the entire code base and sent it to "the company". I told them to use it for whatever they wanted. I said I didn't expect or want any payment. To be honest, at that point I just wanted to get the fuck away from a toxic situation.
By not getting an agreement what would happen if things went south, I ended up losing a lot of interesting code. I don't care about giving away almost 100 hours of coding for no money, but I kick myself for making it unusable or unsharable. One day I may ask if I can publish it under an open source license (though I'm not sure it's worth it). I may need to settle for being paid in lessons learned, fears overcome, and motivation gained.
Subscribe to:
Posts (Atom)