CEO Mike Long has the experience and humor needed to start up Kosli. Working with Userfront engineers has been effortless and enjoyable.
Mike built the MVP for Kosli. Now he’s involved with everything from sales and support to “emptying the trash.” But, at his core, he is a technologist who loves building products for developers. His expertise is making DevOps easier, especially in the field of regulatory compliance.
Before Kosli, Mike was CTO of a DevOps consulting firm with customers in regulated industries like banking, financial services, automotive, healthcare, and safety-critical devices. Even though each industry has its own challenges, the needs of providing auditability around the software delivery and DevOps changes were universal.
But, as Mike notes, “As a consultant, you're there to solve a problem. Nobody wants you to build a product.” So, when that consultancy was acquired in 2019, Mike saw the opportunity to start something new. He saw a clear need for DevOps change management automation in regulated software industries that could be solved with a single, tool-agnostic platform. For Mike, it just didn’t make sense for every company to reinvent the wheel with duct tape and undifferentiated heavy lifting.
“And this was what I was passionate about - helping engineers in our most critical industries deliver their work faster with lower risks.” Mike notes that Kosli “handles the parts of DevOps where you have more rules about how things have to get done.” They provide change management automation for fast, compliant deployments, removing the need for slower and riskier processes involving screenshots, spreadsheets and tickets.
We asked Mike what his favorite ways to stay current are. His answer rang true to us and was truly inspiring.
So, this is a bit old fashioned, but my favorite way of staying up to date is to meet people in real life. I go to conferences, meetups, and seek out the “Hallway Track” as my grapevine. It’s everywhere. You know, I was at a meetup last night about platform engineering and developer experience, and learned a lot about the real-life pitfalls of scaling devops in large organizations. Because when you talk to actual engineers solving their real problems, you get the real truth. It's not like what's hot on hacker news or what the marketing website has in their case studies. Talk to engineers and they'll tell you exactly what they think about products. And that is great, because this grapevine is what keeps the industry going.
Mike wrote the first thousand commits of Kosli. As with many startups today, it was about getting an MVP out, people using it, getting feedback, early traction, and funding. When authentication came up, developers were already using GitHub accounts, so he opted for that authentication provider. It went quite well for a while. Then he started getting enterprise customers, with enterprise requirements, who were not willing to log in with GitHub.
He liked the customer and wanted the big contract. He needed to figure it out. Mike’s team chose to build a single tenant version of their product which would authenticate with the given Identity Provider (IdP). The solution worked for the enterprise customers they were setting up. But, along with the default GitHub auth, it meant maintaining multiple authentication schemas. Mike discussed the logical conclusion to this design:
Then a customer comes along who's using Okta. Then another customer comes along who wants to log in with Google. You know, it grows, right. It was unsustainable for us to spin up a new environment for everyone that wanted SSO as well. Like, we need to do this multi-tenant. Okay, well, now is the time. Come on.
Mike and his team wanted to focus on building Kosli’s specialized feature set in the product they were selling. And some of those features were grounded in some pretty basic enterprise concerns: Where’s the data? How does the user log in? What does the SLA look like? But IdP code is outside of Kosli’s differentiated offering and as Mike put it, “unsatisfying to write. (with all due respect to the fine engineers at Userfront.)” Mike realized it was time to use a service:
This is just part of growing up. We have to do it. And that was the time to look into the market. Now, we need a proper authentication system. We need to do this right and in a scalable way, which will solve all the enterprise needs around authentication.
A driving factor was satisfying multi-tenant users with SSO, specifically active directory and Google. Later, when they acquired a customer who was using Okta, Userfront “just worked. It wasn't another thing to do.”
At the time his engineering team migrated to Userfront, Mike wasn’t coding. (He jokes about his engineering team not letting him near the code anymore.) As CEO, Mike viewed the migration as background noise. It was not very painful or memorably difficult. For the most part the migration didn't affect customers. If they were already logging in with GitHub, they just continued. But now they could also log in with Google. Kosli could satisfy customer requirements, like a particular SSO. And if the customer wanted to be on Kosli’s multi-tenant solution, they could do that too.
As a technologist, able to fill multiple roles, Mike understands the buy vs. build question from different perspectives. He gets why engineers need solutions like Userfront with a generous free tier, especially at a pre-funded startup:
Putting on my engineer hat, I'm like, “I don't even know who to speak to in my company to get approval for a paid product.” So anything that has a price tag, I'm scared of. In contrast, I can write as much code and no one cares. Code is free. I'm going to do it. I don't have to ask permission. It's what I do anyway. So there's a bias to open source - roll your own free options, right?
But if there is a free button where I don't have to go around and find out where the finance is coming from? If there is, then I'll do that.
Mike also understands a manager's mind. You have no ability to write code, but you can write a check. That's your option.
When it comes to investing in R&D, you're like, “I'm going to take engineers and have them work on an IdP solution? That's not core business.” I can write a check to get them back on core features, which will get me where I need the team to be.
For someone with a startup mentality, a crucial ingredient to success is early and frequent feedback:
Most projects start small, even if they're in a company. “Let's just get something up. Try it out. Time-to-feedback is really important.” If the first thing you're doing is figuring out how to log people into your application, you’re just kicking the feedback further down the road. There are lots of reasons why using a tool like Userfront makes sense.
If you're just getting started, Mike cautions against implementing your own IdP:
Don't do what we did. Don't make it. Don't roll it yourself. Userfront has got a generous free tier that makes a lot of sense for the hobbyist and the startup alike. Get in. Get working. Then, when you're big enough, pay for Userfront.
We hope this spotlight conveys the delight in building a startup and integrating Userfront Ready to build your own?
Experience smarter enterprise sign-on tools & reporting.