20 min read
How do you “keep the receipts” for your software process? Is it possible to automate change controls and deploy software with Continuous Compliance? Earlier this year, Mike appeared on the CodeStory podcast where he was interviewed by Noah Larbert. He explains how lessons learned as a DevOps consultant in regulated industries led to the realization that change management, risk controls and traceability were all part of a general governance problem that could be solved with automation.
You can listen to the audio below and we’ve also attached the transcript of the full interview. We hope you enjoy it, and if you have any questions about the things Mike talked about, don’t hesitate to reach out to us on social media, via our contact page, or in our Slack community.
Mike If you go and buy a coffee in the coffee shop, you ask for coffee, you pay for your coffee, you walk out with your coffee and that’s great. You don’t need a receipt because you got what you wanted. But if you were to buy coffee for the office, then it’s suddenly something you’re going to expense. There needs to be some kind of proof that you spent the money and then it goes into the official accounts for the company, and that receipt needs to have a life cycle because it’s got tax implications. There’s a whole story around it, so not everybody drinking coffee needs receipts, just like not everyone making software needs receipts, but if you need it to prove something in a legal context later, then absolutely the receipts are essential. Hi, I’m Mike Long. I’m the CEO of Kosli.
Noah I’m your host, Noah Labhart. Today we’ll hear how Mike Long created a way for you to deliver secure software changes at scale, compliant, and fast. This is the creation story of Kosli.
Mike Essentially what Kosli is, it’s a DevOps tool to help companies in regulated industries like financial services, banking or healthcare or medical device manufacturers, safety critical systems. What we see is that DevOps teams, especially in these organizations, have a lot of manual work and toil around audit, compliance, security, these aspects of their work. People making software in this space have a lot of rules because their software comes associated with a lot of risk as well. Money can disappear or even lives can be in danger. So the level of scrutiny and risk management you need to do is actually quite high. So all these teams need to have a software delivery process. They need to follow that process and they need the proof that they follow the process. When the auditors come, essentially they need to keep the receipts, so that’s what Kosli is for.
We record what’s running in your production systems and so on. We connect that back to the code commits, the pull requests, the approvals, the builds, the tests, the security scans and so on - the proof that you followed your process, and we make it all searchable. So, say the auditors come by - you’ve got all the receipts they need. It means that the developers in these companies don’t need to slow down to document their work.
The reason why I started the company was actually to do with my previous company. I was part of a DevOps consulting business. I was CTO in a company called Praqma. As a kind of a niche DevOps consulting business, we tended to get cool into places where DevOps was more challenging. There were more requirements than just the standard of a pipeline and so on. We saw the same problem over and over again, whether it was in automotive car manufacturing or medical devices or even healthcare records or banking, it was the same problem. Everybody described it slightly differently. Some said that they needed traceability. Some said that they needed to meet their change management needs. Some talked about the regulators, but like I said, zooming out, it was all the same thing. We just need to follow a process that manages our risk and have the proof. And after our company was acquired in 2019, I thought, okay, this is definitely the thing I want to spend time on.
Noah Tell me about the MVP. So, that first version of the product you built, how long did it take to build and what sort of tools did you use to bring it to life? It’d be interesting because in the industries that you’re serving, I’m sure that an MVP maybe might not be minimum. Maybe it might be, I don’t know where you’re going to go with it, but I’m curious.
Mike I mean it was very, very minimal. There was a big M in the MVP for sure. What gave us the courage to start the company was that me and James, my co-founder, we’d actually pitched this idea to a bank in Norway. So we said - we’d like to build this thing because this sounds like something you would like, and they said, yeah, sure. How about we fund a proof of concept over the summer? So we got quite good funding to spend the summer, three months, to build out a proof of concept, which was great. We closed our first company based on a two page white paper essentially. So that was the real minimum viable product to get us started. I knew kind of what I wanted this system to be, but basically every technical choice I made in the start was wrong.
I wanted to have an append only journal of the documentation trail, and back then blockchain was all the rage, but I was sure blockchain wasn’t the right solution for this because it was distributed and trustless, whereas this needed to be centralized and based on trust. Basically, I wanted to avoid anything where there could be mutation of data so I thought, well, I’ve got a lot of experience with the internals of Git - maybe Git could be the storage mechanism for this tool. That was like the first disastrous choice I made. The second disastrous choice I made was, well, I knew that I needed to get information from the CI pipelines into our system and I thought, well, okay, the system’s going to have a front end and a back end, so why not just do it in JavaScript? Then you’ve got kind of one holistic language across the whole stack. But that wasn’t really clever. And then the third mistake I made was that okay, and then the client tools that ran in the pipeline would be written in Python.
Happy to dig into why all those choices ended up being wrong and thrown out over time, but actually ended up throwing out Java before we even demoed to the customer. Basically replaced six weeks of JavaScript coding with one week of Python coding. It was just so much more, shall we say, productive to work in Python for the problem I was solving. So that was good that we kind of solved that quickly and yeah, it took you another year before we swapped out Git and the Python client tools. But all in all, the decisions early on were not great, but they were enough to get us our MVP to demo something and to start towards our early customers.
Noah You have your MVP, it’s working. You’ve proven the point, you’ve worked through all of your technological decisions. How did you progress the product from that point and mature it? And I think to wrap that question in a box a little bit, what I’m looking for is how did you go about building your roadmap and how did you decide, okay, this is the next most important thing to build or to address with Kosli?
Mike What kind of happened coincidentally was I built an MVP of the product - and we’d always kind of assumed it would be because our customer base was quite risk averse - we thought it would be an on-prem solution to begin with and that was really where our focus was. Let’s try and get four or five big financial institutions who want this thing and have them fund the development. And what happened at the same time was a thing called Covid-19 so that became - as a business plan - the wrong choice because all of the big financial institutions were not doing innovation projects in 2020 and even in 2021. This was the time to figure out how to use Zoom and run your bank remotely without office space in that period. It was time to reevaluate. We’re too early to sell this at scale.
Our early design customers are busy with other things at that moment, so what do we do as the next step? And what James and I really decided was, okay, let’s take this thing and turn it into a SaaS product, make it easy to use with no operational overhead and see if we can get some smaller customers on board. Because we realized that rather than funding it through innovation projects in big companies, we’d have to get early adopters and to go towards a VC funded route.
So that’s what we did in 2020 - built the SaaS basic functionality, made it self-serve to an extent, and towards the end of the year we picked up four or five fintechs and that was great. That was enough proof we had usage, we had people that believed in the idea, and that was also enough for us to raise a free seed round. And then once we had customers, it was a bit easier to drive a roadmap - we had customers with real needs that we could iterate with and use as design partners.
Noah Okay. You mentioned you raised your pre-seed and then you had enough money to build a team. Let’s talk about that team. How did you go about that process of building your team and what did you look for in those people to indicate that they were the winning horses to join you?
Mike I guess the unfair advantage that I had is that I have a lot of friends that are excellent technologists that I’ve worked with in the past, so nearly all the early employees, I would say yes, nearly all of the first 10 employees were part of my existing network. I’d either worked with for years or collaborated on open source or on the conference circuit. It was all people that I knew I would really want to work with if ever had a chance. I was very happy that they wanted to work with me as well. So that was kind of the hack I would say. And then as we’ve gone further, the net has been cast wider and it’s just grown from step to step. But what’s always been interesting is the further along my career, it’s less important what I work on, but more important who I do it with. So, figuring out who’s in the team is actually one of the biggest decisions you can make as a founder.
Noah Okay, let’s flip to scalability then. This will be interesting. I know the iterations of technology may have made this something that wasn’t thought of in the beginning, but I’m curious if Kosli was built with scale in mind from day one - or is this something you’re having to fight and adjust as you grow?
Mike We did. We kind of definitely had our battle with scalability. I wouldn’t say it’s behind us, but at least we’ve tamed the beast to the level of scale that we need for the short term. So as a startup, I think that’s the right level of investment. As I hinted at before, we started as Git as the database and that was fine until volumes got quite large. Then you start to realize that if you want to look at the history of a file and a Git repository, you actually have to traverse the entire repo’s history and that becomes extremely slow.
That was the big scaling challenge that we had to face. So, we did a lot of work last year to move towards an append-only document database and that really made a big difference. Obviously there’ll be more and more scaling issues as we get more and more customers and with the customers we’re onboarding now we’re looking at hundred thousand changes a month, millions of changes a year, and then being able to navigate that volume of data is going to be really interesting to solve. But then many of us in the tech team are coming from real time systems. I don’t think the technology risk is so big in our business - it’s more about the go-to-market risk.
Noah You’d piqued my interest with the append only document-based database. Can you tell me a little bit more about that solution and how you came about it?
Mike There’s no real magic sauce. We looked at a lot of different options here. Should we use a Merkel chain or what’s the right format for this? Where we ended up in the end was to use DocumentDB or MongoDB as the backend database and then write a transparency log on the site if we need it. We haven’t so far had a lot of pull. What’s quite interesting actually is that the guarantees for append-only, the mutability, are on our side in the application rather than as technical limitation, but because of this we can fingerprint every transaction into the system and create a transparency log for it. So, I think that’s where we’re headed towards going forward.
Noah Okay, so as you step out on the balcony and you look across all that you’ve built, what are you most proud of?
Mike I mean obviously the team is the engine that drives the whole thing. I’m very, very pleased with the team that we have. We’re 15 people, everyone has earned their seat in the team and it’s great because we’re all extremely motivated for what we’re doing. We’re having a lot of fun while we do it, and that kind of shines through when we go into conversations with our customers and work together on solving problems. It just makes the day so much better. Every problem’s a lot smaller and I feel like going forward with this team, we’re in a good spot.
Noah Let’s flip the script a little bit then. So tell me about a mistake you made and how you and your team responded to it.
Mike There’s not been any big mistakes, but there’s a lot of learnings that we’ve had that maybe would’ve shortened the cycles and what we’re doing. I think as a company it took too long to address the American market and to try and be active in the American market. If I was to do it again, I would not start a company selling to banks during a global pandemic either. I don’t know if they’re mistakes, but they’re definitely learning because I think that what I’ve learned over the period of building this business is that the US is a really great place to build companies and we were two and a half years into it before we had our attention set over here.
And I think a little bit of a culture challenge with Scandinavian startups in general is that there’s a lot of support locally. There’s a lot of talent locally, you can even get funding locally. There’s a little bit of a mentality - first you win in your local market, then you win Scandinavia, then you win Europe, then you win the US. I don’t agree with that. Having seen what I’ve seen so far is to get to the US as early as possible and learn as much as you can about the biggest market that you’re attempting to work in.
Noah You mentioned a little bit of this earlier, but I’m going to ask it as if you didn’t answer, or maybe it seeds my question a little bit, but I’m excited about what the future looks like for the product and for your team.
Mike From a technology perspective, we’re super ambitious, so we have a way to turn your environments, Kubernetes clusters, docker containers, S3 buckets into version control essentially, just automatically. We fingerprint everything and we serialize it in a way that just looks like version control. So you can have the change log of a Kubernetes environment, how it actually changes, and that means you can check out older versions like what was running on Christmas Day is a question we can answer. We can say - how has this environment changed this morning? What is its evolution over time or what is the difference between these two points in time or even these two systems? What’s the difference between staging and production is a really interesting question to ask. Oftentimes we’ve found that we’ve kind of built a very general purpose tool, but we’ve only focused on a very specific niche around compliance, audit and security.
And what I’m really excited to see is what happens when we open this up to folks that are not thinking about this from an audit perspective, but from a “I just need to know what’s going on" perspective. We’re starting to realize that we’re sitting on a lot of extremely valuable data, how your systems are changing, where those changes are coming from, being able to query and search and report on this stuff has got a lot of value, but we’re starting to realize, well, how do we get this information out to people? Is it through chat integrations to Slack? Where else should this data be showing up? How else should we be integrating with other systems? What I love about this problem is that the more we pull on the thread, the more we find it seems like an endless possibility. Again, it’s kind of like an ERP system. You can think about your DevOps as being like the factory floor. This is how your software changes get made. We’re like the ERP system and as an ERP system, we haven’t really gotten to the bottom of what we could do with that power
Noah As you were describing, and I was thinking about that, opening it up to other people. Does that change the product or the product approach? I imagine the people or the entities that you’re targeting now that are a little more regulated perhaps are maybe more enterprise leaning. I could be wrong there, but that’s where my head goes. And does that change how you build the product moving forward? Does that split it?
Mike Fun thing is that it doesn’t change the product very much because regardless of what the use case is, you want to record the facts. So what you need to make sure is that this is a true record of the deployment. That this is a true record of what’s running in this system or this is a true record of this security scan, that all stays the same whether you’re using it for security or audit or if you’re just using it to find out, “Hey, I’ve had an incident, what changed?” Imagine your alerts are firing. You go and look at your dashboards and your monitoring tool. You see, okay, something’s going wrong. Really the first thing you want to know is what changed. That doesn’t change our system, but it brings new challenges in terms of messaging. How do we describe our tool to the market? How do we find our customers? How do we let them understand that this is also for them?
Noah Tell me who influences the way that you work, name a person or many persons or something you look up to and why?
Mike Well, I mean the great thing about working in the software industry is there’s so many people to be inspired by. I mean, we’re just surrounded by great role models. I think the ones that are closest to home, the ones that I work the most with are actually our investors. We’re lucky enough to be backed by a venture capital company called Heavybit in Silicon Valley, and they’re all dev tool founders in the past, the partners in the firm.
So, Jesse was a founder at Chef, James was a founder of Heroku, Joe was a founder of Librato. They’ve all walked the walk in this space, they’ve all built tool companies. They understand the market and they only invest in DevOps companies, essentially. So it’s been PagerDuty, Stripe, LaunchDarkly, these kinds of companies. So the whole network around the ecosystem, it’s just fantastic - constantly being introduced to people that I’m just in awe of. I couldn’t list them all, but there are a lot of people, especially in these circles, that have a wealth of experience and are very generous with their time, which I’m forever thankful for.
Noah We talked about a mistake earlier, but this is a little different spin, Mike. If you could go back to the beginning, what would you do differently, or where would you consider taking a different approach? It doesn’t have to be something that was a mistake or it doesn’t have to be something that even didn’t work, could have worked well, but maybe you’d tweak it a little bit.
Mike I touched on it a bit earlier. I think that all things being equal, I wish we’d come to the US earlier. Maybe this is just my experience from the outside, but in Scandinavia where our home is, it’s very conservative. People are comfortable, very comfortable, but it doesn’t lead to an awful lot of innovation and risk-taking, especially with the types of customers that we’re targeting. So it was quite a hard place to start. I think if I was honest, if I had another chance, I would find a way to get to the US or find US customers, find the US market earlier because there’s so much to learn from the US market and just it’s easier. It seems like the risk appetite and the competition is much, much stronger. So there’s always a desire to find a new edge, to try something new.
Noah Okay, Mike, last question. So you’re getting on a plane and you’re sitting next to a young entrepreneur who’s built the next big thing. They’re jazzed about it. They can’t wait to show it off to the world and can’t wait to show it off to you right there on the plane. What advice do you give that person having gone down this road a bit?
Mike So, I would definitely encourage them to turn their idea into reality and to do it as quickly as possible. Social media is full of armchair generals, and armchair generals don’t win the war. The way you actually succeed in life is to go out and do it and make the product market fit. Find customers and do all the hard work. It’s not easy for sure, you’re going to make lots of mistakes. You never get it right because this isn’t what you’ve done, especially if you’re a technologist. You spent your time writing code and getting good at that and maybe building products as well.
But taking an idea and turning it into a business is a hard problem. But the only way to do it is to actually do it. You can’t go off and do an MBA and do it. There’s no prerequisite. No one’s going to pick you. You just have to go and do it. So that would be my encouragement. Do it. Absolutely do it and do it as quickly as you can because time is flying.
Noah Couldn’t agree more. Well, Mike, thank you for being on the show today, and thank you for telling the creation story of Kosli.
Mike Been an absolute pleasure. Thanks Noah.
Noah And this concludes another chapter of CodeStory. Code Story is hosted and produced by Noah Labhart. Be sure to subscribe on Apple Podcast, Spotify, or the podcasting app of your choice. And when you get a chance, leave us a review. Both things help us out tremendously and thanks again for listening.
