Pursuing an Open Source, Bootstrapped, Long-Run Path towards Serving the Fortune 1 Million with Typesense’s Co-Founder, Jason Bosco


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


Happy to answer any questions! Feel free to @ me :slight_smile:


Thanks for doing this, @jasonbosco! This captures a core omission of the typical B2B SaaS playbook. With your lens, there’s much to reflect on for both early-stage and late-stage founders. I agree, there are very few instances of companies serving customers across segments. From what we’ve learned at Chargebee, it’s certainly possible but quite hard and requires a special, constant commitment. I’d also love to hear your thoughts on hiring. Given Typesense’s open source model and the inherently great access to contributors, how differently have you approached it?


:100: This is definitely hard and requires intentional commitment to doing this well.

Great question! We’re able to expedite the hiring process significantly and make it more information-dense given that Typesense is open source.

When we open a role, we pick a small, relatively independent, feature request and have the candidate(s) work on it as a paid project, as if they were contributing to any open source project - so all communication around architecture, approach, code reviews, etc is over GitHub.

We also don’t set any time constraints - we let them give us a very rough timeframe for when they will be able to complete it, since they might already have another full-time job.

Once their PR is reviewed and merged, and we both like how we collaborated with each other, we then extend an offer with no additional steps.

This allows candidates’ code to speak for itself, and both the candidate and Typesense get first-hand experience of what working together would look like.

In many cases, we haven’t even looked at candidates’ resumes when they started working on one of these paid projects! This model is very similar to how in open source, in a non-hiring context, contributors are not asked to share their resumes when contributing a PR. Instead code is the central artifact around which collaboration happens.


Which Engineering Background person doesn’t love this? @jasonbosco

I stay more on the business side, but given my involvement in the product with my co-founders who code, we always aim for the AMP (Autonomy, Mastery, and Purpose). In fact we hire people and give them enough AMP power to make things fast and amazing.

Totally cool thing to have.

On the contrary,

we are 1 year into clAppIt, a dev centric platform and now feeling the big burn of R&D of building a platform on top of multiple open-source projects (Solving Key problems like application infrastructure, multi-tenancy, multi-cloud, and so many) that are SaaS centric Engineering problems which are hard to weave together.

We abstracted IaaS for Multi-Cloud, CI/CD, Multi-tenancy, & Service Applucations like RBAC, Metering, Monitoring into a Single pane of Glass.

Phew, I wish I had an easy way to say all of that but it is what it is.
P.S. Totally not proud of this explanation.

We hypothesized this in the early months but a gentleman from Github, (Karan) corrected our path and said don’t take the route unless you want to go all in community.

In de-risking our product, after listening to your story we will go back to the drawing board to see how we can pivot if we need to.

We got a good intent from large enterprises in the last couple of months, it’s exciting but also scaring the shit out of us as we lack the resources of a funded startup and an open source product.

@jasonbosco If you allow me to, couple of things I would like to pick your brains on:

  • We would love to go open-source but don’t have any money to do so as we quit our jobs without realizing how complex of a problem we are solving. What do you suggest us to to do to stay afloat and keep building for the Fortune 1 Million?

Since we have a couple enterprises ($B+ Companies) interested, should we go full speed or pivot away from the big guys at this stage?

BTW, Our MVP is ready.

If we have to approach a VC, when do you think we should do?

  • Could you spare 15 minutes to review our product and give brutal feedback as an Engineer? Would love the criticism so something magical might happen to us. :sweat_smile:

Last but not least, Amazing to read your Journey. :pray:t4:


Ha! Nice acronym! :raised_hands:

One option to consider is to do some hands-on consulting work related to your domain. So for eg, in your case, you could help companies optimize their infrastructure or setup production grade monitoring, alerting, etc for them, etc.

This way you’re also able to gain valuable context into different stacks that you can use to improve your product, while also generating revenue.

If you have enterprises interested already, I would definitely not shy away! Get one or two folks to signup as a design partner and use their feedback to improve the product and make it a complete offering.

Disclaimer: I’m not a VC, so this is 2nd-degree information based on my interaction with VCs.

Very often VCs are looking for the next company that could become the next billion dollar company in their portfolio and one that can show some early leading indicators of this trajectory.

So the more growth you show month over month, over a sustained period of time (in terms of customers, revenue, downloads, etc), the better you’re placed to gain the interest of VCs and more importantly the better terms you’ll be able to get from a deal.

Since you asked for it! (Also disclaimer: I might not be your target customer, so you want to ask your potential target buyer to give you this feedback).

  • “Build Your Product for the Future” seems way too generic IMO, it doesn’t convey the value your product delivers.
  • The line below that heading is too wordy, I would find a way to shorten it.
  • I would recommend having a section that talks about the pain you’re solving - like what people would do before your product, and then show how your product would solve it.
  • Add more navigation elements to the top nav-bar, especially pricing, so it’s easier to find.
  • Add some element of social proof - number of downloads, quotes, early customer logos, etc.

@jasonbosco Thanks a Ton! Definitely revamping the entire thing.

Pricing page is getting ready, the model is ready. :black_heart:

On it, in the middle of project helping a company solving AWS to Multi-cloud Migration/Transformation Setup.

Approached 5 companies and started the UI alongside their feedback.
In a month, the Version 1 will be ready to use.

Done! :pray:t4:

1 Like