In the following exchange, Typesense’s co-founder and CEO, Jason Bosco (@jasonbosco), points at the locus (and the limitations) of the VC-backed SaaS “disruption” cycle, explains how that leaves SMBs perpetually underserved, and describes their own attempt at building an open-source, self-funded, “value-sharing over value-capturing” alternative.
— Why open source is an ideal bet for developer tools
— How the SMB market is (predictably) left stranded
— De-risking a flaw that both VC-led and bootstrapped paths share
— Monetization models: open source vs. open core
— Figuring what to build next with the Typesense community
Why open source is an ideal bet for developer tools
If you’re building a dev product, today, doing anything other than open source is making life harder than it needs to be. From what I’ve seen, this way there’s less of a resistance from developers to try out something new.
Typesense has been around for 7 years.
But potential users discover us for the first time every day. And despite all the metrics that we publish such as our searches per month, servers we’ve deployed in production, and GitHub stars (as vanity a metric as that is), some people are still skeptical.
“Is this going to be around?”
“Can I adopt this?”
“Is it safe to work with?”
“How do I get help if I run into issues with it?”
Having an open source community element helps allay some of those concerns.
Especially so for us given that we haven’t raised institutional funding and thus don’t have a major credibility signal for addressing what I call, drive-by user evaluations — figuring out if a product is even worth exploring within the first 5 minutes.
With Typesense I’ve had folks repeatedly mention, “well, worst case, if you aren’t around, I’m happy that I can self-host this or I can look into the code.”
Not that anyone has had to do it to my knowledge. People are certainly self-hosting, but most of them aren’t changing the source code and hosting a customized version themselves. Still the possibility exists for them to do it and that helps reduce friction.
Then, there’s word of mouth. Developers are more comfortable sharing an open source project with their peers rather than a paid SaaS app.
I also love the fact that sometimes when people report bugs they’re also able to jump into the source code and say, “I think this is where the issue might be” or ask, “any reason you’ve done things this way?”
Sometimes even suggesting possible solutions and PRs.
That sort of dense-information feedback certainly shortens bug resolution cycles.
Which isn’t the case with SaaS products, where all users can do is observe symptoms and one ends up wasting a lot of cycles just exploring causes.
How the SMB market is (predictably) left stranded
It’s great that entrepreneurs have access to venture capital during the early stages.
To build their ideas out. To test the market. To find their ideal customer profile.
Banks weren’t built to sustain such risks.
Where incentives really start diverging is typically at the growth stage, where VCs invest $50m/$100m/$200m in a single company. With an implicit, well, actually explicit understanding that you’d become a billion dollar business.
And the easiest way to get to that mark (increasingly in terms of revenue, not just valuation)? Would you spend your time targeting customers that pay you a thousand dollars a year? Or a millions of dollars a year?
The latter path is, of course, the more efficient path.
There’s nothing wrong with it. This is just how the math works out.
That’s why, in the beginning, VC-backed companies prize and go after early adopters (usually other startups and SMBs are more willing to give new technologies a shot). Even subsidizing pricing to propel their reach.
By the time they hit series A/B, growth-stage VCs show up, and the projected growth trajectory suddenly changes. Now the same trusting SMB market seems like peanuts and gets deprioritized.
Which leaves a gap.
That paves the way for the next cycle. Another startup starts solving for SMBs. Eventually going upmarket as well. I’ve seen this repeat time and again, across markets.
There’s an opportunity for someone to build a long-running business that specifically focuses on the consistently-left-behind needs of the SMB space.
Either because prices become too expensive.
Important new features automatically end up behind “contact sales” CTAs.
Or because products turn overwhelmingly complicated as they try to serve new segments and verticals in search of those higher revenue enterprise deals. Doing everything for everyone. Building abstractions on top of abstractions.
So, in service of keeping the software simple and attaining mass adoption, what if we created a company with the goal of serving the Fortune 1 million (or go even beyond that) not the usual Fortune 1000 (there are only so many of them after all :))?
Another thing worth noting is how even YC recommends founders to raise a seed fund and get to profitability as soon as possible, so they don’t have to raise ever again in the future.
Again, I’m not suggesting not to raise funds.
It can be very difficult to sustain a venture in the early stages.
The way we were able to de-risk the whole journey was because we built Typesense as a nights and weekends project while working at other full-time jobs and relying on side-projects for capital. Only jumping in full time 5+ years into Typesense.
I understand that not everyone has that option.
But when it comes to raising, I’d suggest, go through the early rounds (angel, seed, even series A) diligently, and then get to profitability right after.
If not, you just have to be okay with setting yourself up on a billion-or-bust trajectory.
De-risking a flaw that both VC-led and bootstrapped paths share
The years of intensive R&D effort that went into Typesense isn’t just because search tech is uniquely demanding. Whenever one spends that much time in a particular domain, you end up building more and more of a moat of expertise.
This is connected to the previous section and really speaks to a common limitation of both VC-led and self-funded paths. If you can remove the element of capital entirely — i.e “I need this thing to make money as fast as it can” — I feel that’s where innovation happens.
There’s this book (Drive by Daniel Pink) on the subject of what motivates knowledge workers.
In an experiment that the author writes about, researchers found that adding financial incentives had a negative impact on creativity and output.
The elements that instead motivated people were: autonomy, mastery, and purpose.
Raising VC funds, as we’ve seen, by definition comes with a ticking clock of how much you can burn until the next round. With bootstrapping, too, your savings runway acts as a similar forcing function.
Which is why I recommend the path that we took.
Keeping our day jobs and building on the side without external pressures and self-imposed time/financial constraints. We were able to spend dedicated exploratory time within the problem space, truly understanding the technology and our users.
We didn’t jump into Typesense full time until enough people started telling us, not just that we had something interesting in the works but that they’d pay for it.
We had paying customers the week we launched Typesense Cloud.
That’s how much we de-risked the whole thing.
So. Perhaps. Don’t quit your jobs just yet. If possible, don’t raise a seed round before you’ve figured out what it is you’re really going to build and if people are going to pay you for it.
That’s the most ideal of all paths I’ve seen.
Monetization models: open source vs. open core
Speaking of monetization, we failed at first.
Our first bet was on the open core model.
Offering a premium set of features alongside the free and open source product.
Interestingly, none of our users had asked us to take that route.
It was just our hypothesis that certain features would be appreciated more by larger companies. And that they’d likely be willing to pay for a premium license to access those.
It did not go well at all.
Then, 7-8 months after that is when people began requesting us for a hosted version of Typesense. As there wasn’t much adoption of the open core model, we decided to open source everything and charge for hosting instead.
Which proved to be an excellent, not just a viable monetization alternative
And we learned a lot in the process.
As we opened up the previously paid, closed-source features, more people started using them and giving us feedback on bugs and on the big UX gotchas, which, in turn, led to more iterations and made the software more stable for everyone.
In hindsight, this was ironic, as you’d usually expect the premium offering to be more reliable. But, in our case, it was the least stable part of the software as it wasn’t exposed to as many users as the free, open source parts.
The incredibly tedious conversations around whether a feature should be open source or gated were also completely out of the equation.
This decision has reaffirmed the amazing benefits of open sourcing everything.
There’s a definite risk to this as well.
But we have a GPL license. Which means that if someone wants to change Typesense’s source code, they’re required to publish it open source. This licensing philosophy helps build the Typesense community together.
Something that just won’t fly at a VC-backed company where a key principle is to capture maximum value as a single entity. Whereas, we want to share the value with the community as we’re building not just with their feedback but also with their contributions.
Similar to what Linux has done over the years.
This has been working really well for us.
Figuring what to build next with the Typesense community
Typesense’s product prioritization has mainly been driven by the simple metric of the no. of people asking us for a particular feature.
Which, I admit, is a crude way to do things but has served us very well.
There have been, thankfully, very few cases where we’ve had to so no to a request. Because most of them concern use cases that are adjacent to what we’re already solving for.
But if someone was to ask, “I’m using Typesense for site search and I would now like to use it for indexing my application logs,” that is a big stretch. Going from a JSON data source to unstructured log data from an application. That’s something we’d say no to.
Then there have also been the “we’ll get to these some day” sort of ideas where a user’s own progress has nudged us in a direction to prioritize faster.
Case in point is vector search.
A few of our users, who were deeply integrated with Typesense, also wanted to run similarity searches based on image data. It would have been painful for them to switch.
The fact that they had already been experimenting with some workarounds, and were willing to give us feedback and iterate with us, made us take it up way sooner than we would have otherwise.
Support for Thai and Vietnamese is another example. We don’t have native speakers of those languages on our team. So when someone, who was a native speaker, showed up with feedback and helped us iterate with each build, we were able to move quickly.
Then, whenever we kick off work on a feature, we apply first principles thinking.
Let’s forget that we have these huge products (ex: Algolia and Elastic Search) that solve this. If we were to build for a particular use case from scratch, how would we approach it?
That simplifies a lot of things.
— MagicBell’s co-founder, Hana Mohan, on realizing: “capital, I’d tell myself, is just another tool”
— YouCanBookMe’s co-founder, Bridget Harris, on why bootstrapping is an art not a strategy
This is definitely hard and requires intentional commitment to doing this well.
