The Data Stack Show - 27: Building B2B Marketplaces with Mike Luby from LeafLink

Episode Date: March 3, 2021

On this week’s episode of The Data Stack Show, Eric and Kostas are joined by Mike Luby, director of engineering at LeafLink. LeafLink is a cannabis industries B2B wholesale marketplace where thousands of brands can manage and track their orders and relationships.Highlights from this week’s episode include:The infrastructure LeafLink provides for the cannabis supply chain and how it deals with compliance issues. (2:03)Structuring product management organization to launch high-velocity teams (8:08)How it started vs. How it's going (12:00)Containerization and leveraging AWS tools for LeafLink's stack (13:19)Shifting to an event-driven architecture (24:46)Using APIs to provide critical integrations for customers to automate and optimize their businesses (32:47)Keeping an eye for the future but building for today (36:56)The Data Stack Show is a weekly podcast powered by RudderStack. Each week we’ll talk to data engineers, analysts, and data scientists about their experience around building and maintaining data infrastructure, delivering data and data products, and driving better outcomes across their businesses with data.RudderStack helps businesses make the most out of their customer data while ensuring data privacy and security. To learn more about RudderStack visit rudderstack.com.

Welcome to the Data Stack Show, where we talk with data engineers, data teams, data scientists, and the teams and people consuming data products. I'm Eric Dodds. And I'm Kostas Pardalis. Join us each week as we explore the world of data and meet the people shaping it. Welcome back to the Data Stack Show. We have a really cool guest lined up, Mike, who is the Director of Engineering for LeafLink, which provides all sorts of solutions for both brands and retailers in the cannabis industry. And the burning question that I want to ask is they have a lot of different products and it's just really hard to do sort of analytics and I mean really even software development

across a suite of four or five products and they may even have more than that so I just want to hear how is approaching that I mean that's just a building one product for one person is is really hard and so I want to hear how they're doing that. Costas, what's your one question? Yeah, my question that I want to ask from the moment that I saw like their website and their product line is about the usage of APIs in a marketplace. That's a pretty unique thing that you don't often see in marketplaces. And it's clearly technical. And I would love to hear about the business and the technical reasoning behind this choice. So looking forward to chat with Mike. Great. Let's dig in. Welcome to the Data Stack Show. Today, we are really excited to have

Mike, the Director of Engineering for LeafLink on the show. Mike, thank you so much for joining us. Hey, thanks for having me. I appreciate it. And why don't you just give us, you have such an interesting background and I want to dig into that, but could you just give us a brief overview of your background, then what you do at LeafLink and then what LeafLink does and the problems that they solve? Yeah, sure. So like I said, my name is Mike Luby. I'm the director of engineering here at LeafLink. I oversee our marketplace product. I've been building software for the last 16 plus years professionally. I've worked from small startup all the way up to enterprise level companies and both from a SaaS, enterprise SaaS perspective, and quite a few

DTC spaces as well. LeafLink itself is a cannabis industries wholesale marketplace, where we're defining the way that thousands of brands and retailers can manage track their orders and relationships, and they can focus on growing their businesses. It's a B2B marketplace where those producers can, you know, meet their retail customers customers and buy product from each other, and then build those relationships through CRM tools and other tools to help optimize their business. We also have quite a few other areas of the product that kind of ladder up through our marketplace, specifically our payments side, which I don know, we, I don't know if you recently saw in the news, we recently closed a $250 million debt facility round, one of the largest deals

to bring liquidity to this specific market, given all of the compliance challenges that this market has. We use this capital to support the cannabis supply chain as a whole by providing that liquidity directly to licensed businesses. We also have a shipping portion product, which we recently launched in March of 2020 to help streamline the order delivery experience for our customers. We provide a faster, more reliable delivery experience to those customers. And we continue to roll these out to a whole bunch of different markets over the next year. But it allows us to be part of that supply chain, optimize it, and provide better service overall in comparison to some of the delivery aspects that they have today. Additionally, we also have our LeafLink Insights product launched around the same time as our shipping product. This is really our, provides the data insights for our customers to build, measure,

and deploy their brands on LeafLink. We also provide in-depth insights for each of those unique markets in terms of how their products perform, their categories perform, how they interact with the customers, how the market is overall, et cetera. I mean, you provide so much infrastructure. And tell me if this is a dumb question, and I know this is a show focused on sort of data and technology, but I think the way that a lot of our audience thinks is they apply technology to solve business problems. And you touched on some of this, but I just wanted to ask the question directly. I mean, there are other, you know, sort of marketplace type solutions out there, you know, even generic type solutions, you know, that sort of connect wholesalers and retailers. And I'm just interested to know with such incredible growth, you know, what, what are

the specific challenges that LeafLink solved or that brings to the table. So you mentioned that shipping, you know, is one area where the options weren't great there. I know that compliance in the cannabis industry is certainly a consideration, but I just love to know, you know, you're bringing powerful technology to the table to solve a really specific marketplace problem and really sort of infrastructure problem for the industry. And I just love to know what problems created the demand in this specific industry. You know compliance is probably one of the bigger ones out there, is this industry. So for example, the United States obviously is not federally legalized at this point. And each state has their own individual specific rules that differ from

state to state. Whereas Canada, for example, Canada has a little bit better from a consistency across province perspective. So what our tool does, one, it helps with that compliance side, right? So understanding each individual state's needs and requirements for things like the marketplace, for licensing, for deliveries, financing, etc. It gives our customers the ability to really understand who they're working with, making sure that they're working with reputable and compliant retailers or brands, et cetera. And then the other side of it is the fact that this tool is specifically geared towards cannabis.

So there are aspects to this tool and cannabis that are unique in comparison to other kind of wholesale marketplace and tools like it. You know, we focus on things where we have our, for a very tactical example, our testing information based on the strains of each of the, you know, different flower and products available. And then we have that information surface within the product. So they have it at their fingertips. And then we have that information surface within the product. So they have it at their fingertips. And then we also work closely with a compliance tracking software system called Metric. So we have deep integration with that. So we make sure that all of the touch points through the supply chain are compliant and they have all the information needed

to be on the level. Super interesting. Thank you for that background. I think our listeners just appreciate the context. All right. I have a ton of questions, but I've been monopolizing the conversation. So Costas, please get us back on track. No, that's a super interesting conversation to have. So Mike, you went through a quick overview of the product. And actually, it's not just one product from what I understand, like it's a complete suite of products in order to support this market. I mean, how do you manage to have this crazy velocity in product development, which of course, I guess it reflects also the growth that the market has and also the company. Can you give us a little bit of how it looks like inside the company in terms of coming up with the product ideas,

developing the product, delivering and all these things? I mean, there are plenty of companies out there struggling with just one product. How it looks in a company like yours? Yeah, I'm going to start with kind of how we structure the product engineering organization at the company because I think that really starts off and is the kind of entry point to how we really build this high velocity teams, right?

So at LeafLink, we structure our product engineering organization around our business domains. Currently, we structure our product engineering organization around our business domains. Currently, we have five individual domains. We have liquidity, payments, commerce, deliveries, and our platform. Within each domain, we have several cross-functional pods that focus on key goals that drive the customer value. Each cross-functional pod consists of members from engineering, product, design, DevOps, quality, all of that. And the exact breakdown of each pod

in terms of the specific resources is really dependent on their specific needs. But I would say this kind of pod structure is very similar to the kind of Spotify pod field model where we have those cross-functional partners. There are multiple, in addition to that, I think going a step deeper in terms of velocity, there's a multiple things that we do. We are very thoughtful and measured in terms of how we design and think about product, which then leads into also how we also think about an architect software. And then we go through our processes to ensure that that software is built to the highest quality and delivered as quickly as possible with minimal defects.

Really, at its core, I think some of the key aspects that I think are very important that we leverage are, one, is automation. So we have a robust CICD pipeline to get the code from each individual engineer to production as quickly as possible and without sacrificing quality. Next is accountability. And this is really across both the product and engineering. And even at the entire company level, we really hone in and focus on OKRs. We leverage that across the entire, not only product development lifecycle, but also from a career growth and development perspective. We leverage that platform or that framework to really hold ourselves accountable and deliver product. And it ensures that we're thoughtful around what we're doing from a step function perspective. The next is growth. And this really, you know, ties again to the OKR

perspective, but, you know, specifically calling it out is making sure that the teams have the training, the tools, the, you know, being so that they are being challenged to grow both technically and from a career development or professional perspective as well is key because it all kind of ladders up to that ownership and accountability as well. How big is the team right now? We are currently around, the engineering team itself is around 30. I think the company is around over about 130 total. We have offices in New York, LA, San Francisco, Denver, Austin, Toronto.

So we're kind of spread out as of right now. But majority of the engineering department is in New York. And was it like this from the beginning? Because, you know, like many times when we talk with people, we focus too much on how the structure is today and why it's great and how it helps and all that stuff. But I think it's also quite important, like the journey to get to this state

that you are having today. So I don't know how much aware you might be of that, but like that would be amazing to share a little bit with us, especially for a company that grows so fast, which probably means that any kind of also organizational changes have happened fast. So how was the company look like in the past? And how did it progress to reach these very robust and high velocity structure that you just described to us? Yeah, I've only been here for about four months, but I do have some insight in terms of how we kind of started and where we are today.

Like any startup, it started with our co-founders, Ryan and Zach. They built up the team for the last, I think, four or five years the company has been around. It has been a relatively scrappy team. Within the last year, from a management perspective, the engineering team really consisted of the VP of engineering and an engineering manager. The rest was more of a flat organization. Relatively recently, within the last, I want to say four or five months, we started bringing on more engineering management to help us scale, right? Our VP and CTO have done a great job up until this point, but it's time for them to focus on a lot of really strategic, high-level things while we bring in more talented engineering management about the stack that we are using? And also, if you can give us an indication of the infrastructure and the volumes of requests that you have to work with.

In general, give us a bit of more color into what it means to build this product and also to operate it from an engineering perspective. So at a high level, we are in Amazon Web Services. We're a containerized application leveraging Kubernetes. We are primarily today a Python stack leveraging Vue.js on the front end. We leverage Postgres, Redshift, Terraform as well. That at a high level is pretty straightforward. We are continuing to invest in bringing more newer technologies, more newer capabilities within

our technical stack. We are driving towards event-driven and service-oriented architectures as we continue to accelerate over 2021. One thing I specifically do want to call out though is what I find really that I appreciate the most after joining LeafLink is that our CICD pipeline is pretty robust. I know that kind of sounds like a silly thing or table stakes, but based on my experience at larger companies in the past, LeafLink's CICD pipeline is kind of top of the line where we can quickly get that code, the work from an engineer, get it to production pretty automatically, making sure we have the quality in place and whatnot. So they can see their efforts in production

in customers' hands pretty quickly. I think that's pretty rewarding. Yeah, that's great. And I think that every engineer out there is going to appreciate the value of having a robust CI-CD pipeline there. I don't think that anyone can disagree with that. I want to repeat the same question that I did about the organization and how it changed.

But this time around the technology. I know that, as you said, you've been there only for four months. But how do you think that as the company matured and the product matured, the technologies also changed? What was the process? And what technologies, for example, you introduced now and you didn't have in the past? And this was also like the result of having the growth that you have and like any company of this size and who are growing, there are still, you know, one could say technical debt aspects of it. But the very beginning, we were a Django Python application. You know, the standard, you know, you hit a page, it loads a template, it renders data, you click submit on a form, it sends the data back and just kind of refreshes the page. From there, we start to introduce, you know, the single page application kind of technology. So bringing in view into the stack. As we are continuing to

scale up the organization, as we are continuing to, you know, hit the product market fit and deliver functionality that customers truly want. We're introducing the new technology. So we're bringing on more and more managed solutions from Amazon. Really one of kind of the mandates is like, what does Amazon provide from a technology perspective, from a managed solution perspective, that we can integrate into our platform

so we can continue to accelerate our development. So one of those things is DynamoDB. For example, we're pushing towards leveraging Dynamo. We're pushing towards leveraging Amazon's Lambda functionality and serverless. Their event bridge technology for event-driven architectures, et cetera. We have a very robust containerization of our platform.

Like I mentioned, leveraging ECS and Kubernetes and whatnot. Our DevOps team is top-notch. They do some excellent magic on their end. That's great. You said that you are moving more and more into leveraging AWS technologies. This has also the side effect of a much stronger lock-in inside the vendor, right? Do you think that this is like some kind of risk? And also based on your experience, not just like in LeafLink,

but also other large companies that you worked before, this vendor lock-in with the cloud and like all this also movement towards like a multi-cloud environment and all that stuff. How important do you think it is? And how much you think like it should affect the decisions from an engineering perspective over my my experience in and i didn't touch on this earlier but i'll touch on that you know i've worked at salesforce i've worked at nike so pretty large systems overall yeah my personal opinion is that yes i agree that there is in theory, vendor lock in. And that is something, you know, as a business, you should consider and think about. But I think that, you know,

from my experience, the Amazon services that you provide that they provide are pretty robust, and are top quality solutions that, you know, if you are to switch, I would be hard pressed to say, there's another, you know, technology stack out there that more infrastructure stack out there that would, you know, be really apples to apples to them. They're, in my opinion, you know, best of breed, right? Now, I think that you can, as you're going and building your technology, your application logic, your, you know, your business logic and whatnot, you can account for potential vendor lock-in and abstract out some key areas in terms of a case of glass break here kind of situation where you need to move. But I think there has to be a balance there as well because the chances of that happening are probably pretty slim. So why spend the extra effort to do that? You know, from my experience, Amazon provides a lot of great stuff. I know I'm kind of sounding like an Amazon salesperson at this point, but it really does do everything we want. In previous organizations, we worked on Google Cloud and on-prem solutions, but just Amazon has always been the gold standard in that.

Yeah, absolutely. I mean, I know that usually the multi-cloud paradigm, I think it's something that you hear about really large enterprises because they have their own reasons and politics and compliance that they have to consider like this kind of architectures but it's very interesting to hear about this also like from the perspective of an engineer and what that means for the engineer that's the whole thing about products right like if it makes your life easier and you're happy with it why you should change it anyway so and yeah. AWS is probably, I mean, they started this whole thing,

right. With, with the cloud and the infrastructure as a service. So yeah, I think it makes total sense. They have like almost everything that you will need out there. Sometimes it reminds me, I think who said that, like, I had a friend who was giving this metaphor that it's like a supermarket of technology, you know, like there's just everything in there. Probably even like their own employees don't know about all the different products that they have at the end that they can offer through AWS.

I think it was a smart move a long time ago when Bezos was like, you know, develop technologies and products that we can then resell, right? And I think that was the right approach for Amazon. And, you know, I think

after all these years, you could see that, you know, it was the right choice, right? Yeah, absolutely. Costas, if you don't mind, I have a question burning in my mind. Like, I'm interested to know, you know, we've talked about sort of the software development lifecycle and team structure in terms of shipping software across multiple products. And one of the implications sort of downstream from shipping the software is sort of the data and analytics piece from having multiple products. And I know just from working with, you know, some of our customers and just past experience that, you know, it can be really difficult to sort of understand product usage across multiple products. I'd just love to know from your perspective,

how do you think about that from an engineering standpoint? And do you do any work around sort of servicing the teams that are running different products? And then is there an effort or existing sort of infrastructure workflow around sort of understanding the sort of product usage across multiple products? Yeah, I think, you know, that is a critical part of, you know, I think one of LeapLink's successes is leveraging kind of how customers use the product, not only from like a usability perspective, but also, you know, from how they leverage it and use it for their own success, right? That allows us to be, you know, very data-driven and understand, you know, what will potentially work and use that to define new features and new workflows for them to be successful. You know, as you kind of alluded to, there's a challenge across multiple products. There's a challenge in terms of what. You know, as you kind of alluded to, there's a challenge across multiple products. There's a challenge in terms of what, you know, for example, like what is a user in

product A versus a product, you know, product B, right? You know, there's, you know, if you have a unified authentication layer, then great. You know, you can say, okay, let's, let's limit down to, you know, the user IDs, for example, but then you also potentially run into their personas, right? So smaller customers, right? The same person who is doing the logistics side is also the sales rep, who is also the CEO, who's also the guy who is, you know, the marketing team. So like each persona also has like a different usage and really understanding the company size, how they function, what they're doing is critical and having the infrastructure in place

to pipe all that data. And then, you know, I'm very fortunate to work with some people on the data team who are super talented. They go above and beyond when it comes to the data science side of this and really understanding and really thinking about how the customer functions and then surfacing that with our cross-functional partners, right? Our product organization, our sales team, our market team,

so that they can be successful as well. Sure. Yeah, it's just interesting. Just looking at the suite of products, I was thinking, okay, if you have a larger organization, and I'll use your example, the person who's working on the logistics and shipping is different from maybe the person who's using the advertising product, for example, right? And those are two different personas within the organization. And so you're capturing this data. But when you think about even simple metrics, say, like, you know, an activated user or something, the definition of those things, you know, likely change from product to product just because they're doing very different things.

And they're very different sort of, you know, user journeys within the product. That's really interesting and actually really cool to hear that that seems like a competitive advantage for you that you have all that sorted out because that's really, really hard work. Yeah, you know, I think it also kind of plays into defining the appropriate KPIs, right? What is a success metric for each of those personas? And then that helps you hone in on what does success mean for the logistics persona? What does success mean for that marketing persona, et cetera? And so that way we can, you know, tweak and hone in on the appropriate functionality for them. You mentioned at some point, Mike, that you're moving towards implementing event sourcing. Is this correct? Yeah. Event-driven architecture is what we're moving towards in some areas. Yeah. That's very interesting. Can you share with us a little bit more information around this choice? Why you want to move towards that?

So while we have different areas of the product, right? As I mentioned earlier, the LeafLink platform really focuses around the marketplace and then the other products are key pieces of that. One data model that specifically applies to all of those areas, for example, is orders, right? Whether that is a retailer going in and creating an order with a brand and saying, hey, I want these products, these flowers, et cetera. Or it's the other way around where there's a sales rep relationship where they're building this relationship directly with the retailers, et cetera, there's still that order model, right? Then that is applied to financing in terms of capital and making sure that they can leverage our debt facility round to have liquidity in the market, et cetera. And then going to the logistics side, it's an order needs to get shipped, right?

We need to receive the product from the producer. We need to have it in our warehouse. We need to make sure that it gets shipped on time and delivered on time to the retailers, right? All of those things revolve around that order data model. A event architecture or event-driven architecture will allow us to have different triggers and different sources of change within our entire platform.

So it would be a large undertaking if we had all of our engineers touching the order model. It could get pretty hairy because one engineer might tweak it so it's optimized for the marketplace where the other one is going to tweak it for it's optimized for logistics and the other one's finance, et cetera.

Having a domain owner of that order allows a single source of truth, which then allows kind of the ownership there where the other aspects of the platform are the customers to that data model, right? So that event architecture allows, in some cases, a fire and forget type of use case where, hey, you know, we are on the financing side, a user is, a customer is making changes to their net terms, maybe they're getting an extension, maybe they're making a payment. So we're going to send an audit log data. We're going to store data around that

change and we're going to fire it off and forget about it because it doesn't necessarily affect day-to-day work, right? Whereas let's say the logistics side, it's a little bit more important, where we're going to fire that saying, okay, we picked up the product, we packaged it into totes. It's ready for delivery. And we're just waiting for the driver to come by and pick it up. All those notifications get funneled back into that order. We have that up-to-date in real time. So then we can show visibility through the entire platform as well. Oh yeah. That's super interesting. It makes total sense to be honest, especially when you have so many different products that they have to operate.

I mean, I think that adopting such a model gives much more agility in terms of iterating, coming up with new products if you need to. I think it's pretty interesting. So have you already implemented this or are you in the process of doing that? Yeah, we're in the process of rolling this out, right? The challenge is, you know,

service-oriented architecture, event-driven architecture is relatively, not necessarily new, but it's new to a lot of engineers. So part of that is making sure that we train our engineers in how we think

event-driven architecture or service-oriented architecture should function. Setting up those guardrails, right? so that they can have room to explore and learn, but it's still within these high-level guardrails in terms of meeting our strategic vision of what those things mean. So it's a thoughtful process. Like I mentioned earlier, we're very methodical about how we deliver products. So it's a thoughtful process in terms of making sure that they're trained up,

making sure that we have trained up, making sure that we have the appropriate architecture or arc specs. We have the guardrails in place to make sure that it's hitting our strategic vision, etc. Yeah, makes sense. So you mentioned that you're a Python shop, right? So you're also like hosted on AWS. In terms of like technologies, frameworks, and infrastructure, what you have been using to enable this new paradigm inside the company? And can you give us a couple of tips like from

your experience with that transition so far? Part of the move towards more service architecture is these decisions around what framework are we using, what specific technologies we're using, it's starting to become a little bit more minimized, right? You know, as I mentioned before, at the very beginning, we were Django, Python shop, right? Now we have Flash services, we have Django services, we have Lambda functions that don't leverage any framework, right? Because it's a function as a service, right? So those decisions are becoming more minimized. We're going to start to bring on different technology stacks in terms of node, especially like in the finance realm is, is a really popular tool in finance technology that a lot of engineers who have that experience

have experience in node, right? So like, it makes sense for us to bring that technology into our platform. One from a recruitment perspective, right? Because not everybody's a Python developer, but there's a lot of other developers out there. And then also the way we think about it is around like what's the best tool for the job, right? Do we need more kind of a WebSocket real-time functionality so that customers can see real-time statuses of orders.

Yeah, that makes sense. So let's focus on maybe a Node tool that leverages WebSockets. In the Amazon world, they have another implementation that is leveraging API Gateway's relatively new WebSocket tool where you can back it by a Lambda function. So you could write it in Python, right? There's a lot of tools out there that we can leverage that we're moving towards.

Yeah, these are all great advantages of following such an architecture. Do you see any drawbacks to that? Usually in life, everything's a trade-off, right? So I would assume that there is also like a trade-off there. What do you see as the trade-off? Obviously, there are technology trade-offs and there's people trade-offs.

From a technology perspective, you know, it is, do we, or I guess they're all kind of tied to people as well. It's like, do we have engineers who know the new technology, right? Like just because we have one engineer doesn't mean we should actually move towards that specific technology because, you know, the whole bus rule. And if they get hit by a bus, then we are left with nobody who knows, you know fortran

at the company that's not a good decision right yeah yeah so like those are part of the technology decisions so being thoughtful around what new technologies we're introducing the next is is around training you know you can read blog posts about the proper way to do service-oriented architecture right and people could take those blog posts and like yeah we got to do service oriented architecture. Right. And people could take those blog posts and be like, yeah, we got to do it, but they don't fully understand the ramifications of that. So really having engineers really focus in and understand the ramifications of each technology choice and why, why to do it or why not to do it is, is critical.

So making sure that training is there because we can get into a path where we're, we have a whole bunch of half solutions that because of of blog posts, were good ideas at the time. And then we have this disjointed, crumbling platform, right? Makes sense. Makes sense. One last technical question before I let Eric ask his questions. I noticed on the website that you have invested heavily on exposing APIs. To be honest, I find this very interesting for a marketplace.

Most of the marketplaces that I know, they don't invest that much in creating an environment where their customers can integrate with. That's more of a business question that reflects also on the engineering side of things. But why you did that? And what's the value of having something like this? Yeah, I think having APIs is definitely critical to our customers. As I mentioned, our platform,

we have 1,800 plus brands, 5,700 plus retailers, ranging from smaller mom-and-pop shops to large multi-state operators. Our APIs provide critical integrations to help those customers automate and optimize their businesses to be more successful. Right. You know, I think that building a developer ecosystem and evangelizing those APIs, it's critical so that they, you know,

not only are those companies successful, but in return, LeafLink is successful, right? Yeah. You know, as they say, every company is a software company at this point, right? Yeah. And, you know, where they can automate things away, where they can focus on those critical value adds, right? It's kind of like, you know, delegation at an engineering management perspective, you know, where you can automate and save some time. Like you can then use your leadership capital

in other areas, for example. And how do you see the adoption of that, like from smaller customers that you have? Because from what I understood, from what you mentioned, you have like every size of like companies that you interact with as customers. So I would assume like bigger companies,, it's much easier for them to employ

or have even some contractors to work with that. But with smaller companies and shops, for example, do you see adoption also there to the APIs that you expose? And how do you see this working, actually? Yeah, so we have a public API and integration team as well here at LeafLink. So not only are we here to help serve the larger customers through those public APIs, but we also have other organizations, in one case, other organizations that are building integrations of their cannabis-specific technical products that are leveraging APIs against

LeafLink product because their customers are also our customers. So it makes sense from integration of a third kind of third-party vendor perspective. And then we also, on the smaller integration side, those smaller companies we're seeing are leveraging external things like marketing tools or, you know, additional different CRMs that we have integrations with. And we leverage, you know, appropriate workflow CRMs that we have integrations with and we leverage, you know, appropriate workflow tools to push data between and sync data between those third-party vendors

and our platform as well. That sounds great. I find it very interesting, to be honest, like extremely interesting. I have some stories from other marketplaces where they were trying

like to do something similar in the past, like a couple of years ago. And it was a big part of the work to be done to figure out how we can help small ESOPs, for example, to integrate with our platform. But anyway, that's a discussion for another day. Eric, he's all yours.

I just want to just touch on one other point. One of the other benefits is that, again, going back to the compliance side, there are multiple markets that leverage metric. From a compliance perspective, those integrations are critical for the small companies and larger companies to have those integrations

because in a non-integrated world, you have multiple sheets of paper that people have to sign and work through from a logistics perspective. So this is just another great benefit of our integrations and APIs. Well, Mike, we're getting close to time here. So we'll end with a question.

I'm constantly thinking about ways that we can help our listeners, especially when we get to talk to someone like you who has such a diverse background working at some huge companies. So the question I have is, you know, you've worked at Salesforce, you've worked at Nike. LeafLink is, you know, obviously smaller than those companies, growing at a really fast clip.

I'd just love to know, working at really massive organizations like Salesforce and Nike, what are some of the lessons that you've learned about scale that have stuck with you or, you know, that have sort of formed the way that you think about building software, you know, especially at an earlier stage company? Yeah. Some of the, like the first things that kind of pop into mind are around, you know, keeping things simple, right. The whole, you know, KISS architectures, right? Where, you know, trying to build and abstract these things out or pre-optimize has caused more issues in the future

than that were helpful, right? Abstracting away functionality because that's how you do it in Java or, you know, building multiple layers and building a non-scalable layer on top of a, you know, serverless, highly scalable system. Like just, in theory, it may make sense. And, you know, you're setting yourself up for great innovation three years down the line.

But today you're not serving your customers, right? So like, you know, kind of how I think about it and how I, you know, what I've learned over the years is like, yes, have an eye towards the future, right? Understand where you want to go strategically, but really you got to build for today, right? So that eye towards the future will inform what you're building today, but you really still have to deliver value. You have to build the functionality for your customers, prove that, you know, your product works, you have product market fit and all those great things. So you can then in the future, scale it out and build those really, you know, artistic solutions. Sure. Yeah. Artistic is such an interesting way to put it. And I think

if I had to distill that perspective into a word, I would probably choose mature. And it's interesting to hear you. Yeah, I think the word nuance can be overused. But the concept of looking into the future and being informed and the difference between being informed about the future and building for today and building for the future, those sound very similar, but there's a significant difference. And one thing that comes to mind, Costas, that we've heard other guests on the show talk about is this concept almost of a boring stack, you know, where they say, you know, our stack isn't crazy, but that's because it works really well and it's

really reliable for our customers. And that's the most important thing. So really need to hear that perspective reiterated. Yeah, exactly. I, you know, I agree with that fully. It's that, you know, when it comes to engineering talent or, you know, time and experience, like that is the artistic part of, of what we do is, is knowing that nuance between like, like you mentioned building for now with the eye towards the future or building for the future. Right. That's, that's where you can find those really talented engineers who can, who can do that effectively. Sure. Yeah. I was watching a talk from a founder. I can't remember exactly which one, but they talked about this, you know, innovation, looking into the future

and imagining a different world. And he said, that's really cool for building new types of technology, but not great for building a business because, you know, people aren't ready to buy that. Yeah, that's a really good point. Like, you know, there are people who have real problems right now. Well, Mike, it's been a pleasure to have you on the show. We've learned a ton. It sounds like you're doing really incredible things at LeafLink really in all regards, but especially in the software development life cycle. And we'd love to, we'd love to catch up with you down the line when you've had a little bit more time in the saddle there and hear how things are going. Excellent. And thank you for having me on. I, you know, I look forward to seeing if there's any questions, if anybody wants to reach out and, and again,

contact me with me, feel free, looking forward to all that. And thank you for having me on. I appreciate it. Well, that was a great conversation and I'm glad we got our top questions answered. I think one of the things, and I'm glad we got our top questions answered. I think one of the things, and I'm probably going to repeat this a lot because it's a recurring theme, is this concept of keeping it simple and almost having a boring stack. I thought that the way that Mike described having a simple stack and the value of that for your customers today was really well said. And I think just points to how mature he is after having such a vast amount of experience at all sorts of different huge companies. I found extremely interesting, actually, the conversation that we had about my initial question. It is amazing to hear from a company that is building marketplaces,

which traditionally they are supposed to be not very technical in terms of the products that they expose. And having Mike actually saying that even small shops are software companies today, and they need to be if they want to survive. That was a great insight. And I'm really looking forward to see how this is going to progress in the future, because I think we will see more and more products like these that they are more consumer-focused

and not that technical to become more and more technical in order to deliver value. So looking forward to chat with him again in the future and see what's going on and what's new with LeafLink and Mike himself. Me too. Well, thanks again for joining the Datasack show. Subscribe to get notified

about new episodes on the platform of your choice. And we will catch you on the next one.