We've decided to license all our code under MIT and make it fully open-source. With this decision also comes the realization that it is unlikely we will establish a company based on Kviklet. In this post we are sharing some learnings from our journey and what's next for Kviklet.
The Problem Space and Market Feedback
Our initial observation was clear: database access, and production access in general, represents a significant hurdle across the tech industry. The existing solutions, including StrongDM, Teleport, and Apono, are not only complex but also carry a hefty price tag. However, as we delved deeper, we discovered that awareness of this problem varies greatly, and so does the willingness to pay for a solution. Highly regulated industries showed readiness to invest in complex, expensive solutions, whereas less regulated sectors remained largely oblivious to the issue, showing little interest in paying for such tools.
The Reality of Selling an Open Source and Self-Hosted Tool
Selling an open-source and self-hosted tool itself is much different from selling a typical SaaS solution. Telling someone about your product that they then have to install on their own infrastructure instead of a simple "Login with Google"-button on some website, was a significant hurdle in selling. For a security tool like ours, there was, however, no way around it, hosting your database access on someone else's infrastructure is simply way too risky.
The Security Sector itself
The security sector, in particular, presents a "cold start" problem. Our tool, designed to be simple and appealing to small companies, didn't resonate with its intended audience. Small companies are often indifferent to security, and larger companies seek solutions with a proven track record—leaving us in a catch-22 situation. We also do not want to build a generic security tool, but a tool that is specifically designed for database access. Because this is where we think the building around the four-eyes principle is most important and presents a significant advantage over other tools.
Compliance sells better than actual security
Companies that are regulated or try to maintain/achieve specific certification are much more likely to buy a security tool. This is not because they are more secure, but because they have to prove that they are secure. This is a very important distinction to make. As an early engineering-led product we heavily focused on the security aspect of our solution. We could also explain why the implementation of this workflow is secure and companies should use it, but decision makers often didn't care about actual security but what it could gain them on paper.
Open Source: Not the Amplifier We Hoped For
Making Kviklet open-source did not significantly boost our visibility or adoption. While platforms like Reddit, LinkedIn, and Twitter offered some traction, most leads came through direct networking, cold outreach, or meetups. Nonetheless, the community's engagement did lend us some credibility. I also believe that this is a long-term investment and that the community and visibility will grow over time.
Security has a difficult to prove ROI
One of the most challenging aspects we've encountered is demonstrating the return on investment (ROI) for security solutions. Especially in a market that often prioritizes immediate, tangible benefits, the preventative and intangible nature of security investments makes it a hard sell. This challenge is compounded in environments where efficiency and cost-effectiveness are paramount. Companies are busy trying to cut costs, reducing head count, and finding immediate efficiencies which Kviklet only provides if your current workflow is inefficient.
What’s Next for Kviklet?
Despite these challenges, we still believe Kviklet is a great tool and solution. We will continue to develop features that we find cool and useful, dedicating our free time to this passion project. We are also open to contributions and eager to support anyone interested in enhancing Kviklet. Companies now have complete freedom to use Kviklet, and we stand ready to assist with any required support or specific feature development. Who knows maybe in the future there will be other opportunities for us to make Kviklet a success.