Teri LeBlanc, Chief Technology Officer and Co-Founder of Drop – Interview Series

Even though Colorado’s adult-use market has been operational for well over a decade, the state’s cannabis industry and its customers still struggle with reliable delivery providers that fully comply with strict state regulations. Given these extensive requirements, delivery services often struggle to ensure every step of the transaction is completed accordingly. Furthermore, with each state—and often individual counties—enforcing different laws surrounding cannabis delivery, compliance is no simple feat.

While Colorado created transporter licenses specifically for social equity applicants and entrepreneurs, many of these transport companies still lack steady partnerships or substantial delivery volumes, even in a market as robust as Colorado’s.

For a deeper look at technology that simplifies the delivery process while connecting social equity-owned transport services with a stronger client base, myCannabis.com spoke with Teri LeBlanc, Chief Technology Officer and Co-Founder of Drop.

What were the most interesting or otherwise beneficial courses you took as part of the Computer Science program at University of Louisiana-Lafayette?

My favorite class was Operating Systems, taught by one of my favorite professors, Dr. Ashok Kumar. It was the course that tied together how software is actually built on top of hardware. We started at the level of how the machine interprets electrical current, worked up through binary and instruction sets, and by the end we had hand-customized a complete operating system.

That class changed how I think about software. Once you have seen the entire stack, from current in a wire up to a running program, you stop treating any layer as magic.

I have continued building operating systems throughout my career, from robot operating systems to quantum operating systems, and now the operating system for cannabis delivery.

Furthermore, how did the internship with the university increase your understanding of the very relevant subjects you studied? How did a university setting allow for you to study those subjects in a far more detailed manner?

The university setting gave us the freedom to build whatever robot we wanted, which is not something you get in industry, where the product is usually decided before you arrive. I chose an autonomous underwater robot because I wanted to work deeper with hardware and software and I really wanted to work on space stuff. Underwater was the closest environment to it I was going to get. That parallel is real, and it is why NASA trains astronauts underwater. Neutral buoyancy, pressure, no GPS, and no way to reach your hardware once it is out there.

The research became an IEEE publication. But the part I remember most is the first test. We ran it in my uncle’s pool. Everything was going well, the robot was swimming, and then it stopped. We pulled it out, opened the housing, and the computer inside was on fire. We had badly underestimated how much cooling we needed in an airtight chamber. Nothing about the design was wrong on paper. We had just not accounted for what happens when you seal a computer in a box with nowhere for the heat to go and then submerge it. So we went back to the drawing board and engineered the cooling properly.

When you build software for hardware, you do not really know whether your software works until you run it on the hardware. Pure software projects do not have that complexity, and I liked the extra challenge. Ultimately that project directed my career. I fell in love with robotics, and my first job out of university was as a robotics engineer. I still have not made it to space though. Perhaps space after cannabis.

What types of products did you oversee as Software Development Manager for Amazon? What were the most fascinating things you saw in the Robotics department?

My first role at Amazon was leading the engineering team responsible for the software infrastructure that gets Alexa connected devices online. That covered direct communication between devices in the home as well as communication out to the Amazon cloud for online services. This is where I learned about scale. About what is actually required to scale technology around the world.

My second role was leading a team of roboticists building fully autonomous warehouse robots. That one was fascinating because it had much more of a research and development character to it. We had an office building full of obstacle courses, and we ran the robots through them every night for testing. We also tested in real warehouses, with real customer packages. 

The most interesting part of putting self-driving robots into a space where people are also moving is the research behind how humans move around robots. We had scientists on staff who helped us work out what the human-robot interaction interface and behaviors should look like. Underneath it, that work was really about human behavior around technology. It has been directly useful ever since in building applications that people actually want to use.

What caught your professional attention about designing a platform catered to retail cannabis sales and dispensaries? Were there any concerns or worries you first held about designing a platform for the cannabis industry?

My friend and now Drop co-founder, Kat Savoy, approached me with the idea. We are both avid cannabis connoisseurs as well as convenience aficionados. She brought me her research on what the industry needed to solve delivery, and by the time she finished describing the problem I could already see the system architecture in my head. I knew I could build a platform that serves every user across the lifecycle of a cannabis delivery.

My concerns were never about cannabis. They were about the constraints. You cannot use the normal payment rails. Every step of a delivery has to be provable to a regulator. And a platform like ours cannot hold a license, which means the whole product has to work through partners rather than around them. Those were the real design problems, and honestly they are what made it interesting. 

Cannabis has mattered to me personally for a long time and I am grateful that I can continue building technology in industries that I am passionate about.

How did you rely on your vast software engineering experience with Amazon and IonQ when designing the interface that became Drop? What were some effective software designs and strategies from those companies that inspired Drop?

My entire career has been spent on complex systems where separate components talk to each other through well-defined interfaces. I designed Drop’s architecture very similarly to how I built the quantum operating system for IonQ’s quantum computers. Completely different domain, same underlying problem. One control layer holds the true state of a complicated system, and everything else works through it rather than around it.

In practice that means a single API that every application in the platform runs against. The consumer has their own application, the driver has one, the dispensary has one, but all of them communicate with one brain. The orchestrator is the only thing that understands the entire state of the system, and that is what lets it direct every user across every application. Each user only sees their own slice. It keeps the whole thing clean and traceable for everyone involved.

At Amazon Robotics the pattern was the same. We ran fleets of autonomous units from a central system that held the full picture while each robot only knew its own task. Drop’s dispatch works that way with drivers in place of robots. The orchestrator knows every order, every driver, and every dispensary. The driver just sees their next stop.

Why do you feel like Colorado is a great state market to debut the Drop platform with? What issues in the Colorado industry is the Drop platform designed to provide assistance to?

Colorado is one of the pioneering cannabis states and it continues to push the industry forward. It also has a mature regulatory framework, which matters more than people assume. When the rules are clear and settled, you can build a compliance system against them. That is much harder in a market where the rules are still moving underneath you.

Colorado has real demand for delivery, but the infrastructure for it never got built. Delivery here runs through licensed transporters rather than the dispensaries themselves, and in Denver stores are required to use a contracted transporter rather than self-delivering. So a dispensary that wants to offer delivery has to find a transporter, coordinate with them, and maintain a compliance trail that spans two separately licensed businesses. Most of that is still being done on paper.

On top of that, delivery is authorized municipality by municipality, and most of Colorado still prohibits it. The serviceable map is not a state, it is a patchwork, and it shifts as cities opt in.

That gap is what Drop was built for. We connect the dispensary and the licensed transporter, carry the compliance trail between them, and handle the parts neither one wants to own. Dispatch, identity verification, state paperwork, and payment. The demand was already here. The infrastructure was not.

How will Drop provide extra business opportunities and brand awareness for social equity-owned transport companies and cannabis brands alike? How will the platform solve those widespread issues that social equity-owned companies face?

Colorado reserved delivery for social equity licensees. The transporter delivery permits went to social equity operators first, the state waives the licensing fee for those applicants, and Denver has moved to make that exclusivity permanent. The licensed delivery transporters in Denver are social equity businesses. They are not a group we serve on the side. They are the transporter side of our platform, and every order that moves through Drop is revenue for one of them. Our growth and theirs are the same number.

The harder problem is what happens after someone wins a license. The license is the part the state helps with. It does not come with dispatch software, a compliance system, relationships with dispensaries, or customers. A newly licensed transporter with two vehicles is competing against the operational infrastructure of much larger companies, and building that infrastructure is the expensive part. Most of them cannot afford to, and I would argue none of them should have to.

That is what the platform hands them on day one, with no capital outlay. It also hands them demand, which is the harder half. A transporter on Drop is connected to every dispensary on the platform instead of having to go win each relationship on their own.

For brands, the marketplace is a new shelf. A product that previously had to be found by someone physically walking into a particular store is now visible to anyone browsing that store’s menu from home. Smaller and newer brands gain more from that than established ones do, because discovery is the thing they lack.

From a software engineering standpoint, how is the app designed to take into account current rules and any changes that may be made to Colorado transportation regulations?

We added a rules engine for regulations, because in this industry there is no single set of rules that applies everywhere. They vary by jurisdiction, and they change.

The engine resolves them in a chain. A delivery address resolves to a ZIP code, the ZIP resolves to the municipality that governs it, and the rules for that order come from that municipality rather than from one statewide assumption baked into the code. Whether delivery is permitted there at all, what the local delivery window is, and whether stores can deliver themselves or have to use a licensed transporter. Two customers a few blocks apart can fall under different rules, and the engine is what makes that a lookup instead of a special case.

Those rules live in the database rather than in code, along with the record of when each municipality opted in and who entered the change. A city voting to allow delivery is a data update, not a software release.

Around the engine, compliance is its own layer rather than logic scattered through the ordering flow. Purchase limits, address eligibility, identity verification, and track-and-trace each live as separate components. Every regulation we enforce carries an identifier in an internal register, and the code enforcing it cites that identifier directly, so when a rule changes, finding every affected line is a search rather than an excavation.

How will the transportation and retail regulations in other state markets be included in the design of Drop when expanding into other state markets?

The platform was designed for this from the start. Every legal delivery market has the same skeleton. A state system of record. A manifest that exists before the product moves. Age proven at the door. Undelivered product reconciled back. Driver credentials valid at the moment of dispatch. That skeleton does not change when we cross a state line.

What changes is the detail. Purchase caps, delivery hours, who is licensed to carry, whether a municipality has to opt in first. Those are the pieces we built to be configurable rather than hardcoded. Adding a state means teaching the engine that state’s rules. The product underneath stays the same.

Track-and-trace is the integration that varies most between states, so it sits behind its own boundary. The majority of states use METRC, and we are a vendor integrated partner with it, so the compliance backend carries forward directly. A state on a different system becomes a new adapter behind the same interface rather than a new platform.

The retail side generalizes the same way. Dispensaries connect through their point of sale system, and the major cannabis POS platforms operate across many states, so an integration built in Colorado is largely the same integration in the next market.

As someone very experienced in software design and engineering, how do you envision this technology evolving and adapting as the cannabis industry itself evolves?

Some of what makes this product hard today will simply go away. If cannabis is rescheduled or legalized federally, the banking constraints loosen and payment stops being a custom build. Interstate commerce becomes possible, which changes what a delivery even is. A lot of the machinery we built specifically to work around federal prohibition becomes unnecessary. I would be glad to delete it.

What will not go away is exactly what we built the platform around. Age verification at the door does not disappear with legalization. Alcohol has been legal for ninety years and you still get carded. The chain of custody does not disappear. Proving to a regulator what happened, when, and to whom does not disappear. Those requirements outlive prohibition.

The things that are stable across every version of this industry belong in the core of the system. The things that are volatile, and in cannabis that is most of the rulebook, belong in configuration where they can change without touching the product. Regulatory change now becomes maintenance instead of a rewrite. 

So my expectation is that the compliance surface gets simpler in some places and more demanding in others, and the platform’s job stays the same. Hold the true state of the system, prove every step, and keep the operators using it from having to think about any of it.

Longer term, the real product is infrastructure rather than an app. What we have actually built is the ability to move a regulated product from a licensed seller to a verified buyer, prove the entire chain, and settle the money. 

Thank you for joining us, Teri! For more information on Drop, please visit its website.