Bootstrapping after 8 Years on the VC-Backed Path, Getting to Multi-Million ARR with a Team of 3, and Notes on PLG with Userflow’s Co-Founder, Esben Friis-Jensen


In the following exchange, Userflow’s co-founder and CEO, Esben Friis-Jensen (@esben-userflow), stresses how scaling a company with institutional capital can often unerringly distance founders from what they cherish most about starting up: the product and the customers they’re building for.

He also writes about his decision to switch course towards funding his own business, choosing a market that aligned best with just that goal, and growing with exceptional efficiency.

Why Esben bootstrapped his second startup
Brief notes on scaling thoughtfully as a small team
Setting the PLG foundation from day one


Why Esben bootstrapped his second startup

There are the two primary reasons for bootstrapping Userflow after having founded a successful VC-backed startup (Cobalt) before:


When we started Cobalt the ambition for us (like many other startup founders) was to become a unicorn. What I learned over the years, though, is that such a journey takes a very long time without necessarily benefitting the founders as their ownership gets diluted for every round.

So albeit Cobalt is successful and I think we took the right path as first-time founders, as a second-time founder, I wanted to do it differently.


When you are VC-funded, you are often incentivized to hire more people than needed, instead of thinking as lean as possible. As a result founders tend to get further away from the product and customers and move more towards people management and org building.

Whereas I love working with the product and customers, so I prefer being on a smaller team that makes this possible. We have full autonomy on where we want to take the business.

There is no artificial, external pressure.

Even during a time with slower growth, as 2023 has been for most, we are still happy.

We still set revenue goals. But that is more for our own motivation and not as something we are committing 100% to and hire according to. As long as we see good growth compared to peers we are happy.

Plus, both my co-founder and I were experienced in building SaaS businesses, which also made us more confident about how well/fast we could build things and monetize.

Another reason why we were able to self-fund Userflow is that the cost of market education was (and continues to be) low, given that this is an established (and competitive) market.

It had potential customers who knew they had a problem, those who were looking for a solution, and then those who were already using existing products.

We could get to product-market fit faster just by focusing on our unique differentiation (strong, easy-to-use UX and robust features for serving different levels of sophistication).

The existing demand also meant that we could deploy SEM (search engine marketing) early on in Userflow’s journey. We found the first few customers via our network, but right after, a lot of them came through SEM.

Brief notes on scaling thoughtfully as a small team

How can one do it?

Well, spend your money wisely and only hire if you absolutely need to.

Even though Cobalt had raised external capital ($37m), we were always frugal with spending money, especially in the early days.

But we did hire a lot of people over time. Which was not always the best, so that is one thing we decided to do differently at Userflow to avoid managerial overhead.

Often when you hire a new director/team lead they will ask to hire four-five team members. But challenge that and see how resourceful a single person can be. In the early stages especially, you should hire doers and not people who only want to manage.

But the primary way to stay small, yet effective is to adopt product-led growth (PLG) as your go-to market model and a mindset where you always think product-first in everything you do.

So if you e.g. get a lot of support questions, then think of how you can fix the root cause in the product instead of hiring more support staff. This is the number one reason why we at Userflow have been able to scale with a small (three-member) team.

Finally the things you cannot fix in the product you should try to automate.

There are great tools out there for automation of emails and other processes.

Setting the PLG foundation from day one

On the PLG thread, I think it is a great model that can drive growth at scale and I recommend every startup to have it as a foundation.

It makes attracting new customers much easier and also opens up a channel for getting diverse product feedback faster. And in the long run, it helps reduce customer acquisition and service costs significantly.

We opened up pretty early for a free trial and started charging for the product.

In that way we could see how users signed up and bought the product. I think too many founders keep their product hidden from their potential customers for way too long.

So building out a PLG flow should not be used as an excuse to not do customer validation. You should still speak with your customers (especially in the early stages) to ensure you reach product-market fit (PMF) and build a smoother motion.

We’ve extensively documented how we’ve shaped our whole PLG funnel, here.


[A Loom from Esben on Userflow’s sign-up process]

We have automated user onboarding both in-product (using Userflow :)) and via email. These drive the users towards aha moments. This focused onboarding combined with having a great product that solves a real problem has been essential to driving growth.

We have built ours in a way that follows best practices. Making it action-driven and focused on the right aha moments. Which, in our case, means how easy we can make it for our customers to build onboarding and customize it.

Furthermore every part of the process from our marketing, to website and the sign-up flow, to the actual product has a lot of transparency around the product and a very aligned messaging (‘fast user onboarding’) that attracts the right user profile (in our case product management and customer success).

Transparent pricing is, as you’ve mentioned, another key to PLG motions and a model that works particularly well in PLG is usage-based pricing. We, for example, charge based on monthly active users.

In that way businesses can start small and grow in cost as their company grows.

We did this out of the box, because server pricing was higher for more MAUs, so it made sense to charge for it. But usage-based pricing has also, in general, gained popularity in the PLG space.

All our tiered packages/offerings share a PLG foundation.

We have a more expensive enterprise plan that justifies us spending more high-touch time on larger customers. But by being focusing on self-serve we are saving tons of time on all customers both small and large.


Related reading from the Relay archives:

Lou’s co-founder, Rachel Pardue, on shaping the self-serve path to the first 1,000 users
Lately AI’s co-founder, Kate Bradley Chernis, on ignoring MRR for the self-serve switch
MagicBell’s co-founder, Hana Mohan, on “thinking of bootstrapping as a, not as a way of life”


Great to read about how you’re deliberately shaping your second venture and prioritizing what you value most as a builder, @esben-userflow. The Userflow team, if I’m not mistaken, comprises two co-founders and a designer. So I’d be curious to hear when and what role you’re thinking of hiring for next. And what would be some of the operating (skillset) requirements that’ll make it to their job description.

1 Like

Thanks for your question. We are unlikely to hire more people. But if we were to hire I would maybe hire a strong partnership person. As that is a good PLG channel, and its not a skillset we have today.

1 Like

Thanks for this @esben-userflow

I really want to get into hands-on here about the B2B user flow.
Multi-tenancy allows the flexibility to isolate the tenant data, preferences, etc to fully customize the product. Great.

Even before that, while signing-up, how do we screen out the public domain ID’s like,, and etc from signing up?

Afterall, and are domains and can be counted as Tenants.

Here is what we do currently,

  1. A database with all the public domains (around 4000+) we borrowed from a reddit thread and a git repo that’s updated by a community.
  2. Link the database to a logic saying, do not accept email with these domains.

Is there a better way to do this?

Mainitaining the Database is an Issues and it’s a lag nevertheless.

We wish there is a better way. Appreciate your help on this.

Are you seeing any edge cases in this process? Like a Public domain company engineers can be your users?

1 Like

Yes you can use tools like