To help raise money for his university studies he would launch a website consisting of 1 million pixels organized into a 1,000 x 1,000 grid; and sell 10 x 10 blocks for $1 per pixel.

The Million Dollar Homepage went live on the 26th August 2005 and quickly became an internet phenomenon. By the 11th January 2006 the final 1,000 pixels were sold via an eBay auction for $38,100, bringing Alex’s total tally from the website to $1,037,100.

A few days ago a somewhat similar story went viral on X.

Jonathan Wilke, a German indie developer launched Outbid.lol, a simple leaderboard-style website where individuals or businesses could bid for placement on the leaderboard. If you wanted to be #1 on the leaderboard, you’d need to pay an amount higher than the amount paid by the current leader.

On the surface the idea sounds really silly. Why would a business spend money to be on a new website with no organic traffic, authority, backlinks, or brand awareness.

Well reader, the idea worked.

The website went viral and at the time of writing this post (less than 4 days since it went live) over 1.2 million people have visited the site.

Over 1,100 bids have been placed in the hope of capturing some of the traffic hitting the site. The highest bid so far, $15,000 😳.

As the screenshot above shows, Jonathan has earned $177,506 so far from his viral site, an incredible +-$45k a day from a website that took him about 3 hours to build.

Just like in the case of Alex Tew’s Million Dollar Homepage, many developers have cloned Outbid trying their luck to make a quick buck. The vast majority will fail and none will get even close to the financial success Jonathan has seen.

I think when unique situations like Outbid.lol come around it’s useful to analyze the situation and learn what we can.

The rest of this post is going to do just that.

Subscribe now

Why did Outbid.lol succeed?

Every day thousands, if not tens of thousands of developers launch new projects and the vast majority never make any money.

Apparently someone launched a version of Outbid back in 2024. It made a few thousand dollars but never went viral anywhere close to the level we’ve seen with Outbid.lol.

So what makes Outbid.lol special?

In my opinion it was a combination of factors, fortunate timing and some luck.

The success factors of Outbid.lol

In the New York Times best seller, The Tipping Point, it’s author, Malcolm Gladwell makes the argument that for ideas to go viral multiple factors need to be in place.

I believe that for special situations like Outbid to occur, there needs to be multiple factors working together to create outsized effects.

Some of these factors are directly influenced by the creator, while others are external.

Below are the success factors of Outbid as I see them.

• Novelty

• World-class execution

• Simple concept that’s easy to share

• Easy to use, low barrier to entry, and repeatable

• Transparency and real-time reporting

• Leveraging human psychology (inclusivity, ego, the game show effect)

• Distribution desperation

• Existing audience

• Launching on X

• “If he can do it, so can I”

Novelty

Unfortunately one of the outcomes of AI’s meteoric rise is more and more crap stealing our attention. When a new, interesting idea captures our attention it has an impact.

We are now living in a world of mass produced content and cloning. New ideas are rarer and will therefore stand out.

World-class execution

I think one of the most important factors in my list is Jonathan’s world-class execution.

Not only did the website look great, but everything from the color scheme, branding, domain name, layout and placement of elements was executed perfectly.

I must have visited the site more than 20 times and it was never down, slow to open, or bugging out in anyway.

As the site continued to get traffic Jonathan made minor improvements which added to the experience.

At one point the volume of traffic forced Jonathan to switch over to a different analytics provider. He made the switch quickly and did everything he could to prevent the viral flywheel from slowing down.

It’s one thing to “catch lightning in a bottle” but executing the idea at a world-class level makes a huge difference.

As you’ll read throughout the rest of this post, Jonathan’s decision making was spot on and his choices helped maximize the virality of Outbid.lol.

Simple concept that’s easy to share

Another important factor is that Outbid.lol is a simple idea that anyone can understand and explain to another in a sentence or two.

Complex ideas typically stay in their niches and get adopted very slowly, if ever. Consumer trends that go mega viral are almost always simple concepts.

Easy to use, low barrier to entry, and repeatable

One of the smart decisions Jonathan made was allowing anyone to make a purchase at Outbid.lol. Some buyers promoted their Substack newsletters, X profiles, or even sub-reddits.

Even though the main action was for the top 3 slots on the site, over 1,100 businesses and individuals bought placements on the leaderboard. For just $1 you could be part of the action.

The use of Stripe for easy payment processing was an obvious but powerful choice. Anyone with a credit card or Link account could make a purchase in just a few clicks.

To help maximize revenue, Jonathan allowed businesses to compete for placement over and over again. I saw some businesses spend over $10,000 multiple times trying to stay #1.

Not only was Outbid like a game but the players could play over and over again.

Transparency and real-time reporting

One of the under appreciated factors to Outbid’s success was the clever use of numbers throughout the site, and in Jonathan’s real-time reporting on X.

By being so transparent, passive observers like myself could quickly see that the site was legit and take part in the experience.

The 2 most important numbers on the site: Live count of visitors and the price to claim #1.

The first number, the live count, shows that the site went viral and was getting a ton of attention. By being one of hundreds of people looking at it, you felt you were looking at something special.

The second number, the price to claim #1 on the leaderboard, has a shock effect to most people, especially since it passed 5 figures.

Spending $50 for a listing isn’t a big deal, but $10k+? That’s remarkable.

Since going live, Jonathan has been posting frequent updates on X. Not only did this bring him a ton of new followers, but it was entertaining to occasionally visit his profile to read up on the latest with the site.

It was kind of like the experience of watching a news broadcaster sharing regular updates on a big news story.

Whenever changes were made to the site, Jonathan would post about them.

Leveraging human psychology

The most successful marketers in the world understand human behavior and psychology at a very high level.

I could write a thousand words just on how Outbid.lol taps into our lizard brains but here are just some ways the site achieves its goals through psychology.

• Inclusivity - We all want to be part of trends. Our desire to be part of the crowd is biological and very powerful. Jonathan’s decision to allow people to continue buying slots even as the cost rose was very smart. Hundreds of people spent $1 - $50 each just to be on the board and part of the story.
  

• Ego - We all know that those with money like to show off their money. Businesses buy billboards, have their own conferences and spend money in funny ways even when the ROI is clearly not there. Outbid provided the place for businesses with cash lying around to be #1 on a leaderboard in front of hundreds of thousands of other builders and tech operators. Tapping into our egos is a tactic used by marketers since the very start of commerce.
  

• The “game show effect” - There is a reason game shows are popular. They are not only entertaining but if done well, allow the audience to compete for themselves in their own minds. Outbid was almost fully transparent and updating in near real-time. All around the world indie developers and digital entrepreneurs could watch the action from the comfort of their homes, see a fellow builder making tens of thousands of dollars and try and work out how the hell he did it.

Distribution desperation

The tech world is currently suffering from “distribution desperation”. There is a massive attention supply demand problem and it’s only getting worse.

Since building software has become relatively simple, even for non-technical people, the number of new SaaS, directories, landing pages, marketplaces and other types of websites is exploding.

Most of these new projects are being bootstrapped so there isn’t capital available for paid marketing. This leaves only a few viable growth channels namely social media, search engine optimization (SEO), answer engine optimization (AEO), product-led growth and cold outbound.

Most indie developers aren’t marketers and don’t enjoy it.

I don’t blame them, marketing is hard, takes a lot of consistent work with little to show for it, and most channels are tough to master.

Most tech businesses are desperate for distribution and looking for ways to get more eyeballs on their apps.

Outbid was a new shinny way to get some eyeballs to your app so many businesses jumped at the opportunity.

If you’re going to open a hotdog stand, the best place you can open it is close to a starving crowd.

Jonathan’s Outbid.lol offered increasingly more expensive hotdogs to a very hungry crowd.

I still haven’t seen a post on X showing the ROI of being listed on Outbid but that’s a point for a different newsletter.

Existing audience

For a trend to reach a tipping point it needs fuel to get started.

I believe Jonathan’s existing audience did help get the ball rolling but it’s in no way a critical factor. I think if his audience was 1/10th of its size Outbid would have still gone viral and performed more or less the same as it has.

If I’m not mistaken, Jonathan had around 12k followers on X when he launched outbid.lol which is a sizable audience and it definitely helped get things moving.

Launching on X

The fact that Jonathan launched on X made a big difference.

X is a platform built for virality and is also very popular among the target audience of Outbid. As I previously mentioned, Jonathan’s existing audience definitely helped get the word out and start the viral flywheel spinning on X.

if Jonathan had launched on LinkedIn, or Instagram, instead of X, I probably wouldn’t be writing this post.

“If he can do it, so can I”

Another psychological factor that needs to be listed on it’s own is the fact that Outbid is so simple that anyone with experience with Claude, Cursor, or has the patience to learn vibe-coding could build it.

I estimate the setup costs for the site to be under $30 (not including time to build it).

Within 48 hours of going live, over 100 clones of Outbid had been created and X was flooded by their creators trying their hardest to drive traffic to their leaderboard sites.

It was funny to see some of these cloners bidding on other clone sites trying to drive traffic from one bidding site to another.

I even saw founders running multi-million dollar ARR SaaS jumping on the bandwagon. This shows the powerful psychological need to be part of trends. The vast majority of these clone sites won’t recover their costs and be a waste of time.

My favorite clone? Warmap.

The fact that Outbid’s target audience were fellow builders and the site itself could be built by that audience in a few hours is a very unique situation.

The fact that Jonathan made over 6-figures in 3 days from a site he built in 3 hours is making a lot of builders question a lot of things.

Outbid.lol is not a business, it’s a special situation

I’m probably going to get some hate for this section of the post but bare with me and let me make my case.

Outbid.lol is one of those rare “flash in a pan” type situations that is entertaining to watch while its happening but will inevitably die. Remember Pokémon Go? Same thing. It worked when a large number of people were vested in it but it becomes just a memory once the hype dies down.

Don’t get me wrong, I think Jonathan was smart to try his luck and I’m happy for him that it worked. He not only made a lot of money in a short period of time, but boosted his personal brand to a level that you can’t easily quantify.

If he plays his cards right, the notoriety he has gained from Outbid.lol will bring him far more than the revenue the site will generate.

I think we are so lucky to be living in a world where someone with a laptop can publish a website in 3 hours and make 6-figures in 72 hours but it’s also important to accept these are special situations and not replicable.

The message I want to get across to my fellow builders is that Outbid is a special situation, not a business. If your goal is to build wealth, gain financial freedom, and have the financial resources to make a positive impact in the lives of others, for the love of god, don’t try and clone Outbid.

instead focus on building a scalable, sustainable business that can weather storms and provide value to a market over the long run. Those of you that already have one of those, wish Jonathan well and get back to work.

That’s it for this week, thanks for reading and I’ll see you in the next one.

Justin

PS: If you enjoyed this post, please consider subscribing by entering in your best email below.

Subscribe now

Before starting this newsletter I spent about a decade helping businesses setup, manage, and scale, their business intelligence infrastructure.

This involved setting up popular BI tools like BigQuery, Tableau, dbt, Fivetran and others. Once the tools were in place my focus shifted to writing SQL and building dashboards.

The modern data stack did a fantastic job covering API-based data sources, but it didn’t have a solution for manual datasets.

You see most online businesses have company-specific business data that needs to be maintained manually.

Some examples include:

• List of marketing campaigns and their utms.

• List of influencers and their coupon codes.

• List of SKUs and their historical costs, suppliers, categories and sub-categories.

• The company’s monthly, quarterly and annual growth and financial goals.

• KPI targets per department.

• List of conferences the company will attend over the next 12 months.

The list goes on and on and it gets more complicated the bigger the company gets.

Now here’s the problem.

Most companies don’t have a clear process for storing, managing and centralizing all this important information.

Every department will create their own manual datasets using whichever method they prefer. Some will set up Google sheets, others will use Notion, email threads, or Slack canvases.

As a data consultant the best solution I came up with for this problem was using Google sheets.

The graphic below shows how I’d set it up for my clients. I’ve connect each sheet to Fivetran, a popular ETL solution with a great free plan, and move the data into BigQuery, my data warehouse of choice.

This approach can work but its riddled with issues. Here are just a few:

1. There’s no way to prevent the wrong data type being added to a field. Let’s say I have a sheet which lists marketing expenses. I’d expect one of the fields to hold numbers. Sometimes the person filling in the sheet would add a $ sign along with her value. The underlying data pipeline is expecting numbers only in that field so when it sees a non-number value it breaks the pipeline and the dashboards don’t get fresh data. This issue would occur at least twice a quarter leaving everyone frustrated.
   

2. No backups, central governance, or strict privacy controls.
   

3. No easy way to maintain data freshness. Employees aren’t notified when they forget to update the sheets.

Subscribe now

The solution: Self-hosted Nocodb

After almost a decade dealing with this problem I believe I’ve got the best solution yet and I’ve started rolling it out to my last remaining consulting client.

The solution involves using Nocodb, a self-hosted Airtable-like interface that sits on top of a postgres database.

Nocodb would be hosted on a standard web server (I’m a fan of Render) and connected to a postgresdb instance (ideally on the same host as the web server).

Then I would recommend setting up a subdomain and pointing the server to that address. So for example, data.yourcompany.com. This way it’s easy for employees to remember instead of having to bookmark a custom url from your webhost.

The setup looks like this when it’s done.

In Nocodb you create each of the data sets (tables), and then connect the underlying postgresdb to Fivetran which pipes the data into the warehouse.

Since we are dealing with relatively small datasets, Fivetran’s free plan (500k rows a month) should be sufficient.

The real magic of Nocodb, its interface

What makes Nocodb so much better than Google sheets for managing data is the fact that it’s built specifically for this purpose.

When you set up a table in Nocodb, you set the specific field types. You have 37 field types from your standard single line text, date and number, to JSON, checkbox, barcode, phone number, url and even color.

Behind the scenes Nocodb is communicating in real-time with the underlying postgresdb making sure that whichever data it receives is handled correctly.

This solves the first major issue I previously mentioned with using Google sheets, receiving incorrect data which inevitably breaks the pipeline.

With Nocodb, you can’t add data that doesn’t fit the specific column type.

Nocodb also allows you to control who has access to which tables and what each user can do with that table (view only vs. editor permissions). This is important for compliance and data protection.

API, MCP server, and workflows

Nocodb has a very easy to use API and MCP server which makes it easy to connect your instance to 3rd party tools like n8n, or even to agentic agents like Viktor, Claude, or Cursor.

This is important since it gives you easy ways to set up data freshness automations and messaging to help maintain the data sets.

Nocodb has other powerful features such as workflows, different table views, table operations and much more that I have yet to explore.

Another interesting use case: Update your website without needing code changes

I recently started using Nocodb for managing content on Project Echo’s Open page.

On the page there are three areas which need to be maintained manually, the changelog, milestones and P&L section.

Before using Nocodb, I’d need to open cursor and write a prompt so it would update the code. These three areas were hard coded.

Now that I have Nocodb set up and plugged into the site, I can log into my instance, add or update a row in the corresponding table and the site updates automatically. It’s kind of like using WordPress or Ghost to maintain a site but a more custom approach.

In summary

If your head of data is pulling out his hair because internal datasets are all over the place, breaking pipelines, and not being maintained, forward him this post.

I’ve shared how using Nocodb on a cheap web server and postgresdb can eliminate all the major issues he is facing with the outdated “Google sheet method”.

Nocodb does have it’s own hosted solution but it’s quite limited and expensive to upgrade and support multiple users (it chargers per license). From what I can tell the hosted version gives you 80% of what you need at zero cost (other than hosting).

Does the Nocodb approach solve your manual dataset management problems? Let me know in a comment below. I’d love to write a follow up post in a few months with some case studies.

That’s it for this week, see you next time.

Justin

Share

Welcome to part 5 of my $0 to $10k MRR series.

If you are new to SaaS Decoded, or haven’t yet heard of the $0 to $10k MRR series, you can find the first four parts listed below.

Since my last post in this series I’ve switched my attention from developing Project Echo to marketing the service to potential users.

I have put in on average one deep vibe-coding session each week with a lot of focus on building integrations, and speed improvements.

Here are some of the highlights of the dev work I have done in the last few weeks:

• Built Slack and Notion integrations.

• Built a REST API and MCP server so agents can now read and write to Project Echo.

• Lots of speed improvements and bug fixes.

I’ve also spent time enhancing the Open page by adding new metrics, a profit & loss and tech stack section, and implementing Nocodb in the backend to allow me to add content without Cursor.

Now that I’ve shared some updates, let’s dive into the meat and potatoes of this post; my marketing strategy for taking Project Echo from zero to $10k MRR.

Subscribe now

The marketing strategy to get Project Echo to 10k MRR

At this early stage Project Echo’s marketing strategy boils down to two main pillars, “owner-led growth”, and “product-led growth”.

The “owner-led growth” pillar has 4 main areas of focus:

1. Content - I create content that promotes Project Echo to my personal audience. The open page, this series and my personal YouTube channel will play a big part in this area of focus. The goal is to tell the story, and educate people. Indirectly people will find out about Project Echo and some will choose to sign up.
   

2. Social media - The idea is to get better at social media marketing and grow my audience exponentially on LinkedIn and X. A lot more of my time moving forward will be on audience building and getting better at leveraging social media.
   

3. Networking - This part is very limited but whenever I have the opportunity to network with SaaS founders in real life I will take that opportunity and help share the story behind Project Echo.
   

4. Things that don’t scale - A big part of marketing an early stage SaaS is doing things that don’t scale. I’m going to cover this area in more detail later in the post.

The “owner-led growth” pillar is the most important at this stage in Project Echo’s story because it’s all there is. Since there’s no marketing budget, or team helping me out, I need to convert my time into awareness.

I like to think of it as adding the initial “energy” into a system that can then run itself (and gain speed).

Once enough “energy” has been added, the 2nd pillar, “product-led growth” can start contributing to growth.

In this pillar there are also 4 areas of focus:

1. Flywheels - There are at least 2 product flywheels built into Project Echo at this stage. The first is a usage-based flywheel, and the second is a multi-user flywheel. Both will help get the product in front of more people at an exponential rate once usage, retention and the weekly signup count hit certain levels.
   

2. Integrations - Project Echo already has some integrations but the idea is to support a wide range and have Project Echo listed in many “app marketplaces”. This way the app can leverage the high number of users search for apps. Slack, Notion, Zendesk, Intercom, Jira and Linear are just some of the marketplaces I have my eye on. Before I can start submitting Project Echo to these marketplaces, we first need dozens of active users who are using these integrations.
   

3. Pricing model - Since Project Echo is freemium+, our pricing model should make signing up and trying the service a no brainer. The high value free plan is also aimed at creating some “lock-in” which will help with retention and increased word of mouth. I’m more than happy having a 2- 3% conversion from free to paid as long as the free users help me drive more and more awareness (top of funnel).
   

4. Word of mouth - If I get everything right and provide insane value at the right price, word of mouth will help me get in front of more and more potential customers. The way to influence word of mouth is by providing a remarkable service.

How do things stand today?

Growth so far has been slow. As of now a few hundred individuals have visited the Project Echo site, and in total 15 users have signed up to the service.

Out of those 15, most have finished the onboarding but none have become “activated” or “retained”.

I’m going to publish a dedicated post that will go into detail on how exactly I’m defining user segments. At this stage it’s too early. I first need to strengthen the top of the funnel and get more signups.

The graph below shows the daily active users according to Posthog since I started using it in early July.

The graph below shows unique visitors, pageviews etc according to Plausible which I’ve been using for longer than Posthog. Plausible is only installed on the public pages of the site while Posthog is tracking activity across all pages (public, subdomains and the app itself).

The bottom line is that the top of the funnel is small and needs to grow significantly. It’s been almost two weeks since the last user signed up to the service.

Doing things that don’t scale

At this point I have to get my hands dirty and do a lot of “one off" / unscalable actions to help boost the top of the funnel.

To help me source ideas, I turned to Viktor, my AI agent that works with me in Slack. Below is the exact prompt I sent Viktor.

The output was what you’d expect, a 100+ tasks listed in a dedicated project in Asana. Viktor did a great job in providing clear instructions in the description field of each task.

The plan is to work through this list in the coming week and finish it before the weekend.

I don’t expect every item on the list to have a direct impact on the top of the funnel but at this point it’s more important to take action and drive traffic however I can than focusing on optimization.

Below is the exact list that Viktor created for me. I’m sure some of you are wondering what ideas the AI came up with.

1. Apply to be listed in the Slack App Directory

2. Write a personal JOMO post about what you gave up to build Project Echo

3. Submit to GitHub awesome-product-management lists

4. Submit Project Echo to EU-Startups or regional startup directories

5. Cross-post content from Twitter/X to Threads and Instagram

6. Post a problem-focused LinkedIn post about fragmented feedback channels

7. Reach out to 5 Product Management newsletter writers for a feature

8. Submit Project Echo to SoftwareAdvice directory

9. Engage in startup Discord communities daily for the rest of launch week

10. Optimize your Twitter/X profile bio with Project Echo

11. Write weekly what we shipped tweets throughout launch week

12. Post in Notion and Slack communities about Project Echo integrations

13. Post a transparency tweet showing Project Echo free vs paid features

14. Write a 5 feedback mistakes that kill SaaS growth Twitter thread

15. Post your Project Echo journey on r/Entrepreneur as a lessons learned post

16. Add Project Echo to your email signature

17. Reach out to your SaaS Decoded audience about Project Echo

18. Create a case study showing Project Echo used to manage its own feedback

19. Write a build vs buy Twitter thread about feedback management

20. Reach out to 5 SaaS founder communities for a featured member spotlight

21. Submit Project Echo to MCP server directories and awesome-mcp GitHub repos

22. Submit to startup launch aggregators like Killer Startups and BetaPage

23. Create a teaser page for a future Project Echo referral program

24. Submit your founder story to Starter Story

25. Share Project Echo on Facebook groups for entrepreneurs

26. Reach out to 5 journalists who cover SaaS and startup launches

27. Create a Product Hunt Collection featuring the best tools for SaaS product teams

28. Submit to Pitchwall startup community

29. Create a shareable product feedback quiz or checklist

30. Share Project Echo via a LinkedIn native poll

31. Post in Customer Success Slack communities about Project Echo

32. Write a why we have an unlimited free plan blog post

33. Post in r/CustomerSuccess about managing product feedback

34. Respond to hashtag buildinpublic tweets and share Project Echo context

35. Post in r/webdev about the technical side of building Project Echo

36. Cross-post your LinkedIn article to Medium

37. Share Project Echo with startup accelerator communities

38. Create a Twitter list of SaaS PMs and founders and engage daily

39. Submit to Startup Stash resource directory

40. Write a lessons from building Project Echo post on LinkedIn

41. Submit an application to AppSumo marketplace

42. Do a rate my SaaS post on Indie Hackers or Reddit

43. Post in r/GrowthHacking and other growth-focused subreddits

44. Write a Twitter thread comparing Project Echo free plan to Canny pricing

45. Share Project Echo on the Fediverse and Mastodon

46. Create a short explainer YouTube video for Project Echo

47. Update your LinkedIn Featured section to highlight Project Echo

48. Comment on high-ranking blog posts about feedback management tools

49. Post in the Product Coalition community Slack

50. Write cold emails to 20 small SaaS companies that need feedback management

51. Post in the SaaS Club Slack community

52. Post a before and after visual showing feedback chaos vs Project Echo

53. Set up Trustpilot profile and ask early users for reviews

54. Submit to Futurepedia AI and productivity tool directory

55. Start a Product Hunt Discussion thread to build community presence

56. Add Project Echo to SourceForge directory

57. Answer product management questions on forums that Google indexes

58. Post on Threads.net about your launch

59. Post in LinkedIn Groups for Product Managers

60. Post in Discord communities for SaaS founders and product people

61. Create a free Notion template showing Project Echo in a PM workflow

62. Submit Project Echo to Slant.co as a software alternative

63. Request reviews from your first users on G2 and Capterra

64. Post in the Product-Led Growth community Slack

65. Submit to AI tool directories highlighting the MCP server feature

66. Write a how to collect and manage product feedback blog post

67. Submit to Product Hunt Upcoming page before your main launch

68. Create a LinkedIn company page for Project Echo

69. Post in GrowthHackers community

70. Create a public roadmap for Project Echo using Project Echo itself

71. Use Project Echos own changelog to announce your public launch then share it

72. DM 10 Twitter followers who are SaaS founders with a personalized note

73. Reach out to 5 SaaS podcasts as a potential guest

74. Share Project Echo on Startup School community (YC)

75. Share Project Echo on r/nocode and r/buildinpublic

76. Write and publish a Building in Public week 1 update on Twitter

77. Post in the Mind the Product community Slack

78. Tweet daily helpful tips about product feedback management

79. Submit to Startup Buffer directory

80. Post in r/B2BSaaS subreddit

81. Submit to LaunchingNext startup discovery site

82. Submit to BetaBound for beta tester matching

83. Submit to MicroSaaS directories

84. Submit to Wellfound (AngelList) startup directory

85. Post in Facebook groups for SaaS founders

86. Post a short Loom walkthrough video on LinkedIn and Twitter

87. Reply to LinkedIn posts about product feedback and feature request management

88. Email your personal network a personal launch announcement

89. Find Product Hunt hunters with large followings and ask them to hunt Project Echo

90. Reach out to 5 SaaS newsletters for a feature or mention

91. Post in r/entrepreneur on Reddit

92. Post on Hashnode about your SaaS launch

93. Post on dev.to about building Project Echo

94. Write a Project Echo vs Featurebase comparison page for your website

95. Submit to GetApp (Gartner Digital Markets)

96. Write a Project Echo vs Canny comparison page for your website

97. Post in the Indie Hackers Show IH forum

98. Post in SaaS Slack communities in their launch or products channels

99. Search Twitter/X for feature request and feedback tool queries and reply

100. Search Twitter/X for Canny pricing complaints and respond

101. Write a Twitter/X thread about the problem Project Echo solves

102. Message 20 LinkedIn connections who run SaaS businesses

103. Post a LinkedIn article: Why I built Project Echo

104. Answer product feedback tool questions on Quora

105. Search Reddit for feedback tool threads and reply with Project Echo

106. Post in r/ProductManagement on Reddit

107. Post in r/startups on Reddit

108. Post in r/SaaS on Reddit with your launch story

109. Submit to StackShare

110. Submit to SaaSHub

111. Create a listing on Capterra

112. Create a dedicated listing on G2.com

113. Submit Project Echo to AlternativeTo as a Canny alternative

114. Create a Product Page on Indie Hackers

115. Submit Project Echo to BetaList

116. Post Show HN on Hacker News

117. Submit Project Echo to Product Hunt

It’s going to be a busy week but I’m ready for it. Wish me luck!

That’s it for this week, thanks for reading and I’ll see you in the next one.

Justin

PS: If you enjoyed this post, please click on the share button below and share it to LinkedIn or X. Any help you can offer getting SaaS Decoded in front of more readers is appreciate.

Share

I recently came across an interesting reddit post that highlights a common challenge many early-stage SaaS have to deal with.

In this post I’m going to provide a detailed analysis of this challenge and provide you with the approach, tools and mindset for tackling it.

Let’s jump right in.

Subscribe now

The reddit post: 50 users, some usage, no revenue

My analysis of the post

The first thing to know before we dive in is the nature of the SaaS being discussed.

The SaaS in question, SocialMate, is a social media schedular.

In tools like SocialMate, the user creates a post in the tool and assigns it to a social network (Facebook, LinkedIn, X, etc). Then based on time slots set up per social network, the posts are automatically posted on the user’s behalf.

The whole idea is that instead of you creating content every day and manually posting it, you spend a few hours creating content and the social media schedular posts them on your behalf.

The market leader in this space is Buffer, which I’ve mentioned in a few previous posts. I’ve also covered Postiz which is an AI-focused solution in this space.

Almost every week I’m coming across new solutions in this market. To say it’s become commoditized is an over statement.

The X thread below is an interesting discussion on this topic.

The entrepreneur behind the reddit post shared 6 points; let’s go through each in detail.

1. A little over 50 users, 900+ posts published through the platform.

Reaching 50 users is a nice little milestone and the 900+ posts being published is a decent sample size.

Unfortunately we don’t know the distribution of usage among those users. This is usually more important than totals without much context.

What I’d like to know is the following:

Out of the 50 users, what percentage published at least 1 post?

The answer to this question would help us understand if the SaaS has a user activation issue.

Lets assume only 5 out of the 50 users published at least 1 post. That would clearly indicate that most users don’t experience the “aha” moment that the SaaS provides.

Usage distribution is key in painting a clearer picture of how users engage with your app, and at what frequency. Adding time constraints (“within the first 7 days from signup” for example) makes it even clearer.

As a general rule, things happen quickly in SaaS or they don’t happen at all.

Before a user can publish a post they must first connect a social network to the app.

So before the question above is answered, what we really need to know is, out of the 50 users, what percentage successfully connected at least 1 social network?

I advice SaaS founders to think through user activation, usage, and conversion to paid within the framework of the “core funnel”. Every SaaS needs to know it’s core funnel and track it.

Below is a hyperthetical example of SocialMate’s core funnel.

In my hyperthetical example we can see a few important pieces of information:

1. Only 40% of users successfully connect a social network. This is clearly an onboarding issue.

2. Out of those that connect a social network, 60% publish a post. This isn’t bad but also not great. At least 80% of the users that can experience the “aha” moment should.

3. Since only 12 out of the 50 (24%) actually published a post (experienced the “aha” moment), the sample size is simply too small to understand how the end of the funnel performs. Only 12 people saw value, how many do we expect to pass through to the next step in the funnel?

A tool like Posthog would be great for recording key events which can then be used in an analysis to plot the core funnel’s numbers and conversion rates.

2. Over 1,500 visitors and 3,000+ page views in the last 30 days, all organic, zero ads.

This point sheds some light on the top of the funnel (traffic to the website). 1,500 visitors in 30 days is a nice starting point. I don’t really care about pageviews since it’s irrelevant.

The fact that all the traffic is organic is great, especially since SocialMate is being bootstrapped. There’s no revenue yet so there’s no profit left over for marketing.

If we assume a conservative conversion rate of 2%, we should expect around 30 new signups a month. This conversion rate would be affected by the percentage of new traffic, and the quality of that traffic.

3. Hit a single-day high of about 146 visitors yesterday

This point doesn’t tell us anything. The single-day high might have been a one-off that’s not in the control of the entrepreneur.

What is more interesting is the rolling 28-day sum of new traffic.

Since there is a ton of variance in daily traffic numbers we need a smart way to normalize the data and compare it over time.

I touched on the concept of a “moving window” in an old YouTube video which I’ve embedded below.

You’ll either need to use AI, a tool like Tableau, or do some manual work in Excel to build a rolling sum graph of your new traffic.

If the rolling 28-day sum of new traffic is not going up over time, then you aren’t actually growing your top of funnel. Ignore outliers and focus on growing your 28-day moving sum.

4. Traffic from Google, Bing, DuckDuckGo, and ChatGPT, which has been sending people for a while now.

The fact that traffic is coming from multiple sources is very positive, especially since some traffic is coming from ChatGPT.

Once again, I’d like to see a distribution. Does search count for 95% of traffic, leaving 5% from ChatGPT, or is it a 50/50 split?

There is also one obvious question that arises; why isn’t there traffic from social media? Does the owner not “build in public”?

Search engines are a great source of traffic since it’s usually high intent traffic, and with the right strategy, can be scalable.

At this point in the reddit post, the OP adds the follow:

The honest part: still pre-revenue. Pro is $5 a month, competitors charge $18 to $99 for less, and people are signing up and actually using it. Getting users has been going well. Getting paying users is the next milestone.
My read is that the product is solid and the traffic is real, and the thing I am weakest at is the part after signup, getting someone to see enough value to put down $5. I can build anything, but I would rather stay on building and hand growth to someone who specializes in it.

I have a few comments on this section of the post.

Firstly it’s a mistake to charge $5 a month for a social schedular SaaS. My guess is the entrepreneur behind this SaaS took a look at the market and decided to undercut it by charging just 5 bucks a month.

Unfortunately I wasn’t able to see what is included in the $5 a month plan but if you are going to charge $5, you might as well charge $12 or $15. No one is going to look at a $12 a month price point and say, “oh wow, if only it was $7 cheaper”. The OP even says that the competition charges $18 to $99 so why undercut yourself by over 60%? The OP doesn’t understand price elasticity.

The next point is that the OP mentions:

my read is that the product is solid and the traffic is real, and the thing I am weakest at is the part after signup, getting someone to see enough value to put down $5.

The issue with his statement is that 50 users isn’t a big enough sample size to understand how the end of his funnel is performing. He needs more users and more middle of the funnel data to determine if it’s reasonable to expect users to convert to paid.

His positioning, product bundling, and pricing all impact the free-to-paid conversion rate. The $5 price point may even be hurting that conversion rate.

The OP then posts 2 questions looking for feedback.

5. At 50 users and pre-revenue, would you focus on feedback or just more acquisition?

My answer to this question is “both”. Feedback should be a priority from day 1 for every SaaS and honestly, collecting feedback should never end.

The OP should be analyzing his user data, reaching out to every signup, and trying his hardest to get on video calls with early users to gather feedback.

User acquisition should also be a priority since more users means more opportunities to gather data and objective feedback.

There’s no way around statistics and without a big enough sample size of usage data, and how users progress through the core funnel, you’ll just be guessing.

6. For a $5 tool against $18-$99 incumbents, does the low price help, or does it signal low value? (I feel almost on par, if not better)

As I wrote above, I’m not a fan of charging $5 a month for a social media schedular.

Another way to think about it is if your goal is to get the SaaS to $1,000 in MRR, you’ll need 200 paying users. Converting 200 businesses to paid subscribers isn’t easy, especially for a founder working solo on nights and weekends.

At an ARPU of $12, that 200 number drops to 84 (to have $1k in MRR).

A social media schedular is a B2B SaaS. Businesses are a lot less price sensitive than the average consumer so charging rock bottom prices is usually a mistake.

An exception would be for a “nice to have” SaaS with a very low conversion to paid. I covered such an example in last week’s newsletter.

To answer the OP’s question, yes, a $5 price point does indicate low value.

He would need a lot of social proof and/or word of mouth to counteract the natural perception that his $5 SaaS is proving low value.

A business that will pay $5 will also pay $12. A business that won’t pay $12 but will pay $5 is probably a customer you don’t want anyway.

In summary

If you’re in the early days of your SaaS and not sure why no one is subscribing to your paid plan, you can definitely relate to the reddit post I shared above.

I hope my analysis of the post shed some light on how best to navigate the issue of having no paid subscribers.

The concepts of the core funnel, pricing your SaaS correctly, and understanding if your top of funnel is healthy and growing are all critical in the early days of a SaaS.

I touched on each of these topics in this post and provided you with the methods, tools and mindset for approaching each.

Often the answer to not having any paying users is to keep on going and to be patience. Having enough user data and insight into your core funnel helps paint a picture that will point you in the right direction.

If you like this type of post, please let me know in a comment below. If there is demand for this type of content, I’ll publish more of it.

That’s it for this week. See you next time.

Justin

Share

I forgot to mention in the video that I acquired Meet Slack at acquire.com.

If you’d like to use Meet Slack for your own business, you can get a 50% discount via The Vault.

To learn more about the 6-figure SaaS portfolio I’ve built through acquisitions, check out the post below.

Coffee + Revelation

My 5th SaaS Acquisition: MRR now at $7.8k across 10 apps

Hey friends…

Read more

5 months ago · 2 likes · Justin Butlion

That’s it for this week.

Justin

Subscribe now

Welcome to part 4 of my $0 to $10k MRR series.

If you are new to SaaS Decoded, or haven’t yet heard of the $0 to $10k MRR series, you can find the first three parts listed below.

The Project Echo platform continues to take shape. I managed to dedicate 3 sessions this past week to vibe-coding and I’m really happy with the progress I’ve made.

A lot of the new features and enhancements I built are things I wanted myself as a user of Project Echo.

One example is being able to change the board of a request directly on the requests page.

Before this change you’d have to click on the request, then change the board, and then click back. 4 clicks have been reduced to 2.

You’re welcome to read the latest changelog entry to see the latest updates.

Subscribe now

Radical transparency

One major piece of work I focused on this past week was building the “Open” page for Project Echo.

I decided that since I’m building Project Echo in public, I might as well take it to the max and treat Project Echo as an “open startup”.

If you aren’t familiar with the concept of an “open startup”, spend a few minutes reading up on Buffer. You’ll quickly learn that they take radical transparency to the extreme, even to the point where their entire team’s salaries are made public.

The obvious question is why would a company do such a thing? Why share your private information to the public so your competition knows how your business is performing?

I think the answer comes down to a risk vs. reward equation that companies like Buffer have calculated, and they’ve come to the conclusion that the upside exceeds the downside.

In short, being an “open startup” helps drive more attention since people rarely get to see what’s going on under the covers.

From my standpoint I really have nothing to lose. I’m a solopreneur who is bootstrapping Project Echo so I need to use everything I can to get the word out, especially in the early days.

I’m also a believer that there isn’t enough useful information being shared by operators in general.

So many entrepreneurs are taking advice from gurus and influencers who either never accomplished the success they speak of, or are so far ahead that their advice is hard to connect with.

I want to share the reality of what it takes to build a $10k MRR SaaS from scratch and to do that I’m leaning into radical transparency.

The “open” page of Project Echo will be like a journal sharing the full history of the SaaS.

The “Open” page of Project Echo shows the real, up to date numbers of the SaaS, from the number of workspaces in the database, to the number of active subscribers (none yet). I will be adding more numbers over time such as website traffic, certain conversion rates, churn, LTV and others.

I’m also sharing the changelog entries so anyone can see how the product evolves over time. I’m using Project Echo’s changelog for this purpose (“dogfooding” the product).

The most important section in the page is the milestones section.

In this section I will be recording the exact dates when the SaaS hits certain milestones. This will help my fellow entrepreneurs know how long it takes to reach certain points along the journey.

I’m sure I’ll add some other information to the page as time goes on.

I think showing the actual P&L (profit and loss) statement for the SaaS would be a nice addition. A breakdown of the tech stack and supporting tools will also be published sometime in the future.

What else would you like to see on the page? Let me know in a comment below.

A product demo of Project Echo

Last night I decided to record a product demo of Project Echo.

I wanted a video that shows off the product that I could embed on the homepage (it’s almost always better to show than tell), and also use to market it on social media.

I recorded the video using Loom and edited it (I needed to add some blur effects to hide sensitive user info) using Filmora.

You can find the video below.

The video is shown above the fold on the homepage so visitors can get a sense of what Project Echo does before they sign up. I’m confident the video will help with conversion.

The only issue is the video is too long. At almost 16 minutes, that’s a long product demo. For now I’m using it since having one is better than not but I might record a new one in the future which is shorter.

I think SaaS founders are more likely to sit through a 15 min product demo than the average person, especially if they are researching their options, so I don’t think it’s a huge deal. I also purposefully went with YouTube as the video host to a) save money, and b) to allow people to fast forward easily. It’s also easy to share a YouTube video.

I’m also pushing the video in the welcome email I’ve set up for new users in Intercom.

Since the demo video covers the majority of the platform, I want to encourage new users to watch it since that will help with activation and feature adoption.

Share

The switch to marketing

Now that the Project Echo product is in a decent place, it’s time for me to switch gears to marketing.

As of now less than 10 people have signed up to Project Echo which isn’t enough to help me understand how the onboarding flow performs, or why users aren’t sticking around.

I need to significantly improve this number which means spending time driving relevant traffic to the website.

I need hundreds of signups to create enough data for me to model out the activation rate, conversion to paid, retention and expected usage.

Up until now my marketing efforts have been sporadic and unstructured, that needs to change. I need to build a clear plan and execute on it.

One major change I made this past week was replacing the “join waitlist” button on the homepage with a “sign up” button. I essentially ungated public access to the app and now anyone with an email address, or Google account, can sign up to Project Echo.

I didn’t think there was much of a point in preventing visitors that land on the website from signing up to the service. I need data and adding friction didn’t make sense.

There is a bit of work I can do on improving the onboarding flow but overall it’s not a blocker.

If I had a far larger audience and was confident I could get dozens of SaaS founders to join the waitlist (and then sign up to the closed alpha launch), then it could make sense to close off public access, at least for a few weeks.

Over the next week or two I will be building a marketing plan for Project Echo that I’ll share with you once it’s ready.

The goal now is to move towards clear product-market fit and to understand what’s working, what’s not, and how to turn signups into sticky users.

The immediate milestone is 100 signups.

Wish me luck.

That’s it for this week. Thanks for reading and I’ll see you in the next one.

Justin

Subscribe now

Welcome to part 3 of my $0 to $10k MRR series.

If you are new to SaaS Decoded, or haven’t yet heard of the $0 to $10k MRR series, you can find the first two parts listed below.

Subscribe now

I’ve spent the majority of my working hours the last 2 weeks vibe-coding Project Echo and I’ve had a blast!

I’ve been blown away at how much progress I’ve made on the product, and at my current pace I expect the product to be ready for the beta launch by the beginning of next month.

At this stage I’ve built roughly 90% of the service as I envisioned it on day 1. I’ve already built the most complex features (custom domain support, and integration with users’ own SaaS). Last night I finished another big piece, monetization.

For a deeper look, you are welcome to check out the Project Echo changelog.

The Alpha Launch

In the 2nd week of June I did an informal alpha launch where I started to invite individuals from the waitlist to sign up to the service.

The goal of the “Alpha Launch” is to only add a small number of users to the product to gain some initial feedback, namely on the onboarding flow and core functionality.

At the time of writing this post, a total of 6 individuals have signed up to the alpha version of Project Echo. The feedback has been mixed which is to be expected.

I also had the opportunity recently to give a 30+ minute demo of the product to a close friend of mine. This was helpful to understand how a fresh pair of eyes experiences the product.

Since the platform has matured a lot since the alpha launch, I will be shifting gears to marketing so I can increase the number of users signing up to the service. Ideally I have 25 - 50 users signed up before I open the app to the public.

If you want to be part of the alpha launch, you are invited to sign up to Project Echo here.

The importance of “dogfooding” your product

I’m very fortunate that Project Echo is an app in the product management niche. Being an app for builders makes it easy and very organic to use the product to build the product.

I’m able to “dogfood” Project Echo daily which allows me to easily find bugs and experience the product as a user would.

I’m able to identify points of friction and make micro adjustments which over time make a big difference.

Speed, ease of use, and clear navigation are critical for success in this space.

This process has helped me understand the importance of consistent improvements and a heavy focus on UX.

To be completely honest, there isn’t anything special under hood, but what will make the product stand out is the hundreds of small improvements that I’ll be making over time.

If you’re considering building a SaaS, do your best to choose a niche you know well so you can “dogfood” your own product while you build it. It not only makes the whole experience a lot more enjoyable, but it lowers your risk of failure.

Monetizing Project Echo: A $29 Pro Plan

Part of the work I’ve done this week on Project Echo was to finalize pricing.

I knew I wanted to monetize early since I’m bootstrapping Project Echo and the sooner I can generate some revenue the better.

I covered my high level strategy for getting to $10k MRR in part 2 of this series but I’ve made some minor adjustments to that strategy.

Firstly I did deeper research on my competitors pricing and packaging.

Below are two breakdowns, the first is pricing, and second is what my competitors offer for free compared to what I plan to offer for free.

The way my competitors price their SaaS is quite mixed with some offering a free plan while others don’t. Some have 3 paid plans while others have just two.

As you can see from the table above, most offer their first paid tier for between $15 and $99, with the majority landing in the $29 to $39 range. Upvoty has the cheapest plan at $15 a month but it comes with a lot of limitations.

I want to keep things as simple as possible so I’ve decided to go with just 2 plans, a free plan, which provides the best value on the market, and a paid plan called Pro.

I originally wanted to price my paid plan at $25 but since I’m offering so much value in the free plan, pricing the pro plan at $29 makes more sense. The $4 difference won’t be a factor for those that want what the pro plan offers.

Since I’m against usage-based and seat-based pricing (which is used by Canny and Featurebase), I will need to go with a standard freemium/feature-gated pricing model. The table above shows what I plan to offer in my free plan compared to what my competitors offer.

When it comes to my Pro plan, subscribers will get the features listed below plus some others I have in mind for further down the road.

The only piece I’m still not sure about is integrations.

My competitors all have limits on integrations so it kind of makes sense to do the same thing. I’m leaning towards allowing free users to set up as many integrations as they wish among the basic integrations. Some integrations will be “premium” and only available to paying users.

I’m really happy to have finalized the monetization strategy and implemented it in the product. I still have to “gate” certain features and develop others but the foundation is there and technically users can become subscribers today.

Early considerations when setting up ops

Even though it’s really early days for Project Echo, I wanted to integrate two key tools to help me on the operations side of things.

The first tool is Posthog, a product analytics platform that I’ve actually never used before. In the past I’ve always leaned towards Segment for event tracking, Mixpanel for reporting, and Hotjar for in-app sessions and heatmaps. Posthog covers all these bases and more.

It was also a great opportunity to finally try out the platform which I’ve heard a lot of good things about. So far I’m really impressed. It took just a few minutes to integrate within Project Echo and events are flowing.

I still have a lot of work setting up core events in Posthog but the infrastructure is now in place. Posthog will be a critical piece of my data collection efforts, and help tremendously as I work towards product-market fit. I’m no longer flying blind.

The second tool that I wanted to integrate early is Intercom. I have a lot of experience working with Intercom and its a great platform for providing support, and communicating with users.

What’s really awesome is that you can set up Intercom as a destination in Posthog and send your events to the platform in real-time.

Those events can be used to trigger messages and other interactions in Intercom which will help me do more with the platform.

I’ve already started to experiment with the different message types in Intercom to help my users better understand how to use Project Echo.

Intercom’s messenger widget appears on every page within Project Echo, making it easy for users to send me questions, get help, or just share feedback.

I’ll be using Intercom for my email onboarding flow, and in-app messaging, as well as for all support-related communicating and ticket management.

That’s it for this week friends, thanks for reading and I’ll see you in the next one.

Justin

PS: If you know any SaaS founders, forward them this email, they just might need a feedback management solution like Project Echo.

Share

If you had to give a SaaS founder a genie that granted him 3 wishes, he’d use at least one of those wishes to reduce churn.

Combating churn is one of the toughest things to do in SaaS and it’s a very common cause for the downfall of many startups.

To make matters worse, churn is a complicated, non-standard KPI which many founders don’t truly understand.

If you choose to fight an enemy you don’t understand, you’ll end up losing.

In this post I’m going to share my list of fundamentals for combating churn. By the end of this post you’ll have learnt the following:

• Why you’re measuring churn incorrectly and what to do instead

• The different types of churn

• Why reducing churn is often up to marketing, not product

By the end of this post you’ll know the enemy a lot better.

Definiting churn

The traditional way that churn is measured is the amount of recurring revenue lost divided by the total recurring revenue at the start of the period we are measuring.

Recurring revenue lost would be recurring expansion revenue minus lost recurring revenue.

So for example, lets say at the beginning of January we had $10,000 MRR and by the end of the mouth we’ve lost $1,000 in recurring revenue, our net revenue churn rate would be 10%.

If you look closely at the formula above, you might notice that if your expansion MRR in the period is higher than your churned MRR, then your net MRR churn would be negative.

Negative net churn is the gold standard for SaaS. It means the business is growing its MRR from its existing user base.

We can look at churn in terms of revenue lost, or subscriptions lost. Revenue churn is a lot more relevant since not all customers pay the same amount in MRR.

Why you’re measuring churn incorrectly and what to do instead

Most SaaS businesses look at churn as a fully blended metric. This is fine when reporting numbers to the board, potential investors, or to the company in an all-hands meeting.

When it comes to combating churn, you need to “cut it open” like we’re performing an autopsy.

Let me share an extreme example to demonstrate the importance of segmenting churn.

Let’s go back to our example from early where we had 10% monthly churn.

Assume for a moment that after looking at the lost $1,000 in revenue that you noticed that basically all the cancelations belonged to customers that were on a monthly plan, and based in developing countries.

You dig deeper and notice than 84% of the cancelations are customers who never actually completed the onboarding.

These segmentation analyses tell a very clear story. The vast majority of churn in our hypothetical example belong to subscribers that are from developing countries that did not finish the onboarding.

Often the inverse is the real takeaway: “In January none of our cancelations were subscribers on an annual plan from a developed country; and only 4% belonged to subscribers from a developed country that did finish the onboarding.”

The hard part is to identify the variables which have the largest impact. Most startups simply aren’t collecting enough data to even conduct these types of analyses.

If you aren’t sure where to begin, start by writing down some hypotheses.

Some examples:

• “Subscribers that have done X less than Y times are more likely to churn than those that have done X more than Y times.”
  

• “Subscribers that have less than X employees are more likely to churn that those with more than X employees”.
  

• “Once more than 3 team members have completed action X, the account never churns”.

Some variables worth using in your analysis:

• Total number of key actions (emails sent, tasks created, prompts written, etc)

• Number of active weeks (# of weeks where the user took a key action)

• Size of the subscribers business (startup vs. >7-figures in revenue a year)

• Number of team members actively using the tool

• Geography is almost always a factor. A subscriber from New York is almost always more valuable and less likely to churn than one from central Africa. It’s just the reality.

The different types of churn

Not all churn is created equally which means not all churn can be combated the same way.

There are fundamentally 2 types of churn, Product Churn, and Structural Churn. Churn can either be active or passive.

Product churn is the easiest to understand, it’s churn directly related to the performance of your product and/or company. If the product doesn’t do what its supposed to do, subscribers will cancel.

Same goes if the user experience is poor, support doesn’t do a good job, or the recent price increase is excessive.

Structural churn is churn that happens as a result of the nature of the market.

Gyms have very high structural churn because people struggle to build a habit around going to the gym regularly.

Another good example of structural churn is in the case of SaaS serving markets with high failure rates. A SaaS serving the restaurant industry will have high structural churn because the majority of restaurants fail within their first 3 years.

Structural churn is also the reason most B2C SaaS businesses have far higher churn rates than B2B SaaS businesses.

Product churn is most often active churn. Subscribers will manually cancel their subscriptions, or contact support to do it on their behalf.

Structural churn can be both active and passive.

If the subscriber goes out of business, like in the case of a restaurant in the above example, the credit card will fail to be charged and the subscription will end up being canceled.

Product churn is rarely passive, especially if you’re using a service like Stripe which sends out emails to encourate subscribers to update their credit card before it expires, or to add a new payment method when one does fail.

The solution to high passive product churn is to hire a head of retention who is responsible for following up with subscribers before their subscriptions are canceled as a result of failed payement collection.

If I had to pick one quadrant from the image above where real churn happens, I’d pick active product churn. This is the one area that you have a fighting chance.

Incremental improvements to the product, improved positioning and targeting a healthier market are the best ways to reduce this type of churn.

Why reducing churn is often up to marketing, not product

Notice how in 3 of the 4 quadrants in the image above, the solution includes “find a better market”.

The reason for this is because a lot of churn can be attributed to subscribers who weren’t a great fit for the solution.

Within each market there is a spectrum of “best fit” for any given solution.

Let’s say you build a solution serving lawyers. There are at least 5 ways off the top of my head I can segment that target market.

• Type of law they practice (environmental vs. M&A vs. injury)

• Solo practitioner vs. member of a firm

• Geography (US vs. Europe vs. Rest of world)

• Experience (just starting out vs. 10+ years practicing law)

• Hourly rate ($50 vs. $500)

If my solution is serving all lawyers then I’m inevitably going to serve some better than others. I may find that my solution works best for experienced, American-based laywers with 5+ years of experience practicing M&A law.

The data might show that among that cohort, basically no one ever churns. Now imagine all my future subscribers match these exact characteristics? If the next 100 subscribers I gain all fit these criteria, what would that do to my churn rate?

Churn is a special metric because its truly owned by the entire company. Once the majority of the churn can be classified (product vs. structural, and passive vs. active), we know which department has the bigger responsibility to reduce churn.

In cases where the majority of churn is because of “bad fit”, it’s really on marketing to drive better subscribers to the business.

Consistent surveying of the user base, asking smart questions on support calls, and collecting the right info during signup and onboarding helps a ton to determine the “health” of your subscriber base.

In Summary

Before you can go to war against an enemy, you need to understand that enemy. Combatting churn often takes months of hard work across multiple projects.

Before you can start building a battle plan, you first need to dive deep into your cancelation, usage and demographic data to truly understand your churn.

Only then can you understand where the problems lie and how best to tackle them. You may find that the majority of your churn has nothing to do with your product and that the issue is the market you’re serving.

Start by drawing up a list of hypotheses related to your churn and then start analyzing your data to paint a picture. Use the frameworks I’ve shared in this post to understand the enemy, and then start fighting it.

That’s it for this week friends, thanks for reading and I’ll see you in the next one.

Justin

PS: I’ve made a lot of progress on the alpha version of Project Echo. If you’d like to give the service a try once it’s ready, visit projectecho.io and join the waitlist.

Subscribe now

About 2 weeks ago I published part 1 of my new series, $0 to $10k MRR. In that post I shared the idea for a new SaaS I was building called Project Logbook.

I’m a bit embarrassed to report that I’ve already shut down Project Logbook.

A few days after building the MVP (and sharing it with you in this newsletter), I realize that it was a silly idea.

For some reason the idea behind Project Logbook entered my brain and wouldn’t leave. I jumped the gun on an idea which goes against so many entrepreneurial principles that I believe in.

There are three major issues with Project Logbook that I’ll share with you briefly.

1. No existing market - The idea behind Project Logbook is “innovative” and “unique”. This makes it highly risky and far more difficult to make work compared to building in an existing market.
   

2. Trust - In order for Project Logbook to work, you need to connect all your business tools to the platform. This means sensitive data is being recorded at scale. I would need to build up significant social proof before people would trust me enough to use the service. This just adds to the difficulty factor.
   

3. It’s a nice to have - Is Project Logbook solving a real problem? Not really. No one across my entire audience should any interest in Project Logbook. Once again, when you’re building something brand new there is a high chance there’s no demand for it.

The silving lining is that I identified my mistake early and took the correct steps. Today I pulled the plug and turned off Project Logbook.

The cost: 2 days of my time, about $50 in expenses, and some “egg on my face”.

Introducing Project Echo

So here’s the good news. I’ve already decided on a new SaaS and I’ve made significant progress building the alpha version.

The new SaaS I will be building (and sharing the full journey to $10k MRR in this series) is Project Echo, a user feedback management tool built for SMB and Midmarket SaaS businesses.

Some of you reading this will be saying to yourself, “another feedback solution?”, and the answer is yes (and that’s the exact point). I’m done building “new” things which require market validation. I’m now a “cloner”.

The idea is to completely eliminate the questions, “does this solve a problem?”, and “will people pay for this?” from the equation.

The user feedback tool market is well established with a lot of players. This means there is an existing market and companies are willing to pay for the value these tools provide.

It’s “evergreen” and a growing market (now that it’s really easy to make SaaS).

Instead of jumping head first like with Project Logbook, this time I ran the idea through a checklist.

I’ve always been a fan of this market. I used UserVoice at my previous company over 10 years ago, and more recently I’ve recommended Canny to my SaaS clients.

A few years ago I almost acquired a SaaS operating in this market but unfortunately it didn’t pass my due diligence.

I decided on the name Project Echo simply because I already owned the domain and the term “echo” fits nicely.

So you’re just going to clone Canny / Userjot? How will you differentiate yourself?

In short, yes, but I do have three ways I will differentiate Project Echo from the rest of the solutions in this market.

Differentiator #1 - An extreme free plan

The main differentiator is an extreme free plan. I’m adopting the “Tally playbook” by offering unlimited usage and most features for free.

This strategy will help drive word of mouth and a bigger top of funnel while resulting in a lower conversion to paid and more support. I think this is a good trade because it ties into my advantages.

Like Tally, I will be bootstrapping the SaaS so I need to build leverage wherever possible. I can use product-led growth tactics to build a usage-based flywheel that will market the app to more potential users as the user base grows.

Another big advantage I have is that I don’t need Project Echo to pay my bills. I can take my time and enjoy the process building the platform, brand and everything else that goes into taking a SaaS from $0 to $10k MRR.

I’ve already listed the features that will be included in the free and paid plans on the Project Echo landing page since this is the biggest hook I have at this point.

Project Echo’s paid plan (pro plan) will be $25 a month, or $250 a year, a bit below the market average of $29 a month for the first paid tier.

Unlike my competition, I will have just 2 plans, a free and pro plan.

The biggest draw for the paid plan will be removing the branding, custom user and company properties, and MRR attribution.

Differentiator #2 - Implementing the best from the market

When analyzing the different solutions in this market, you’ll notice slight differences in positioning. Canny, Pendo and UserVoice aim for larger businesses and price accordingly. Userjot, Nolt and most the market, target SMBs and price themselves at around $29 a month.

Most of the players in this space offer the same core features but there are examples of more advanced features which haven’t been widely adopted.

One example is user segmentation and reporting. Canny does a great job offering these features but for some reason they haven’t been widely adopted in the market.

I will take the best features I find across the market and implement my favorite in Project Echo.

Differentiator #3 - My own unique spin

The last way Project Echo will be different from the rest of the market is by doing things my own way. I’m taking a lot of inspiration from Userjot and Canny but I have my own ideas which will go into Project Echo’s development.

A great example is the implementation of card ordering by “drag and drop” in the roadmap section. Userjot doesn’t offer this functionality which is an oversight in my opinion. I want to be able to order the requests by priority within each status column.

I have many ideas for Project Echo but I’ll just share two I’m excited about:

1. MRR attribution - Tie feature requests to existing MRR (through an out-of-the-box Stripe integration) and see how much is at “risk”. Canny does this today to some extent but I believe it can be done better.
   

2. Out-of-the-box user and company properties - Adding custom user and company properties is a paid feature among most solutions in this market. I plan to do the same but offer more out-of-the-box properties which free users can leverage on day 1.

I also have some more risky ideas that I may share at a later stage. I don’t want to get too carried away and it’s important that I’m “dogfeeding” my own product and listening closely to users.

The economics behind Project Echo as a business, and other important considerations

Since the immediate goal is to build Project Echo to $10k MRR, let’s run some numbers.

Assumptions:

• Conversion from free to paid - 2.5% (Tally has a conversion rate of 2%, my market is wealthier so I expect it to be higher than 2% but I’m being conservative).

• % of customers on a monthly plan - 80%

• % of customers on an annual plan - 20%

• Cost of a monthly plan - $25 ($25 MRR)

• Cost of an annual plan - $250 ($20.83 MRR)

• Average MRR per customer - $24.16

• Monthly churn rate - Hard to say. I expect a strong cohort (mature SaaS) that basically never cancel, while many newer SaaS that decide to make the leap to paid that stay 2 - 6 months and count for most of the churn.

So in order to hit $10k MRR, I’ll need +-414 concurrent active subscribers. At a 2.5% conversion from free to paid, that means I’ll need 16,500+ users. This assumes zero churn so the real number is quite a bit higher.

These are all assumptions at this point but I can say for sure that I’ll need to support a lot of users in order to grow Project Echo to 5-figures in monthly recurring revenue.

I know this will take years of hard work.

Risk factors

All business ventures have risk. The main risks I see with Project Echo are:

1. Low ticket will make it hard to scale - Ideally when you’re building B2B SaaS, your ARPU is above $50. Mine is less than half of that which will make it tougher to scale. Project Echo’s infrastructure costs will also be higher than most SaaS as the user base scales because much of the product can be exposed to the public (public portal), not to mention the on-site widget embedded within users’ apps.
   

2. Competitors come in and push prices down - Once more people understand what I’m doing, I’ll inevitably spawn my own copycats. As competition in a market grows (supply), the piece of the pie shrinks for everyone operating in that market. There will be little to stop people coming in and offering similar solutions for an even lower price. The way to combat this is just by being better at the competition. I also believe that $25 a month is close to the realistic bottom for running the business profitably at a sustainable rate.
   

3. Technical risk - This is a real risk that I’m taking seriously. I’ve already built around 40% of the basic platform but I’m leaving the most complex pieces (the on-site widget, user tracking, and integrations), to the end of the alpha build. I’ve also made sure that Cursor and I are building the platform for scale from day 1. I imagine that sooner or later I’ll need to bring in someone with actual devops / scaling experience to help me optimize the infrastructure for increased scale.

Overall the risks I see are minimal and there are no major blockers holding me back from moving forward. The upside is massive and I can now rest easy knowing I’m building a solution in a large market with real demand. Now it’s all about execution, building a world-class product, and getting it in front of tens of thousands of potential customers.

I’ve positioned myself well for learning a ton, sharing an exciting journey, and for building a revenue stream that could change my life.

So what’s the state of the product?

So far I’ve spent about 15 hours vibe-coding Project Echo and I’ve made tramendous progress.

Basic functionality for admins is already in place and at my current pace I expect to have an alpha version ready in under two weeks.

The homepage is live and you are welcome to join the waitlist so you’re the first to know when the app is ready for you to sign up.

I’m already using the product to build the product which is a lot of fun and important for me to go through and enhance the user experience.

The public portal is almost ready and I’ll most likely share it in the next part in this series so you can follow along with the development of Project Echo.

That’s it for this week. Thanks for reading and I’ll see you in the next one.

Justin

Subscribe now

Today I’m launching a new series, $0 to $10k MRR. In this series I will be sharing my journey building a SaaS from scratch to $10,000 in monthly recurring revenue.

In this post I’m going to be sharing the following:

• Why I decided to build this specific SaaS

• How exactly I’m building it

• What the SaaS can do in its current form

• Next steps and how you can help

My goal with this series is to be as transparent as I can and provide a real-world account of what it takes to go from idea to 6-figures in MRR.

Strap in, this is going to be a lot of fun:)

Introducing the SaaS - Project Logbook

Project Logbook tracks the activities you do across your tools so you can analyze, share and build habits around the work you do.

You have complete control over which activities are logged, what is shared to your public profile, and how everything is displayed.

The MVP was launched with the following integrations:

• Asana

• X (formally Twitter)

• Github

• Substack

• Wordpress

I purposefully skipped a lot to get the MVP lean. The list is long but here are some of the things still missing.

• No logo

• Shitty design

• No focus at all on SEO (there’s no sitemap, optimized title and meta tags etc)

• It’s not optimized for sharing on social media

• I’ve integrated Userjot but I’ve spent zero time in the admin console

• No onboarding email flow

• No event tracking (I can’t easily see usage without querying the database)

• Can only sign up via email

• Not optimized for mobile

• Only some activities per integration are supported

Why this SaaS?

The idea behind Project Logbook came to me from a collection of different sources.

Firstly, as a solopreneur, doing work across multiple platforms (X, LinkedIn, Slack, Asana, Gmail, and the list goes on), at the end of the work week it’s difficult to know what exactly was accomplished.

I’ve tried to solve this issue by creating tasks in Asana for every piece of work but the work itself is too fluid and dynamic to have it all in Asana at all time. I don’t want to create extra work to know what work I got done during the week.

Rigging up an agentic agent that sends a daily summary is an option but its a lot of work and limiting.

I believe that in 2026 there is a place for a dedicated platform that can act as a repo for all the work we do. Once all the “work data” is in one place, interesting things can happen.

The next source of inspiration was wip.co, an online community of “makers”.

I like the idea behind wip a lot but I’m not a fan of the execution.

It’s a paid only community (unless if you’re invited?), has little to no automation (from what I can tell), and comes across as outdated.

I don’t mean to hate on wip, it’s no small feat building a thriving community of 3.7k individuals, I just think there is an opportunity to build something better.

There are a number of other reasons I’m a fan of the Project Logbook idea:

• It’s targeted at a large B2B market - solopreneurs, indie developers, and other creatives (the main target market for Project Logbook) are on the lower end of the B2B spectrum, but it’s still B2B. There are millions of potential users and its a growing market.
  

• Simple tech stack and path to MVP - I’ll go into more detail on the exact tech stack I’m using for Project Logbook later in the post but I knew going in that it could be built using a relatively simple tech. I more or less knew before I started what I wanted to include in the alpha version.
  

• I can leverage product-led growth - Project Logbook will be bootstrapped so there won’t really be a marketing budget. The plan is for growth to come through use of the product and word of mouth. Project Logbook will have an extremely generous free plan. I’m using a similar approach to that of Tally (an extreme free plan).
  

• I can accept a low conversion to paid - Since I don’t need to pay the bills from this SaaS and I plan to stay bootstrapped, I can accept a low conversion from free to paid. I will go into a lot more detail in a future post on my monetization plans and pricing strategy. For now just know that I’m going in expecting a conversion from free to paid of less than 2%.
  

• If it doesn’t work, I don’t lose much - Since the setup costs are so low and I’m not building an overly complicated platform, I lose little for giving this a shot. This is what you’d consider an asymetric bet; I lose little if it doesn’t work (mostly time), but if it works I could end up with a very valuable asset.
  

• I don’t need a team - I plan to build Project Logbook without a team. I may hire contracts at certain points but there will be no full-time team members involved on the journey to $10k MRR.
  

• Scratching my own itch + interesting niche - I’ve wanted a solution like Project Logbook for a while. I think its important to “scratch your own itch” and “dogfood” your own product. Project Logbook checks both of those boxes. I’m interested in the whole productivity / data tracking niche which will help me stay engaged and push through the “valley of death” as I work towards product market fit.
  

• It’s an infinite game - Once Project Logbook has been validated by the market and has some traction, it’s a project I can sync my teeth into for years to come. There is something very excited about building my own software platform and turning ideas into tangible tools which provide value to people around the world.

How are you building the SaaS and what’s the tech stack?

I’m building Project Logbook using Cursor on my laptop. I’m prompting the Cursor agent who does the rest.

Here is the tech stack:

• Coding agent - Cursor ($20 a month)

• Version control and code repository - Github

• Cloud host - Render

• Web server - Render ($7 a month)

• Database - Postrgres (hosted on Render, $10 a month)

• Cron - Github Actions

• Domain registrar - Namecheap (the domain cost me $34.98 for the year)

• Email service provider - Postmark (free under 1k emails)

• Web analytics - Plausible (I already have an annual plan so I can add multiple sites, no incremental cost)

• User feedback / feature request management - Userjot (free)

In total the monthly costs to build and run Project Logbook is about $40, not including my time.

The app is built using Node (backend) and Typescript for the front-end. I’m basically building in production which I know is a no-no but it’s working for me for now.

So far 100% of the code has been built using Cursor via prompts.

So what are the next steps?

Project Logbook, in its current form is an “alpha” build. I’m looking for a handful of users to sign up and start using the service so I can start collecting feedback.

I plan to add Gmail as my next integration since that’s where a lot of work is being done.

I will also be adding Google oauth for signing up and logging in. Right now users can only signup via email.

The next big feature on my list is email “summaries”.

Some other dev work I have in mind:

• Goals - Set up activity specific goals and track them in the app (“publish one post every week for the next 10 weeks”, or “Commit code to repo X at least 3 days next week). Goals will also be sharable on the public page.
  

• MCP server - Allow you to connect Claude, Viktor and other AI tools to Project Logbook so you can run your own analyses and trigger workflows outside of Project Logbook.
  

• A lot more integrations - HubSpot, LinkedIn, Slack, Monday.com, and many more.
  

• Monetization - It’s still quite early but at some point I need to integrate Slack and decide on which features will be gated vs. which will remain free.

In the long term I want to rely on user requests and feedback to shape the product roadmap. I want to involve the user base as much as I can to shape the future of the platform.

This is why I’ve integrated Userjot so early.

What if it doesn’t work out?

The deadline for validating Project Logbook is 15th August 2026, approximitely 3 months from now. If by that date there isn’t at least some signs of traction, I’ll shelve the SaaS and move onto the next idea. 3 months is enough time to validate the idea.

Since we now live in a world where a non-developer like myself can use AI to build software, the game has completely changed. It’s now a matter of picking the right idea, serving the right market and playing the numbers game.

If I dedicate myself to building one SaaS every 3 months (4 a year) until I’ve got clear signs of traction (and then double down), it’s just a matter of time until I’ve built a new SaaS to 10k MRR.

Here’s the best part, I can share the journey with you all, learn a ton of new things, and play an infinite asymetric game that has huge financial potential, with little to no risk. I’d be a fool not to at least give it a try.

How can I help?

I know its very early days and Project Logbook is just getting started but the best way you can help me out is by signing up to the service and giving it a try.

If after a day or two you feel it’s not for you, that’s completely fine.

The second best thing you can do is click on the share button below and share this post on your favorite social network.

Share

The more people that follow this journey, the better. I want to spend as much time as I can shaping the product so every extra set of eyes you can help send to Project Logbook, the better.

Enjoy your weekend and I’ll see you in the next one.

Justin

Failure is a great teacher.

Once in a while we should stop and reflect on our failures to remind ourselves of the lessons we learnt the hard way.

In this post I’m going to zoom in on 3 major SaaS-related failures I’ve had in my career.

I’m going to go into some detail on why these SaaS were a failure and what lessons I took from the failures. I want you to learn these lessons so you don’t make the same mistakes I did.

Failure #1 - Bmark

The first failure I’m going to focus on is the very first SaaS I started, Bmark. The idea behind Bmark was to build a smart bookmarking solution that had a social component to it.

Imagine clicking a single button and whatever you bookmarked would be automatically categorized. A music video on YouTube would be categorized as “Music”, a blog post would fall under “Article”, etc.

Instead of sending a link to a friend over email, you could share it with your friends in Bmark.

The closest thing on the market to what I envisioned for Bmark was Pocket which was acquired by Firefox.

I had a grand vision for Bmark but after 2.5 years working on it I had no choice but to shut it down. I had made no revenue, failed to raise outside funding and never reached a critical mass of users. It was a complete failure.

Why did Bmark fail?

There are many reasons Bmark failed.

The biggest reason was my lack of experience. I really had no idea what I was doing and wasted a lot of time. I started Bmark straight out of college with no real startup, or entrepreneurial experience.

For example, I spent months building a business plan instead of just talking with people and trying to build an MVP.

I started Bmark without a technical cofounder (I later added one but I messed that up as well), no real online presence, a small network and no special skills or experience.

The second major reason was Bmark itself. I chose to tackle a “problem” that really wasn’t a problem. Google bookmarks, Pocket and just copy pasting links and sharing them on Facebook, or over email, was good enough for most people.

No one needed a smart bookmarking solution.

I had this idea of implementing content-based ads, like what Taboola and Outbrain do today, to monetize the platform. This idea meant nothing to investors since I had no traction.

Having a plan to make millions is nice and all but if you can’t get from step 0 to step 1, 2 and 3 on the road to step 100, no one cares about step 100.

The final nail in the coffin for Bmark was my failure to raise a seed round of funding after engaging with over 80 potential VCs and angel investors. After 2.5 years, tens of thousands of dollars in debt, and failing to get even intro meetings with investors, I threw in the towl.

The most important lesson I learnt during this time was that if you want to raise VC money, you have to show some level of traction. For investors its all about opportunity and risk mitigation. I did a decent job of showing the potential but I was a super risky bet:)

As a first time founder big ideas only get you so far. It’s all about showing you can execute and that the market wants what you’re selling.

Failure #2 - PulseBanner

The second failure I want to highlight is not a SaaS I built, but rather one I acquired. I acquired Pulsebanner in 2022. It was my first SaaS acquisition.

Pulsebanner is a marketing app that promotes Twitch streamers on X (it was still Twitter in 2022).

When the Twitch streamer went live, Pulsebanner would make changes to the Twitter profile of the streamer, including changing their banner image to show they were live. This drove traffic to the stream which would result in new followers for the streamer.

The first few months after the completion of the acquisition went really well. I ran a successful marketing campaign at the end of 2022 which grew MRR to over $2k.

This was fantastic considering I had spent $48k acquiring the app. At 2.1k MRR, I would bring in over $25k a year and make my money back in less than 3 years.

You can see from the graph above that things turned around from around Feb/Mar 2023, the same time Twitter’s API policies were changed.

In short, X stopped offering their API for free and developers that relied on the API for their apps would be required to pay high fees for access.

Another significant change was the introduction of paid verified accounts. Part of the policy that was introduced meant that any significant change to the profile resulted in the profile becoming “unverified”. In other words, whenever a verified user’s profile picture or banner image would change, that user would become “unverified”.

This meant that Pulsebanner’s whole value proposition, changing your profile automatically to let people know you were live on Twitch, stopped working for people that paid for account verification. Churn obviously followed and there was nothing I could do to stop the bleeding.

Fast forward to today and Pulsebanner is a shell of itself.

To be honest, I mentally checked out of Pulsebanner when these changes were made. I was devastated and didn’t see a path out of the decline. I considered investing in new integrations like Instagram and Bluesky but decided to put my energy and resources into other things.

I also made my second acquisition in June 2023 which has been a very successful.

Coffee + Revelation

The 50k ARR Cash Cow: The numbers behind my most successful micro-SaaS acquisition

Hey friends…

Listen now

9 months ago · 3 likes · 3 comments · Justin Butlion

Why did Pulsebanner fail?

When you build, or acquire a SaaS, there are all types of risks. If your SaaS relies heavily on 3rd party platforms, you have platform risk.

Pulsebanner failed because it relied heavily on specific functionality that was taken away by the 3rd party platform.

The lesson here is to try and avoid platform risk when possible, or at the least try and mitigate the risk. The software world is so interconnected today because of APIs that most apps have some level of platform risk.

There is however a big difference between a SaaS that has a few integrations to a SaaS like Pulsebanner that was essentially a “middleman” between two APIs.

Failure #3 - Feedio

One of the toughest moments I’ve had in my career was shutting down Feedio.

I spent years building Feedio and even though I got further than I did with Bmark, Feedio was ultimately a failure.

The idea for Feedio came to me while I was riding a bus in Tel-Aviv.

I was thinking about James Altucher, an author I really liked. I was thinking about the fact that if I wanted to consume all of Jame’s content, I’d have to subscribe to his blog, YouTube and follow him proactively on Twitter.

I wanted a way to subscribe to James Altucher, the brand, and get sent his content, no matter where it was published. One master subscription to rule them all.

Less than 2 weeks after this bus trip I reached out to a friend of mine who was a talented engineer and convinced him to join me in building Feedio. This was back in 2014.

Both my co-founder and I decided to bootstrap Feedio and spend nights and weekends building the service.

The vision for Feedio was grand. We needed a platform that included content aggregation, email marketing, RSS feed analytics, subscription management and more.

This was the first major issue. Instead of picking a clear pain point and building a solution for it, we tried to build a brand new approach.

That approach meant having to build a complex platform that took years to develop, especially as a “side project”.

Instead of pushing hard for a few months and launching an MVP, we built and built and built. A few years in we did a pivot which meant rewriting a huge amount of the code base. This meant another 6 - 12 months of dev work.

Feedio started to get some traction and the number of users signing up slowly grew but at no point did we feel we had product market fit.

When I became a digital nomad in 2018 work on Feedio slowed down significantly, and after a falling out with my co-founder the service became a “zombie”.

In 2024 I decided to restart Feedio and acquire it outright from my co-founder. I poured thousands of dollars into rebuilding Feedio’s front-end, fixing bugs and relaunched the service in December 2024.

A year later I decided to finally pull the plug on the Feedio dream.

Why did Feedio fail?

Feedio failed because it never really solved a problem.

A few years into building Feedio it hit me that users saw Feedio as an email service for sending digests.

Users were signing up so they could send their blog posts to their subscribers automatically without having to write a newsletter (we did RSS-driven email digests really well). I didn’t want Feedio to be just another email solution since competing in that market is brutal, but this is what the market was telling us.

When I relaunched Feedio in 2024 I went in this direction but I soon realized that in order to compete with Kit, Beehive, Mailchimp and other successful ESPs I would have to go all-in on Feedio and I didn’t want to do that.

It would require years of hard work to build up the brand and gain enough traction to raise funds, or leverage product-led growth to scale. At this stage in my career, I’m not willing to play that high risk game.

In Summary

Failure is a great teacher. In this post I shared 3 personal failures I’ve had building and acquiring SaaS.

I shared these stories to help highlight certain pitfalls that I fell into as an entrepreneur so that you can avoid them.

The first major pitfall is building a solution to a problem that doesn’t exist. This is the single most common reason why SaaS fail.

There is this magical feeling around building something brand new from scratch but it also carries massive risk. Without entrepreneurs that take these kinds of bets we wouldn’t have Uber, Airbnb or OpenAI but for every one of these successes we have thousands of “innovative'“ startups that went no where.

It’s hard enough getting attention for a solution that works, no one will care about your SaaS if it doesn’t provide real value.

The second major lesson from my failures is to keep things simple and move towards important milestones quickly.

It took Tally roughly 6 months to get their first 1k users and hit 1k in monthly recurring revenue (MRR). The Tally founders knew after just a few months they were onto something.

6 months is a long time, even if you’re working weekends. If after 8 months you don’t have clear signs that you’re onto something (sticky users, revenue, word of mouth) then cut your losses and move on. Don’t get stuck in “development hell” like I did. And for the love of god, make speaking with users (and potential users) a priority and do it often.

Failing is fine, just do it quickly so you can learn from it and move onto the next one.

I’ll leave you with one more piece of advice before wrapping up this post: You only need one big win to change your life forever so don’t give up. You are only out of the game when you decide to stop playing. The trick is to learn from the failures and to “get back up on the horse” as quickly as you can.

Good luck!

Justin

PS: If you enjoyed this post, please hit the button below and share this post on LinkedIn (or your favorite social network). We are fast approaching 100 subscribers and any help we can get is appreciated.

PSS: If you haven’t yet, check out the new The Vault mini-site.

Share

You know that feeling you get when you visit a country that’s very different to your own and you can’t stop seeing the differences between the two?

Culture shock is a real thing and I’ve had it non-stop this last week while exploring Fukuoka, the first stop on my 8-week Japan trip.

I’m fascinated with culture and seeing how things are done in Japan has really moved me. It’s truly amazing what can be achieved when you have a high-trust society that behaves in a respectful way to one another.

I’ve got another week in Fukuoka before heading to Hiroshima and then onto Tokyo.

In this edition of Justin’s Field Notes, I’m going to cover the following topics:

• Share some new perks I’ve recently added to The Vault

• A brief summary of April

• First look at some of the fun initiatives I have planned for SaaS Decoded

3 new perks now available in The Vault

EDIT: Soon after publishing this post I sat and built The Vault mini-site. You can now access all the perks in The Vault by visiting, https://vault.saasdecoded.com and logging in with the email you used to subscribe to SaaS Decoded.

I recently added 3 new perks to The Vault, taking the total number of perks to 8. I’ve listed them below.

• Slite (30% off for 3 months)

• Tally (50% off for 3 months)

• Digital Ocean ($200 in credit over 60 days)

• Google Workspace (10% off your first year)

• Mercury ($250, after deposit 10k USD within 90 days)

New additions:

• Viktor ($50 off first subscription)

• Postiz (50% off for 3 months)

• Meet Slack (50% off forever)

Subscribe now

Viktor

Viktor is an agentic AI agent that lives in Slack. I’ve covered Viktor previously in the following posts:

• How to add an AI coworker to your Slack workspace in 5 minutes (+ 12 practical ways to use that coworker)

• How to build an AI-friendly “brain” for your business so you can run insane agentic workflows (6 real-world examples)

I’ve been using Viktor more and more and I really wanted to include it in The Vault. After some back and forth with the Viktor team, a change was made to their affiliate program where new signups from my link get $50 off their subscription.

Postiz

Postiz is a social media scheduling tool that is taking advantage of the agentic AI wave. I started hearing more and more about Postiz on X and decided to give it a try.

I had previously failed to connect Buffer, a popular competitor to Postiz, to Viktor, my agentic agent, which left me frustrated. I managed to connect Postiz to Viktor and I’m now setting up social media posts directly from Slack.

I reached out to Postiz’s founder, Nevo David and worked with him to set up a very generous discount for SaaS Decoded subscribers. SaaS Decoded subscribers can now get 50% off their first 3 months of Postiz. Visit The Vault, log in and click on “Claim” to claim your discount.

Meet Slack

Meet Slack is a simple Slack app which makes it easy to start and join Google Meet sessions over Slack.

I acquired Meet Slack a few years ago and it’s been my most successful acquisition by far.

Coffee + Revelation

The 50k ARR Cash Cow: The numbers behind my most successful micro-SaaS acquisition

Hey friends…

Listen now

9 months ago · 3 likes · 3 comments · Justin Butlion

Meet Slack has a generous 60 day trial but if you decide to continue using it after your trial ends, visit The Vault and claim the perk to get 50% off your subscription for the lifetime of the subscription.

April in review

April was a good month for SaaS Decoded.

In total I published 4 posts:

• Introducing The Vault

• Introducing the Age of the Implementor: Why the majority of tech workers are f*cked (and what they should do about it)

• A deep dive into how Tally grew to $5M ARR in 5 years with a small team and no outside funding

• 40+ resources for bootstrapped SaaS builders

By far my favorite was the deep dive post on Tally’s journey to $5M ARR. I learnt a ton writing that post and had a lot of of fun. I want to write more case study style posts since I think they are very useful for learning tangable lessons.

In terms of growth, SaaS Decoded grew from 81 to 95 subscribers.

As you can see from the screenshot above, growth in April was better than in March but we dealing with very low numbers which isn’t great.

I’ll be making some adjustments this month to my growth strategy which I’m hoping will bare fruit. I’m grateful for every subscriber I gain but the growth of the subscriber base is simply too slow. I have some theories as to why and will be testing them in May.

What’s in the works

I’m working on a few fun initiatives for SaaS Decoded which I plan to share in more detail in the weeks ahead.

• A mini-site for The Vault: As The Vault continues to grow, I need to make it easy to access the perks in the program. A mini-site with email verification should do the trick. EDIT: Soon after publishing this post I sat and built The Vault mini-site. You can find it here.
  

• A new series where I build a SaaS from scratch and take it to $500 MRR: This will be a big project that still requires a ton of thought and execution before I can start writing about it but its a project I’m excited to start.
  

• An in depth post covering Japan’s startup scene: One of my goals for my Japan trip is to meet entrepreneurs and get to know the local tech scene. I’ve started to meet some local operators and I’m looking forward to learning more.
  

• More deep dive case study posts: Covering Tally’s story was a lot of fun and I want to write more similar posts. Moving forward I want to write at least one case study post a month. Who should I cover next?
  

• 100 subscriber milestone post: Once the newsletter hits 100 subscribers I’ll publish a dedicated post to highlight the milestone. I think it’s important to stop occassionally and celebrate certain milestones. It not only helps with motivation but also shares the reality of building a newsletter business. I want to be able to look back and see the story behind what I’ve built.

That’s it for this week’s post.

Thanks for reading and your continued support of SaaS Decoded.

Justin

Subscribe now

The goal of this post is to boost your odds of SaaS success.

The 40+ resources in this post fall into the following categories:

• Educational resources: Learn important lessons for bootstrapping a SaaS business

• Startup programs: Save a fortune on software

• Design resources: Great for the non-designers among us

• Communities: Connect with peers and stay motivated

• Bootstrappers you should follow: Learn from successful bootstrappers

Enjoy!

Educational resources

We are lucky to have access to incredible videos and essays from some of the best SaaS bootstrappers. I’ve listed some of my favorites below.

You will notice a few pieces of content from specific creators such as Rob Walling and Jason Lemkin.

There are only a few high quality content creators in the SaaS space so I’ve done my best to introduce you to the best.

• YouTube: Designing the Ideal Bootstrapped Business with Jason Cohen

• YouTube: I Obsessed Over Product-Market Fit - Here Are the 5 Stages of PMF

• YouTube: How to Perfectly Position Your B2B Brand in 34 Minutes

• YouTube: Bootstrapping to $2B When Everyone Says It’s Impossible with Cloudinary’s CEO

• YouTube: How to Think About Product-Led Growth, Bootstrapping vs VC, and Early Exits with Jason Lemkin

• YouTube: How to build your DREAM SaaS business in 2026

• youTube: Apps so simple you won’t believe they make money

• YouTube: How To Create An MVP (Minimum Viable Product) - STEP BY STEP

• Essay: The Stair Step Method of Bootstrapping

• Essay: How to kickstart and scale a consumer business—Step 4: Find your early adopters by doing things that don’t scale

My recent deep dive post into Tally’s journey to $5M ARR is jam packed with insights for bootstrapping a B2B SaaS.

Startup programs

There are many popular SaaS products which offer significant discounts to early-stage businesses.

Below are some of my favorite startup programs:

• Intercom’s Early Stage Program

• HubSpot for startups

• Zendesk for startups

• AWS for startups

• Stripe for startups

• Notion for startups

• MongoDB for startups

• Mixpanel for startups

Perk Bundles

Get discounts on other popular software products through the perk bundles listed below.

• Lenny’s Product Pass ($30k in value)

• The Vault (by SaaS Decoded)

Design Resources

Design is one of my weaknesses as a founder and hiring a designer can be expensive. Below are some useful resources to help you draft the look and feel of your MVP for cheap.

• Untitled UI: Ultimate Figma UI Kit

• SaaS UI: React-based free component library

• Saaspo: Curated collection of the best SaaS landing pages on the web

• Untitled UI: Icons Pack

• Coolors: Color pallette generator

Communities (peer support and networking)

Building alone is hard. Below is a list of popular communities that provide feedback, and accountability.

• Indie Hackers: The gold standard for bootstrapped, profitable business discussions.

• Product Hunt: Essential for launching and seeing what other makers are building.

• Ramen Club: A community for bootstrapped SaaS founders (great for peer mentorship).

• r/SaaS: High-traffic forum for sharing growth tactics and product feedback.

• r/MicroSaaS: Focused exclusively on smaller, single-person SaaS businesses.

• SaaS Alliance: Networking and workshops for SaaS founders.

• WIP (Work In Progress): A daily check-in community for shipping updates.

• Small Bets: Records plus a vibrant community of bootstrappers.

Bootstrappers worth following

There are hundreds of bootstrapped founders “building in public” on X.

You can create a list in X, add your favorite bootstrappers, and learn what they got right.

I’ve listed some of my favorite bootstrappers below:

• Pieter Levels - Founded many SaaS startups, 100s of thousands in MRR

• Rob Hallam - Founder of multiple SaaS, tens of thousands in MRR

• Rob Walling - Founder of Drip (sold for multiple 7-figures), and MicroConf, angel investor

• Jason Cohen - Founder of 4 companies, 9-figures in ARR

• Staurt Chaney - Founder of Booster SEO, Rivo

• Simon Høiberg - Founder of many SaaS

• Marie Martens - Founder of Tally, $5M ARR

• Daniel Vassallo - Founder of the Small Bets community

That’s it for this week. Thanks for reading and I’ll see you in the next one.

Justin

PS: If you have a friend who is building his first SaaS, do him (and me) a favor and forward him this post.

Share

This was the absolute best timing since I was deep into researching the company and their last major announcement was back in October 2025.

I knew Tally must have been close to $5M ARR because of the exponential rise in their MRR (just look at that graph!), but I couldn’t be sure. I thought I may have to take a guess. Thankfully Marie Martens, Tally’s founder saved me the trouble.

There are many important lessons that can be learnt from Tally’s bootstrapped journey to $5M ARR. My goal with this post is to share as many of those lessons as I can.

Thankfully Tally “builds in public”, and has from day one, so there is a huge amount of information that has been shared by the company’s founders over the years.

I spent over 15 hours going through hundreds of posts on X, multiple podcasts, blog posts, and other content as part of my research into Tally.

The result is this post; a 5,000 word deep dive into how Tally bootstrapped their way to $5M ARR in just 5 years.

The company reached this milestone with a team you could sit around a large dinner table, a lot of very smart business decisions, and incredible patience.

By the time you’re done reading this post you’ll have a complete playbook for building a bootstrapped B2B SaaS business in a large, highly competitive market.

In this post I’ve covered the following topics in detail:

1. How Tally got started and gained their first 1,000 users

2. Tally’s mission, company culture, and team breakdown

3. The genius behind their pricing model, positioning, and product development philosophy

4. How Tally grew to over 1M users and 12,000 customers

5. An analysis of their MRR growth

6. A summary of the key lessons from their journey to $5M ARR

This is a long one so you might want to get a new cup of coffee before diving in.

Enjoy!

Share SaaS Decoded

How Tally got started

Tally was founded by Marie Martens and Filip Minev, two Belgium entrepreneurs, in mid-2020.

Earlier that year they were working on their first startup, HotSpot, a marketplace for travel influencers to connect with hotels. Because of covid, they lost momentum and decided to pivot. It was during lockdown that the couple came up with the idea behind Tally.

Both Marie and Filip had used different form builders throughout their careers but hated the poor design and user experience of Google Forms, and found Typeform, a popular option at the time, as overly expensive.

These clear pain points, and some influence by Notion, helped seed the idea for Tally.

How Tally signed up their first 1,000 users

By September 2020, Marie and Filip had finished building a minimal viable product (MVP) and started sharing it online to gather feedback.

Cold outreach and social selling were the two main channels the founders used to sign up their initial users.

They focused on no-coders, indie-makers and product hunt users who had engaged with similar products to Tally.

Marie covers this topic in more detail in the video below.

The initial users were also invited to a Slack community where they could interact with the founders and continue to share feedback.

The combination of Tally being free, having a powerful usage-based flywheel (more on this later in the post), and the smart decision to prioritize outreach to individuals with their own audiences, meant that Marie and Filip were able to sign up over 1,000 users in just a few short months.

Launching publicly on product hunt 5 months after the MVP went live helped doubled their user base, and provided clear validation that the two founders were onto something.

Tally’s mission, company culture and team structure

The more I dug into Tally’s story the more I came to realize that a huge part of their success lies in their company culture.

Culture is everything and Marie and Filip have done an amazing job in creating a culture that aligns exactly with how they want to build Tally.

Understanding what is needed to succeed and focusing relentlessly on the things that matter

It’s clear that early on in Tally’s story, Marie and Filip understood that there were a few key areas of focus.

At the end of the day it came down to the product.

Since Tally was bootstrapped the company couldn’t afford to compete against the rest of the market through traditional means.

Tally would need to be a world-class product that amazed users so that they would rave about it. This would allow the company to scale through product-led growth organically.

Almost every decision, from starting a Slack community for free users, to their genius pricing model, ties back to this overarching strategy.

Make a world-class product —> Users will be amazed and tell the world about it —> more users sign up —> Some upgrade to a paid plan.

Since the growth strategy was now clear, Marie and Filip would systematically structure the whole company around this central “pillar”.

This meant having to accept:

• Slower growth.

• No full-time employees for the first few years.

• A product-first culture.

• Doing a lot of things that don’t scale.

• Being patient so the flywheel can pick up speed.

• Building the business on their terms meant saying “no” a lot.

• That since there won’t be a lot of revenue for a big team, the product needs to stay simple and be easy to use to keep support costs low.

• It would take years to reach meaningful scale.

All these key decisions were aligned with the main “pillar”, the growth engine, thus keeping the business focused and working constantly towards building more leverage.

The last piece of the puzzle was time and the founders were in no rush.

Tally’s team structure

At the time of writing this post, the Tally team was made up of 11 individuals, including the two co-founders.

Historically Tally either had no full-time employees or a mix of some full-time and some freelance. I wasn’t able to determine which of the 11 today are full-time and which are freelancers.

The Tally organization is very lean, especially for a business making millions a year and with over 1M users.

At $5M ARR, the company has an incredible ARR-to-team member of $454k.

The fact that there are only 3 support reps serving so many users says a lot about the company’s obsessive focus on building an easy-to-use product.

According to Marie, roughly 35 support tickets get generated daily. That’s an incredible number for such a large user base.

For most of the company’s history, Marie was the sole marketer in the company.

The recent additions of a marketing manager and social media manager tells me that Tally understands that in order to accelerate growth, marketing will need to be delegated to a team.

From a product development standpoint, we see that there are 3 full-stack developers. The most recent addition to the dev team was in January 2026.

My guess is that Filip is responsible for R&D while Marie handles support and marketing.

Marie and Filip have always wanted to keep the team small. This lines up with their company culture and patient approach towards scaling.

At the time of writing this post there are no open positions listed on Tally’s careers page.

The genius behind Tally’s positioning, pricing model and development philosophy

One of the areas of business I find the most interesting is how a company chooses to align key variables that matter in its market.

For example, a restaurant can choose to serve a large menu to the “everyman”, or specialize in a few dishes aimed at a richer clientele.

When analyzing Tally, I found that the company had aligned its key variables perfectly for the needs of the founders, and for the market they operate in.

The first thing to point out is that by operating in a very large market, the Tally founders could position themselves almost anywhere, and with enough grit and hard work, run Tally as a nice “lifestyle” business.

By choosing to focus on building a great user experience while offering the most generous free plan on the market, Tally happened to position themselves in a segment of the market which was being underserved.

The mass market had to either use Google Forms for free, and deal with a poor user experience and lack of design, or fork out real money to use TypeForm, SurveyMonkey, or JotForm.

I don’t know if this was part of Marie and Filip’s thinking when they started Tally, but in hindsight it was a very smart decision.

It’s true that Tally is in a competitive market, and they do have a lot more competition today than when they started, but when you zoom into their segment of the market, they are the clear winner.

This positioning wouldn’t work for a VC-backed startup, but its perfect for a bootstrapped, small team that can stay patient long enough to build incredible leverage from a large free user base.

Tally’s pricing model is brilliant and a major competitive advantage

If you visit Tally’s pricing page you’ll immediately notice something a bit different about it compared to most pricing pages.

The emphasis on “free” can’t be missed and they are clearly proud of all the value they provide in their free plan, but take a look at the first two items listed in the block.

Tally offers unlimited forms and unlimited submissions in their free plan!

For comparison, let’s take a quick look at the pricing of two Tally competitors, Jotform and TypeForm.

Both Jotform and TypeForm have strict usage-based limits across their pricing plans. Basically all the major form builders have usage-based limits.

Tally took a completely different approach.

Once again we see an example of aligning variables correctly. Tally could take this drastic approach because they are bootstrapped and playing a very different game to that of the average competitor.

Tally was playing a very long game and could essentially survive with very little revenue for a long time while they waited for their flywheel to gather speed.

What’s even more crazy about Tally’s pricing is that most of the advanced features you’d expect in a paid plan is included in their free plan.

This includes conditional logic, file uploading, integrations with Stripe and Zapier, password protected forms, and many other advanced features.

About 2% of Tally’s free users upgrade to one of their 2 paid plans, Tally Pro or Tally Business.

This is a low conversion rate for a B2B SaaS but it really doesn’t matter. Tally is playing the “big numbers” game.

By having just 2 paid plans, Tally keeps it simple. There is also a clear focus on Tally Pro which has far more features than Tally Business.

Removing the Tally branding, advanced customization, being able to invite the team, and custom domain support are by far the strongest features in the paid plans.

Tally Business has some features which will be important to European enterprises in particular (“control data retention” and “version history”), but overall it’s quite a weak offering when compared to Tally Pro.

I don’t think this is a bad thing overall since Tally is targeting the mass market and Tally Pro provides 95% of what an online business will ever need in a form builder.

I want you to notice that Tally Pro is $29 a month. You might be thinking, “why didn’t Tally offer lower pricing if their whole strategy is based on signing up a lot of users and converting a small percent to paid?”.

As the table above shows, Tally is perfectly priced and dropping their price would only result in less revenue for the company. If anything, they could raise their prices.

The table above is a bit misleading because Tally has no limits on responses, number of forms or team members while the other companies do. It’s not an “apples to apples” comparison which is a good thing for Tally.

Tally Pro is in a different league when compared to the paid plans in the form builder market. This is a strong competitive advantage.

Tally’s product development philosophy

One of the most common issues SaaS companies run into is building features that end up bloating the product and diminishing the user experience.

Tally hasn’t fallen into this trap and I was curious to understand how they avoided it.

During my research I came across an interview with Marie where she mentioned the following:

Tally’s product development philosophy aligns perfectly with the rest of the company culture which means more time spent focusing on what really matters.

There are two key pillars that make up Tally’s product development philosophy.

Pillar #1 - A user-first mindset

Tally’s product development philosophy ties back to their obsession with user feedback and building a world-class product.

Listening to users is a key pillar of their company culture and it shows in almost everything they do.

Below are just some of the ways the company prioritizes the collection of user feedback.

Collecting feedback through NPS surveys

Multiple times a year Tally sends its users using net promoter surveys (NPS).

This allows Tally to collect thousands of data points that can be used to judge their product development efforts since the previous survey.

Each time Tally runs their NPS survey, users can submit text-based feedback as well which helps the company identify patterns. This can help the team focus in on “paper cuts” which hurt the user experience.

All the NPS data is fed into Claude which helps with speeding up analysis.

Feature requests are handled through Userjot

Tally has a dedicated page on their website (https://tally.so/feedback/) for collecting feature requests from users.

Tally uses Userjot which is specifically designed for this purpose.

The company previously used Canny before Userjot but since Canny charges their customers based on the number of users that submit feedback, using Canny no longer made sense for Tally.

Office Hours

A more recent tactic used by Marie and Filip to gather user feedback is “Office Hours”, live group video sessions where users can ask questions, share feedback and engage with Tally’s founders.

Pillar #2 - Highly selective when it comes to product updates

A second pillar of Tally’s product philosophy is being highly selective when it comes to what is changed, or added, to the product.

For years the company focused on improving the experience of free users to help accelerate growth, until switching to building more premium features to help improve conversion from free to paid. Today it’s more of a mix but overall the focus on the user experience of free users has been prioritized.

The company publishes all their product updates in a public changelog which can be seen here - https://tally.so/changelog.

I took a quick look at their updates over the last 24 months and you’ll notice that the number of updates is relatively small but meaningful.

There have only been two updates so far this year (each update usually contains a number of changes and additions to the product).

In the last 6 months the majority of the updates have been “quality of life” enhancements and new integrations.

For Tally it’s all about quality over quantity.

Notice how the conditional logic enhancement that went live in March was one of the most requested features in Tally’s Userjot board.

How Tally grew to over 1 million users

In 5 short years Tally signed up over 1 million users. This is an incredible feat for any SaaS company.

Let’s learn together how Tally grew to such a scale and adds over 100,000 users a month.

You can see in the image above that it took Tally over a year to get their first 10k users. The company added over 600k users in the last 14 months.

Tally’s growth strategy can be boiled down to three main components.

Component #1 - Product-led growth

The usage-based flywheel

As a bootstrapped startup in a large competitive market, Tally’s decision to leverage product-led growth (PLG) is not only the right choice, but probably the single biggest contributor to their success.

Tally has a built in usage-based flywheel which means that each time someone fills out a Tally form they are introduced to the product.

Each year millions of potential users are introduced to Tally simply by users using the product. As more users sign up and use Tally, so do more potential users get exposed to the product.

People are used to seeing ugly forms online so when they first see a Tally form, some of them get curious and click on the “Made with Tally” badge that appears on every form shared by a free Tally account.

Since Tally has the best free plan on the market by a long-shot, the barrier to sign up and try out the service is close to zero.

This simple flywheel is the single biggest contributor to Tally’s user growth.

A world-class, easy to use product leads to a lot of word of mouth

Just look at this snippet from Tally’s $4M MRR milestone announcement.

The more I dug into Tally’s story, the more I realized that this company is obsessively focused on building a great product.

Years and years of focused attention on building an amazing product leads to a raving fan base that promotes your product whenever the opportunity arises.

There’s something special about products which just work and are easy and fun to use.

Tally checks all these boxes and this leads to a lot of word of mouth. I’ve personally recommended Tally to many friends and fellow entrepreneurs over the years.

At scale this results in an army of evangelists marketing the app 24/7.

Component #2 - Community-led growth

From day one, Marie and Filip understood the importance of community, especially for gathering user feedback to help improve the product.

In the early days of Tally, every free user was invited to a Slack community where users could engage directly with the Tally founders.

After the community grew to a few thousand users the decision was made to hide the Slack community from the website and stop inviting new members.

In the video below, Marie goes into some details on the Slack channel and how it helped them gather feedback.

From my research I could also tell that community has become more of a focus for Marie and her marketing team, especially in the last 6 - 12 months.

There is a push for more in-person, community-related activities like meetups.

And more recently the company has been running “Office Hour” sessions where users can connect directly with Marie and Filip to share feedback, and ask questions.

So far there have been 3 “Office Hour” sessions and I assume this is going to become a semi-regular event.

These “Office Hour” sessions is just another great example of “doing things that don’t scale” that help Tally on its mission to provide the best form builder in the world.

By continue to invest in community, Tally is growing their fan base and helping to accelerate word of mouth. Since Tally already has such a loyal following, these efforts will result in outsized returns.

Not every SaaS can use community-led growth to help it scale. These tactics are best used by companies that are good at doing things that don’t scale, and already have a large, loyal fan base. Tally is perfectly positioned to double down on community-led growth to help push it towards $10M ARR.

Component #3 - Building in public

“Building in public” is a popular growth strategy used by indie-builders who share their story and “the grind” on social media as a form of marketing.

Marie and Filip have leveraged “building in public” from the very start of Tally’s journey.

Here are just some of the ways Tally leverages “building in public”:

• Semi-regular blog posts sharing their numbers, areas of focus, goals and other company news.
  

• Frequent updates on social media, especially on X and LinkedIn.
  

• Marie has appeared as a guest on many podcasts where she shares Tally’s numbers, culture and tactics.
  

• Being a speaker at conferences. Marie was spoken at Web Summit and MicroConf.

By being so open about their journey, Marie makes it easier for content creators to tell Tally’s story. I couldn’t have created such a detailed post if it wasn’t for all the time Marie invested in “building in public”.

I can only imagine the number of opportunities she has created for herself to further market Tally by being so transparent over the last 5 years.

Analyzing Tally’s MRR growth

Each time Tally hits an MRR milestone, Marie publishes a post on the company blog. This was a treasure trove of information that allowed me to plot Tally’s history and dig out a ton of important lessons.

In each MRR milestone post, Marie would include a useful graph showing Tally’s MRR growth.

Below is the most recent graph. To tell a more detailed story of Tally’s growth, I’ve added some key milestones to the image.

The first important insight is that Tally monetized early, just a few months after launching their MVP. Tally Pro launched in October 2020.

Bootstrapped startups can’t afford to delay monetization since bills need to be paid.

We can see from the graph above that Tally hit 1k MRR, the first important MRR milestone, in February 2021 about 6 months after launching their MVP.

A product hunt launch happened soon after which led to a nice boost in signups and revenue. According to Marie, their product hunt launch doubled their existing user base.

The next big milestone, 10k MRR was reached 11 months later.

22 months after that the company reached $1M in annual recurring revenue, just over 3 years from starting. The next million came just 14 months later.

We can see from my modified graph that Tally is now adding $1M in ARR in just 6 months. The exponential nature of their growth will result in this number dropping even further as time goes on.

The most incredible data point from the graph is that Marie and Filip went over 3 years without hiring any full-time help.

I couldn’t verify this but I must assume the company at least experimented with freelancers before making this first full-time hire.

To put things in perspective, the company was approaching 250k users by the time they hired their first full-time customer success manager.

By the end of 2025, the company had 12,000 customers.

Since we know the company was at +-$350k MRR, we can deduce that the average revenue per customer of Tally is $29.17, just a bit more than the cost of their monthly Tally Pro plan.

We can deduce further that the vast majority of their customers are paying for Tally Pro on a monthly basis.

The reason the average revenue per customer is higher than the cost of the monthly Tally Pro subscription is because some percent of the customer base is paying for Tally Business which starts at $89 per month. My guess is that it’s less than 10% of their customer base.

The last important question we need to answer when looking at Tally’s MRR growth, is what happened in late Jan of 2025 that caused such a sharp change in Tally’s growth curve?

The most relevant company update around this time is this one - From 2 to $3M ARR: How We Bootstrapped Tally With a Tiny Team.

In that update it’s mentioned that Tally shifted their focus back to building paid features after almost 2 years focused on improving the product for the free user base.

At that time the company also had 4 full-time and 4 freelancers on the team which most likely motivated the decision to shift back to focusing on monetization (since the company had to pay 4 employee salaries).

Another reason for the shift in the curve was Tally being recommended more in AI-driven search results.

ChatGPT became their #1 referral source and has continued as a relevant, and growing marketing channel.

Marie shares more details on this topic in the update post.

A summary of the key lessons from Tally’s journey to $5M ARR

There are many key lessons in the Tally story, especially for bootstrapped SaaS founders that plan to compete in mature, highly competitive markets.

Below I’ve summarized the 7 key lessons I learnt from analyzing Tally’s impressive journey to $5M ARR.

Lesson #1 - Make sure to align the main pillars of the business

The single most important lesson from the Tally story is that life becomes much easier when all the major pillars of the business are in alignment.

There are usually just a few critical decisions that entrepreneurs must get right to stand a chance of building a meaningful business.

Setting the right company culture, choosing a growth engine and pricing model, and setting the right expectations are a few examples.

Tally would be very different today if Marie and Filip went with a different pricing model, decided to raise funding, and set far more aggressive revenue goals.

Instead they’ve built an incredibly profitable business at their own pace under their own terms.

It’s possible to build a successful business in a highly competitive market

Many people would advice against operating in a large market with a lot of competition. I’m sure many people would have advised Marie and Filip against starting a form building business back in 2020.

Tally’s story shows us that it’s possible to compete in a highly competitive online market as long as you get a lot of things right, have incredible patience, and are willing to listen to the market.

Marie and Filip were able to validate their business in about 6 months, identify the most important things to focus on, and then they showed up every day for years.

Tally’s founders made a lot of smart decisions early on and managed to carve themselves a nice piece of the market and dominate it through years of hard work and focus. A lot of entrepreneurs can learn from this lesson.

Lastly on this point, a major advantage of competiting in a large market with a lot of players is that you know there is demand.

The number one reason tech startups fail is they try and solve a problem that either doesn’t exist, or the market won’t pay to have it solved.

Marie and Filip knew from day one that the market for forms was large enough for them to at the very least build a nice “lifestyle” business.

They set the right expectations for themselves and got to work.

Have one clear growth engine

The vast majority of Tally’s users learn about the service by viewing forms shared by Tally users.

Tally identified this usage-based flywheel early on and have stayed focused on improving it by systematically enhancing the user experience one small update at a time.

SaaS founders need to understand where users are going to learn about their products and dedicate a disproportionate amount of resources to build and enhance their primary growth engine once identified.

Bootstrapped founders need to be product obsessed since word of mouth and PLG is their best bet to reach scale without a large marketing budget.

Having a narrow focus is also the best way to outcompete much larger competitors.

It’s possible to reach scale with a small team

Marie and Filip operated Tally for years without any full-time team members.

The company has had a very high ARR per employee for years and will continue to increase this ratio as exponential growth continues in the years to come.

Marie did mention that her biggest mistake while growing Tally was hiring too slowly.

I think Tally is an extreme case, especially over the first 4 years of their history, but their story does show us that it’s possible to reach millions in ARR with a handful of dedicated team members.

In the AI era this will become even more common.

There’s a difference between a product and a platform

Marie makes it very clear that the company views itself as a product, not a platform.

It’s very tempting to build more and more onto your product so that it ends up becoming a platform, or entire ecosystem, but Tally isn’t interested in that.

The company has a clear mission and it can only achieve that mission by staying focused and keeping things simple.

Do things that don’t scale

There are many examples in Tally’s history of the founders doing things that don’t scale.

From cold emailing potential users to help validate the business, to inviting individual users to a Slack community; time and time again the Tally founders have taken deliberate action which is not scalable.

I was quite shocked during my research when I learnt about the relatively new “Office Hours” that Marie and Filip were running. At over $4M ARR the founders were hosting video calls with as few as 20 users at a time.

Which entrepreneurs do that?

Only those that understand that sometimes you need to do things that don’t scale because you just might learn something.

Leverage + time = exponential growth

One of the most incredible data points from the Tally story is that it took the company 3 years to reach $1M ARR and they now add $1M ARR in less than 6 months.

I purposefully included the time it took for Tally to reach certain milestones in the graph above to show how SaaS scales exponentially.

Since Tally’s growth comes from their high leverage, usage-based flywheel, the longer the company is around the faster it grows.

As long as metrics like their free-to-paid conversion rate, churn and pricing stay consistent (or improve), the company will continue to scale faster. The market for forms is so huge that Tally has many years of growth ahead of it.

That’s it for this week. Thanks for reading and I’ll see you in the next one.

Justin

PS: Did you enjoy this post and don’t want to miss my next one?

Go ahead and enter your best email below and click subscribe. I publish one deep researched post every week.

Subscribe now

*Tally is one of 5 SaaS apps that are included in the launch version of The Vault, a free benefits program for SaaS Decoded subscribers.

If you click on the first link to Tally in this post (or here), and decide to upgrade to Tally Pro, you will get 50% off your subscription for the first 3 months. I will earn a small percentage of your spend up to $150.

Subscribe now

If you’ve been living under a rock the last 18 months than you might have missed that tens of thousands of employees have lost their jobs as a result of AI.

I think these mass layoffs are only the beginning and a lot of people smarter than me seem to agree.

I’m going to argue in this post that the fundamental shift in how tech companies operate, as a result of AI tech, will result in the majority of tech workers being forced out of the industry.

I truly believe that most tech workers are f*cked and have less than 24 months to make significant changes to how they earn a living.

I know this sounds very “doomer” but before you’re half way down the page my arguments will be made clear and you’ll be nodding along with me. If you disagree my my thesis, please let me know in the comment section at the end of the post. I’d love to read your counter points.

A fundamental shift in how businesses address tasks

The most basic building block in business is the “task”, an action that needs to be performed that is supposed to help the business make more money.

An easy example to understand is responding to a customer’s support ticket. This is a task that is performed by millions of employees on a daily basis all around the world.

Before the introduction of agentic AI agents, the approach companies took to complete more tasks was clear; they either hired more people, trained their people to do a better job, or a combination of the two.

Now that we live in a world where more and more mundane intellectual-based tasks can be completed by AI, companies are asking a new question, “can this task be handled by AI, or do we need to hire someone?”.

So how does this look in practice?

Introducing the Age of the Implementor

Let’s continue using the example of customer support. A customer support organization in a medium-sized tech company might look something like this:

You have a VP who reports to the CEO or COO and he or she manages 3 support team leads (2 tier 1 and 1 tier 2), an ops manager responsible for tooling, documentation and training, and an analyst who helps pull numbers and prepares reports.

In the age of the implementor, the org chart looks very different:

In the new org chart we’ve dropped 15 humans and replaced them with 3 AI bots, a 79% reduction in headcount.

The first person that is dropped is the analyst.

AI is good enough now that the VP can simply ask an agentic agent to pull numbers from the data warehouse and prepare reports. Once the KPIs, goals and report types are finalized, AI can handle the vast majority of the work.

For any ad-hock, complex data requests, the VP can escalate it to the data team who will have senior analysts on staff.

In the world of agentic AI, there simply isn’t enough day-to-day work to justify having department-based analysts.

The next role that drops off is the junior support rep. A tool like Intercom already has native AI support for drafting replies and responding to chats with a high resolution rate of 67%.

Even if you don’t use a tool like Intercom, setting up an agentic agent that can draft replies to emails is something you can set up in an afternoon.

Since the AI agents can work at scale and solve complex actions almost instantly, the difference in output between AI and humans is difficult to comprehend. Think of it like digging a ditch with a spoon compared to digging one with a mechanical digger.

The reason we still need human senior support reps in our support organization is for reviewing replies drafted by the AI, handling inquiries the AI can’t, or didn’t handle successfully, and for helping to improve the overal level of support provided.

These senior reps will need to handle a lot more ticket volume and we may need to hire a few more if we want to provide strict SLAs, but overall we’ll need far fewer and they can be paid better.

The ops manager has an even more important role to play in the organization since he or she is the “implementor”, the individual responsible for setting up, managing, scaling and optimizing the AI tooling and infrastructure.

This individual is a major force multiplier since without their help and skills, the organization couldn’t implement AI and maintain standards while cutting the workforce by 79%.

In my example the ops manager is the implementor but this doesn’t have to be the case. It could be a senior support rep who has the necessary skills to take on the job.

What can be said for sure is that everyone in the new organization needs to be at the bare minimum “AI aware”. This means that each employee understands what AI is, how it works, how to use it, and how it helps the business accomplish it’s goals.

In the new world of AI driven task completion, you are either an implementor (“force multiplier and extremely high value to the business”), or you are “AI aware”, and still play a role. Everyone else is redundant, or soon will be.

Being “AI aware” will only protect you as long as you perform tasks AI can’t, or hasn’t learnt how to just yet.

So why are the majority of tech workers screwed?

There are four main reasons I believe most tech workers are going to be forced to make a significant change to how they earn a living in the next 24 months:

1. Most tech workers are performing tasks which AI either can already, or soon will be able to perform far better than them at a fraction of the cost. This will force these individuals to either pivot into different roles, switch industries, or become entrepreneurs.
   

2. Following on from the above point, most employees go to work to perform their tasks to collect a paycheck. From my experience most people don’t have a growth mindset and push back against having to learn new skills.
   

3. You can’t simply teach someone to become an “implementor”. The kinds of people that become “implementors” have personality traits, attitudes and a culture which you can’t refine in people. “Implementors” are curious, intelligent, like to learn new things, natural problem solvers and care about efficiency.
   

4. AI is simply too efficient. The number of humans organizations will need will continue to shrink. You only need so many “implementors”. Some businesses will outsource AI implementation and adoption to specialized agencies that can help many companies in parallel thus reducing the need to have your own “implementors”. Some companies will form an internal implementation team that is responsible for AI across the entire organization.

If you take into account these 4 factors, I think it’s clear that the vast majority of tech employees are f*cked.

So what’s the solution if there is one?

How to protect yourself in the world of agentic AI?

If you’re working in tech and concerned that AI is coming to take your job then you’re already a head of many who still have their heads in the sand. AI is coming for most jobs and we’re already seeing more and more startups reaching large valuations with smaller and smaller teams.

With all that being said, there are a few things you can do to improve your chances of riding out the disruption and keeping your paycheck.

Become an implementor

If you’re a curious person who likes to learn new things and enjoy problem solving then you’re probably a good fit to become an AI implementor.

If you’re working for a company which hasn’t yet started implementing AI then this is your chance to show management that you’re the right person to help.

To become an implementor of AI, you need to start learning AI, the tooling, how everything connects together, and to start experimenting and building a plan for how your department can use AI to scale.

My post below is a good place to learn some of the basics.

By becoming the person in your organization that helps the company leverage AI to improve performance, you will have leverage and a lot harder to replace.

Once AI is good enough to implement itself throughout a business, even implementors will be out of a job. For now we need humans to implement, scale and manage AI systems.

Become an artist, entrepreneur, or change industries

If you’re not willing to learn new skills and “become one with AI” then you have 3 other choices.

You can either start your own business (not easy to do and requires learning a lot of new skills), change industries, or become an artist.

Changing industries is the easiest option in my opinion. There are industries which have not yet been heavily affected by AI and many tech workers will want to continue earning a paycheck with minimal disruption.

A junior analyst who just lost their job at Amazon could be hired by a shipping company which is still using legacy systems.

The problem is this is a losing battle since AI is spreading across all industries and it’s just a matter of time until certain jobs are wiped out completely.

It might take a few years but the analyst at the shipping company will end up in the same place as before, and have even fewer options available to him or her.

Many will choose to start their own thing and/or become artists (I include YouTuber’s, streamers, writers, etc in this category).

It’s never been easier to create things online and the number of individual creators making a living online is growing all the time.

I also predict “vibe-coding” will become more and more attractive, especially to junior and mid-level programmers who are replaced similarly to the junior support reps shown in my example above.

Ironically, these “vibe-coders” will use AI to create massive leverage themselves resulting in an explosion in single-founder / small team tech companies operating at very high margins.

In Summary

We’re all living through the AI revolution and it’s fundamentally changing how businesses operate. One of the main “victims” of this revolution is the average tech employee.

I’ve argued in this post that the vast majority of tech employees are f*cked and have less than 24 months to make significant changes to how they earn a living.

Employees that embrace AI, learn how it works and can help a business scale or efficiently have a chance of becoming “implementors”. These individuals are a force multiplier and become very valuable to their employer.

Those that don’t become implementors will need to change their role, industry, become entrepreneurs or earn a living as an artist.

Mass layoffs will continue and I’m pessimistic that most of those that lose their jobs will end up gaining new skills, finding a spot in a new industry, or succeed in making a living as an entrepreneur or artist.

I think universal basic income will become a requirement in some form or another, especially in the west.

How do you see things playing out? Let me know in the comments below.

If you enjoyed this post and want to get next post in your inbox, enter your best email below.

Subscribe now

Thanks for reading and I’ll see you in the next one.

Justin

Hey friends,

I’m excited to announce the launch of The Vault, a curated benefits program for SaaS Decoded subscribers.

My vision for SaaS Decoded is to help as many SaaS founders and operators as possible.

The Vault is another way I can do that, by offering you discounts on some of the best software products I’ve used personally.

Each month I will be adding new tools and other exclusive perks to The Vault and sharing them with you in the weekly newsletter.

Below is a list of the perks included in the launch version of The Vault:

• Slite (30% off for 3 months)

• Tally (50% off their subscription for 3 months)

• Digital Ocean ($200 in credit over 60 days)

• Google Workspace (10% off your first year) [Use the promo code X7MUCCJ3WPNQYQU]

• Mercury ($250, after deposit 10k USD within 90 days)

To take advantage of the perks, simply click on the links above, sign up to the services and you’ll get the benefit listed.

I vouch for each of the services above and have used each of them for years across multiple businesses. I’ve recommended them to friends and fellow entrepreneurs many times.

If you have any questions on The Vault, check out the FAQ on it’s dedicated page at saasdecoded.com.

Thanks for your ongoing support of SaaS Decoded. I’m excited to continue building out the business and supporting more SaaS operators.

Enjoy the perks and I’ll see you in the next one.

Justin

Share

*In order to keep the perks of The Vault exclusive to subscribers of SaaS Decoded, I ask that you don’t share the links above on social media, your website, etc.

**I suggest that you don’t delete this email so you can come back and claim the perks at a later stage. I plan to remove the links above from the published post at saasdecoded.com so I can keep the perks exclusive to subscribers.

Subscribe now

Hey friends,

In this week’s post I’m going to teach you how to build an AI-friendly “brain” for your business that AI agents can use it to make you more money.

If you’re motivated to use your company’s unique knowledge and AI in meaningful ways, this guide is just what you need.

By the end of the post, you’ll have learnt the following:

1. Why you need a “brain” for your startup in the AI era.

2. What is an MCP server and why should I care?

3. What to look for in an internal knowledge base solution.

4. How Slite, Notion, Confluence, and Guru stack up against each other.

5. How to connect a knowledge base to AI tools, specifically Viktor and n8n.

6. How to set up 6 AI workflows that use your company’s unique knowledge.

If you make it to the end of this post, you’ll also know the exact steps, prompts and data you need to set up these 6 AI workflows:

1. Send a list every Monday of software that’s up for renewal that week (save 💵)

2. Speed up new employee onboarding (save 🕝 & make 💵)

3. Remind team members of non-work days in the coming week (nice to have for employees 🎉)

4. Use AI to pull answers to frequently asked questions and draft replies (save 🕝 & 💵)

5. Once a month share a summary of last month’s bank statement (save 💵)

6. Once a week get a content digest of relevant industry news shared with the team in Slack (make & save 💵)

This is long post (over 4,500 words) written as a step-by-step guide for SaaS businesses that don’t have a knowledge base and want to go from zero to AI-driven workflows using their unique knowledge.

If you already use any of the 4 knowledge base solutions I cover in this post (or an AI-friendly alternative), feel free to skip straight to step #3 (about a 3rd of the way down).

If today you don’t have an internal knowledge base in your business, let’s start off by answering the most obvious question.

Why does my startup need a “brain” and what the hell is an MCP server?

We are now living in the AI era but most SaaS startups are either not using AI at all, or using it to create new things.

Claude, Cursor, Lovable and many other agentic AI tools are exploding in popularity for a good reason; they are incredibly powerful tools for creating new things.

Where businesses are falling short is in leveraging their unique knowledge and AI in meaningful ways.

AI needs data to perform its “magic”. The one source of data the AI tools you use don’t have is your own. Therefore, until the AI tools you use have access to a central knowledge base that houses your unique data, you will be missing value.

Once you have your company’s unique knowledge in an AI-friendly knowledge base, we can connect it to AI tools and run workflows that leverage that data.

Getting to this end point is a 4 step process:

• Step #1 - Adopt an AI-friendly knowledge base

• Step #2 - Add your unique knowledge to your knowledge base

• Step #3 - Connect your knowledge base’s MCP server to your AI tools

• Step #4 - Set up AI-driven workflows

The way AI agents communicate with 3rd party tools, such as knowledge base tools like Notion, Slite and Confluence, is done via APIs connected to an MCP server.

MCP, or Model Context Protocol, is often called the “USB-C for AI”. Just as USB-C replaced dozens of different charging cables with one standard, MCP allows AI agents to connect to any data source without developers having to write custom code for every single integration.

If you’d like a deeper breakdown of what an MCP server is and how AI works with it, the video below does a good job.

So if we are going to implement a “brain” in our startup, we need a knowledge base solution which has MCP server support, thus making it “AI-friendly”.

Step #1: Adopt an AI-friendly knowledge base

For this post I researched 4 popular knowledge base tools, Notion, Slite, Confluence and Guru.

I’ve worked with all 4 throughout my career and been using Slite on a weekly basis for the past few years.

All 4 solutions have MCP server support which was a key consideration. Other considerations are price, the positioning of the solution (SMB vs. Enterprise), and if we want a dedicated knowledge base tool, or something more robust.

Notion

Notion is a multi-billion dollar company with a cult following that is a very popular knowledge base tool for early stage businesses.

I’ve personally never used Notion as a company knowledge base but have worked with businesses that have and it’s a great option.

It’s affordable, highly flexible, supports teams of all sizes, and has become a lot more AI-focused over the last 12 months.

Where I feel Notion falls a bit short is on focus.

Notion isn’t a pure knowledge base solution but rather a collection of tools that can work together. It’s more like an online “operating system” for your business where project management, task to-dos, documentation, calendars and databases live.

Notion is now leaning heavily into AI automation, bots and agentic workflows which may give it an edge over some of the other tools on the list; but then again it could also waterdown its strengths as a low-friction knowledge base.

Slite

Slite is an internal knowledge base tool I’ve used for my online businesses the last few years.

At first glance you’ll notice a lot of similarities between Slite and Notion but you quickly see Slite’s value as being solely focused on helping online businesses store and retrieve their unique knowledge.

What makes Slite special is its intuitive approach and extremely low friction user experience.

Commenting, audit logs, extremely useful embed options, a smart folder structure, and public sharing of documents are just some of the great benefits the solution provides.

Confluence

Confluence by Atlassian has been around for over 20 years. It launched back in 2004 as an internal wiki and team collaboration platform.

I used Confluence at my previous job about 10 years ago and back then it was a great solution, especially for creating product requirement documents (PRDs).

Confluence is a more enterprise focused (notice the team size option on their pricing page) knowledge base solution compared to Notion and Slite.

Jira is another product of Atlassian which is very popular among R&D teams; so if you’re already using Jira, you might want to take a closer look at Confluence and see if it is a good fit for your business.

Guru

Out of 4 solutions I looked at for this post, Guru is the least known.

I remember being very impressed with Guru when I used it in my previous company since it had a very powerful chrome extension which made it easy to retrieve info from the knowledge base.

Since then Guru has moved up market becoming enterprise focused and positioning itself as a multi-product company. The company has leaned fully into AI.

At $30 per month per seat, Guru is also the most expensive of the 4 solutions on my list.

If you’re running a larger organization and doing an evaluation of the knowledge base market, then I’d suggest reaching out to Guru to request a demo.

The winner: Slite

Out of the 4 solutions I covered, Slite would be my knowledge base of choice for most online startups.

It’s affordability, ease of use, MCP server support, and focused approach check the boxes which I consider the most important when choosing a knowledge base.

For the remainder of this post I’m going to show you how to leverage Slite to achieve our end goal.

With that being said, the steps I’ll walk you through would also apply to any of the other knowledge base solutions I’ve covered.

What’s important is understanding the key concepts and use cases and then to apply them in whichever knowledge base you choose.

Step #2: Add your unique knowledge to your knowledge base

Every online business has different information that it should store in it’s “brain”.

A helpful rule that I’ve used for my own businesses is to save in the knowledge base any piece of information that you believe will need to be retrieved at least once in the next 12 months. When in doubt, add it.

This includes standard operating procedures, brand kits, tax returns, company specific info like tax ids, useful analyses, onboarding and offboarding checklists, user research, and the list goes on.

Organize everything by department and don’t be shy of using sub-folders.

Below are 15 examples of information that could go into your knowledge base.

Click on any of the items in the list below to find a useful template you can quickly add to your Slite account.

1. New Employee Onboarding Checklist [by role]

2. Employee Handbook

3. Employee Registry

4. Standard Operating Procedures (SOPs) [By department / role]

5. Investor Update

6. Project Budget Template

7. OKRs

8. Brand Kit / Style Guides

9. Customer Avatar Breakdown Document

10. Customer / User Research

11. Job Description Template

12. Product Requirement Documents

13. Product Roadmap Planning

14. Product Release Notes

15. Marketing Campaign Planning Documents

Tips for optimizing, scaling and managing your knowledge base

Assign a dedicated owner

In the early days this should be the CEO, but at scale it should fall under the COO. An ops manager should manage the day-to-day responsibilities.

Invite everyone to the knowledge base

The whole idea of a knowledge base is to centralize, organize and reduce the friction of retrieval of company-specific knowledge. Everyone in the company should have access to the knowledge base.

Slite, and the rest of the knowledge base tools I’ve covered, have adequate controls for limiting who can see what.

A knowledge base only works if it is maintained

Managers in the company should be responsible for maintaining their teams SOPs, checklists and other documents in the knowledge base.

Introduce company wide policies for conducting quarterly reviews of the documentation and make it clear to management that maintaining the knowledge base is expected and a requirement of their roles in the company.

Teach management exactly how to use the knowledge base

Whoever in the company is responsible for the knowledge base should conduct training sessions to teach management the “ins and outs” of the knowledge base. The deeper the training the better.

Use examples throughout the training and record the sessions. Save the records in the knowledge base.

Training videos can be shared to new employees as part of their onboarding.

Take advantage of the full capabilities of the knowledge base

Solutions like Slite have hundreds of minor features which provide incredible flexibility and power to users. Encourage team members to get to know the solution thoroughly and include useful examples in the training sessions.

Have a “rule book” for the knowledge base

The owner of the knowledge base should be responsible for maintaining a set of rules for how to use the knowledge base. This includes formatting, folder structure, what should and shouldn’t be added, how change requests should work, etc. The idea is to maintain consistency as much as possible and encourage order.

Step #3: Connect your knowledge base’s MCP server to your AI tools

Now that you’ve got your unique knowlege in one place, it’s time to connect your knowledge base to your AI tools so we can start building some workflows.

How to connect Slite’s MCP server to Viktor

The first connection we are going to set up is Slite’s MCP server to Viktor, a Slack-based agentic AI agent.

If you aren’t familiar with Viktor, check out my previous post below on how to add an AI agent to Slack. I go into detail on how Viktor works and how it compares to Runbear, another popular Slack-based AI agent.

If you don’t use Slack in your business, don’t worry, the use cases I’ll share later could still be set up using other AI tools that aren’t native to Slack.

To connect Slite’s MCP server to Viktor, you first need to log into Viktor, click on “Integrations” in the left hand menu and then on “Add Custom MCP” in the top right corner.

In the popup that appears you’ll need to enter “https://api.slite.com/mcp” in the Server URL field.

After clicking on “Connect”, you’ll need to log into Slite, pick your workspace and authenticate the connection. This takes a few clicks and less than 1 minute.

Once connected, you’ll see the custom MCP server listed in Viktor as a connected integration.

Congrats, you’ve now connected your knowledge base to an agentic AI agent.

One thing that can be a bit confusing is that it’s possible to connect Viktor directly to Slite using a standard API integration via Viktor’s Pipedream partnership. I’ve tested this integration and I’d skip it. The MCP connection is far more powerful.

To confirm that the integration is working, you can ask Viktor to retrieve a document and share it in Slack.

How to connect Slite’s MCP server to n8n

If you’re not yet a fan of adding an agentic AI agent to Slack then you might want to consider n8n.

To connect Slite’s MCP server to n8n you’ll first need to add n8n’s MCP Client node to your workflow.

Once you’ve added the node to your workflow, you’ll need to add Slite’s MCP server details and authenticate, just like we did when setting up the connection with Viktor.

You’ll want to enter “https://api.slite.com/mcp” in the MCP Endpoint URL field and use MCP OAuth2 as the authentication method.

Next you’ll want to add “credentials” which is an easy process once you’ve followed the steps above. Click on “Create Credentials” and follow the steps.

Once you’ve successfully connected n8n to your Slite’s MCP server, you can go ahead and use the “search-notes” tool, run a search and confirm that n8n can access the MCP server.

Take note in the screenshot above that I ran a search for “Non-work days 2026” which is the title of a document in my Slite. The result of the search appears on the right.

I can now use the id of the document that was returned in the search, and fetch the contents of that document using the “get-note” tool.

n8n is a powerful automation tool but it does require understanding how APIs work, data structures, logical progression and other technical concepts to really master.

If you’re new to n8n then I suggest watching the useful beginners guide below.

Step #4: Set up AI-driven workflows

So far we’ve laid the foundation, it’s now time to start using that foundation to help improve the business’s bottom line. It’s time to build some AI-driven workflows.

The following 6 workflows were all created using Slite and Viktor.

For each, I’ve included the exact prompts I used to trigger the workflows, and in some cases, turn them into recurring tasks for Viktor.

AI workflow #1: Software renewal weekly reminder

How often do you lose track of the software tools you pay for annually? It’s frustrating when a tool you stopped using gets renewed automatically and you have to chase down the company for a refund.

The first automation I want to teach you solves this issue by getting a weekly reminder of upcoming renewals shared directly with your CFO in Slack.

The first step in the process is to create a software expense registry in Slite.

Create a dedicated document in Slite titled, “Software Expense Registry”, create a table and start filling in the details.

In my example, I used the following columns:

• Software - The name of the software (text field type)

• Billing Frequency - Either Monthly or Annual (single select field type)

• Renewal Date (Annual) - The renewal date of the software. Only relevant for software which you pay for annually (date field type)

• Is License Based? - Either “Yes” or “No” (single select field type)

• Notes - Helpful additional info on the software (text field type)

This document should be maintained by your head of IT along with your bookkeeper / administrative assistant.

Once the document was in place, I sent Viktor the following message in Slack:

“@viktor Look in the table titled, Software Expense Registry, in the Slite MCP server and return a list of software with an annual billing frequency which have a renewal date anytime between today and ten days from now. List out these software in a bulleted list, ordered by renewal data in ascending order, provide their renewal dates and any notes.”

Below is Viktor’s reply.

To turn this into a weekly task for Viktor, I sent the following:

“@Viktor Please turn the above request into a weekly recurring task. I want you to fetch me the information I requested every Monday morning at 9am UTC time.”

That was enough to set up the automation on Viktor’s backend.

AI workflow #2: New employee onboarding to-do list

When a new employee joins the business there are a lot of tasks that need to be checked off before the employee is ready to start working.

It can be helpful to share that list directly in Slack with the employee to help speed up the process.

The first step is to create a dedicated document in Slite with the onboarding to-do list for new employees.

Below is the prompt I sent to Viktor in Slack:

“@Viktor Please share the new employee to-do list as a new message in this channel. Share it as a bulleted list in the same order it appears in the document in Slite. Use the Slite MCP server to find the document.”

And below is the outcome of the message to Viktor.

AI workflow #3: Non-work days reminder

As more and more companies employ fully remote, global teams, not everyone in the company is always aware of all the non-work days scattered throughout the year.

By creating a list of the non-work days in Slite, you can create a simple automation in Slack to let everyone know whenever there is an upcoming non-work day.

Below is the prompt I sent Viktor in Slack:

“@Viktor Look in the table in the document titled, “Non-work days 2026” in Slite using the Slite MCP server and share any holidays which are happening this week. List the occassion, the date, and the day of the week the holiday falls on. Share as a new message in the channel, not as a reply to this message.”

And below is what Viktor returned:

To turn this into a recurring task, I wrote the following to Viktor:

“@Viktor Turn the above request into a recurring weekly task. Run the request on Monday at 4:15AM UTC time. If there are no holidays listed in the table for the date range you checked, don’t send a message.”

Once again, Viktor took my message in Slack and added a recurring task to the list of “scheduled tasks” in my account.

*I purposefully changed the date of President’s day in my table to show you how the task would be completed by Viktor.

AI workflow #4: Retrieve support FAQ responses

I own a number of SaaS products and get the occassional support ticket. I usually respond to each from scratch but this is far from optimal. I’ve decided to start using AI to help me provide better support, and to save me time.

To take advantage of this workflow you first need to create a FAQ document in Slite which addresses your most common support questions.

Once the document is in place, you can use Viktor to pull relevant info from the knowledge base and draft responses.

“@Viktor Below is an email I got from a user of Meet Slack:

"Hi, I need help authenticating my Google account"

Check the support FAQ document for Meet Slack in Slite's MCP server, find the relevant answer to the question above and draft a response I can send the user. The user's name is John.”

And Viktor’s reply:

Viktor did a fantastic job and I can now just copy the response and send it.

In the future I want to take this flow even further by simply adding a label to the email and have Viktor create a response directly in Gmail as a draft.

AI workflow #5: Share summary of bank statements to better understand financials

One of the most powerful things AI agents can do is view pdfs and other file types via the MCP server.

In this workflow I’m going to show you a powerful use case where we can use Viktor to analyze financial documents straight from our knowledge base.

The first step is to have a place in Slite where exported pdfs from your bank are saved.

Slite allows you to add files to documents and you can use headers and the useful “table of contents” block to keep things organized.

In the example above, I’ve saved two exported pdfs from my online bank, Mercury, for one of my checking accounts for Hawkeye Venture, my software holding business.

Believe it or not, Viktor, our Slack agent can access these pdfs directly via Slite’s MCP server.

This is what I wrote to Viktor to see if it could analyze the pdfs:

Below is Viktor’s response.

Just incredible! I went over all the numbers and Viktor was spot on!

To turn this into a recurring task for Viktor, I sent it the following:

“@Viktor Great job. Please create a recurring task which should take place on the 2nd Monday of every month. I want you to look for the previous month’s PDF in the “Mercury Monthly Bank Statements - Hawkeye Ventures” document in Slite using the Slite MCP server and share a summary of the month’s transactions. I want to see balances and a breakdown of revenue and expenses by description, type and amount.”

AI workflow #6: Build a content digest and stay on top of industry news

Most industries have a handful of websites where the most relevant news is made public.

You can use Viktor and your knowledge base to build a repository of relevant articles and then turn it into a content digest to help stay on top of industry news.

The first step to build this workflow is to create a document in Slite which can act as your “database”.

Next I asked Viktor to visit the RSS feed of one of the websites which are relevant to my industry, Techcrunch, and add the contents of the RSS feed to the table.

I did this to see if Viktor could visit the RSS feed, pull the relevant contents and add them to the table. If it can do all that with a single prompt, the rest of the flow will be easy.

I could have improved the prompt above by mentioning that the document was in Slite but Viktor was smart enough to work that part out itself.

Viktor got the details and was ready to add them to the table but it first needed approval since the request was to update a Slite document which is a riskier request.

You can change which actions require approval for each integration in your Viktor account.

After providing Viktor with approval and waiting a few seconds, it let me know the task was complete.

I now knew that Viktor could achieve what I wanted so I could now optimize the prompt.

“@Viktor Good job. I want you to visit https://techcrunch.com/feed/ once a day at midnight UTC time and record the contents in the “Publications Worth Reading” document in Slite.”

You could include multiple RSS feeds in the prompt above to expand your data collection.

Since Techcrunch publishes more than 20 articles a day (their RSS feed is limited to the most recent 20 posts), this flow wouldn’t capture every publication so you might want Viktor to run the check more frequently (will be more expensive), or to add more filters so Viktor isn’t saving every post in the table.

At this point we are automatically seeding our database but we aren’t done yet. We need Viktor to summarize the most recent publications in our database.

“@Viktor Visit the document, "Publications Worth Reading", in Slite and share a summary of the most recent publications listed in the table in the document. Most recent means posts which were published in the last 7 days. Limit the summary of each publication to 5 sentences or less.”

Viktor didn’t disappoint.

Make sure you are very clear in your prompt so Viktor doesn’t end up summarizing the entire database which would cost you a lot of credits.

The last step in the process is to turn the request into a recurring task.

“@Viktor Once a week on Monday at 8AM I want you to visit the document, “Publications Worth Reading”, in Slite and share a summary of the most recent publications listed in the table in the document. Most recent means posts which were published in the previous week. Limit the summary of each publication to 5 sentences or less. Limit the number of posts you summarize to no more than 15. If there are more than 15 posts which have been published in the previous week in the table, prioritize posts which include “fund raising”, “SaaS”, “Cursor”, “Anthropic”, “Claude” or “VC” in their titles.”

Final words

If you got this far, pat yourself on the back.

You’ve built a “brain” for your company and learnt how to use your unique knowledge to run powerful AI workflows.

You now have the skills to continue to scale your knowledge base and AI tools to add more and more value to your company.

I’ve done my job and it’s now your turn.

I want you to share with me below in the comments section one example of an AI workflow you’ve built that leverages your knowledge base.

Thanks for reading and if you liked this post, please go ahead and hit the share button below so others can find my content.

Justin

Share

*This post includes affiliate links for both Viktor and Slite. I’m a fan of both of these solutions and use them regularly to support SaaS Decoded. I pick the tools I partner with very seriously. If you decide to signup and pay for either Viktor or Slite, I’ll get a small cut of the money you spend in your first 12 months.

Subscribe now

Hey friends,

Last week I published part 1 of my series on product-led growth for B2B SaaS.

In part 1 I introduced the concept of PLG and shared 8 examples of companies which grew to “unicorn” status using PLG tactics.

In part 2 I’m going to go deeper on the core concepts behind a PLG strategy.

I’ve also decided to cover the topic of PLG metrics in next week’s post which will be part 3 of this series.

The PLG concepts I’m covering in this post include:

1. The Bowling Alley Framework

2. Time-to-value (TTV)

3. The Flywheel Effect

4. Product-Qualified Leads (PQLs)

The Bowling Alley Framework

The Bowling Alley Framework is a powerful user onboarding strategy developed by Wes Bush, the founder and CEO of ProductLed.

A business which adopts a PLG strategy needs users to drive user acquisition.

Therefore, it’s critical that users experience the desired outcome of the product so they can tell their friends, coworkers and extended network.

As the image above shows beautifully, the Bowling Alley Framework is designed to help guide users to their desired outcome.

To implement the Bowling Alley Framework, a business needs to do 3 things:

• Define the straight line to the desired outcome

• Create one or more product bumpers

• Create one or more conversational bumpers

Define the straight line to the desired outcome

Each SaaS product needs to have a clearly defined straight line to their desired outcome.

This would be the path that you’d expect the majority of users to take to experience the core value the app provides.

Let’s look at Canva’s “straight line” and see what we can learn.

Step #1 - Visiting Canva’s homepage and clicking on “Sign up” or “Start designing for free”.

Step #2 - Choosing your desired signup method and complete the signup process.

Step #3 - Answering the question, “what will you be using Canva for?”.

Step #4 - Either start a trial of Canva Pro / Canva Business, or skip.

Since I chose “Small business”, Canva gave me the option to immediately start a trial of their premium offering.

This is smart because a certain percentage of businesses will convert immediately to the paid version which benefits Canva, while adding very little friction to the onboarding flow.

Step #5 - Either opt into receiving content from Canva, opt out, or skip.

Step #6 - Choose what to design.

I was now done with the onboarding (notice the confetti to congratulate me) and ready to get designing.

Canva does an amazing job of showing the wide range of design options and emphasizing “templates”.

Templates are key for helping non-designers (Canva’s target market) create designs without having to create designs from scratch.

Step #7 - Pick design use case.

For this example I want to create an image I can use in a LinkedIn post to promote this Substack post.

I clicked on “Social media” and then “LinkedIn”.

Step #8 - Write out my desired outcome, pick a free template and make changes.

In 8 short steps I went from a non-user to my desired outcome, designing an image for a LinkedIn post.

The time-to-value, a topic I’ll be covering later in this post, was less than 5 minutes.

Create one or more product bumpers

Product bumpers are user-interface-based elements and messaging set up in the product to help users get to their desired outcome.

Product bumpers can take many forms from product tours, to progress bars, checklists and welcome messages.

In the case of Canva, their use of the search bar, icons and cards are product bumpers since they help guide the user to the design builder where value is created.

A nother great example of a business that uses product bumpers effectively is Canny.

After signing up to Canny you are taken to a “Get Started” page (screenshow below).

On this page Canny has 3 distinct sections.

On the left you have listed the main product that is chosen during the onboarding, in my case it was the Feedback Portal. Canny indicates to me that there are 4 steps to finish setting up this feature. Those 4 steps are shown directly to the right of the left hand section.

Canny emphasizes that there are other products I should explore and three ways I can get more value from their platform (by setting up integrations, deploying their widget, and by inviting my team to my Canny account).

Canny has effectively communicated multiple things to me with clear emphasis on the additional steps they suggest I take to complete the onboarding.

Create one or more conversational bumpers

Conversational bumpers are messages that are set up outside of the product with the purpose of educating, re-engaging and helping guide users to their desired outcome.

The most common example of a conversational bumper is the onboarding email series which most SaaS have in place. These are the emails you receive for the first few weeks after signing up to a SaaS.

Below is the welcome email I received after signing up to Canny.

I’ve highlighted in green the elements of the email I want you to pay attention to.

Notice the clear intention of the email, to help you start generating feedback. Canny’s whole focus is on helping its users generate and manage product feedback.

Once a single piece of feedback exists in Canny the user experiences the “Aha Moment” which is why Canny aggressively pushes the user to reach this point.

Canny’s welcome email has multiple calls-to-action which is typically not best practice, but notice how well the different options are laid out. Since the email has one main goal, providing multiple options to the user, each with its own CTA isn’t a big deal.

Other mediums such as SMS, explainer videos, and push notifications are also used for conversational bumpers.

A tool like Intercom is very effective for creating smart welcome series. Intercom allows you to leverage your user and product usage data to build communication flows with smart branching.

Time-to-value (TTV)

Time-to-value or TTV for short, is the amount of time it takes for a user to realize the value they were promised.

In PLG, we specifically focus on the "Aha! Moment"; the point where the user’s mental model of your product shifts from "Is this what I think it is?" to "I get it."

If the Bowling Alley Framework is designed to help get users to their desired outcome, then TTV is the time it takes the user to reach that point.

As a general rule TTV needs to be as short as possible without deminishing the value the user receives when he reaches the “Aha! Moment”.

The main reason TTV needs to be short is users need to quickly see the value the service provides or they will churn (leave and usually never return).

Key variations of TTV

TTV can be measured in a few different ways.

• Time to Desktop/Login: The literal time to access the app.

• Time to “Aha!”: The moment of emotional/mental realization of value.

• Time to ROI: When the customer sees a measurable return (e.g., their first sale, first automated report, first lead captured, etc).

• Time to Expansion: When the user realizes enough value to upgrade or add seats.

The most important is “time to ‘Aha!’” since once the user “gets it”, users will be more likely to give the app a chance and continue using it. This gives the SaaS more time to show ROI and set up the conditions for account expansion.

Strategies to Reduce TTV

To win at PLG, you want to drive TTV as close to zero as possible. Here is how the best SaaS companies do it:

1. Progressive Onboarding

Don’t demand a 10-step setup immediately. Use functional deconstruction: give the user a small win within 30 seconds, then ask for more actions later.

We see this in action in Canny’s onboarding.

After a short signup and onboarding flow, you get to see your feedback board (the small win), but Canny does require the user to take a few more steps to complete the setup.

2. “Empty State” Optimization

Nothing kills TTV like a blank dashboard.

• Templates: Provide pre-filled boards or docs (e.g., Notion, Canva).

• Dummy Data: Show them what a “success state” looks like.

After completing the onboard, Canva gives you dozens of options for easily getting started. Imagine how much tougher it would be for users if they didn’t have these options listed out for them?

3. The “Frictionless” Path

The more friction there is to getting to the “Aha! Moment”, the worst off users will be. PLG businesses are obsessed with removing friction wherever possible.

• Login using Google/Facebook: Google/Facebook login removes the “check your email for a link” or remembering password friction.

• No Credit Card Required: Removing the paywall at the start allows the user to reach the “Aha!” moment without a financial barrier.

4. In-App Guidance

Use interactive walkthroughs (like Pendo, WalkMe or Intercom) that guide users toward the specific feature that triggers the “Aha!” moment.

Measuring the TTV Funnel

To improve TTV, you have to track it.

The easiest way to do that would be in a spreadsheet where you can record your targets and cohort-based analyses.

It’s important to use cohort-based analyses to track the TTV metrics since it’s reasonable to assume your product and marketing are evolving and not every user is the same, or has the same experience.

Remember that you need a sufficient number of users and event tracking in place in order to conduct the kind of analyses needed to build the table above.

*The results in the below table would be either the average across the entire cohort, or the bottom 80% percentile of users (rank users by quickest to “Aha Moment” and measure users up to the 80% percentile).

The Flywheel Effect

When it comes to exponential, viral growth (what PLG businesses hope to achieve) flywheels are everything.

First let’s try and understand a flywheel.

Below is an example of a PLG flywheel that Notion has built.

The first step in the flywheel is for a user to sign up to Notion. To get this flywheel started, Notion had to run marketing campaigns and drive traffic to their website.

Most flywheels require an initial “push” by the business to get it started but after enough “energy” is put into the “system”, the flywheel continues on its own.

The second step in the flywheel is for a user to create a template in Notion and share it publicly on social media.

The result is that some non-users see the template, get their first taste of Notion and then decide to signup and try out Notion for themselves.

Note how step 1 was started by Notion but the rest of the steps are performed by actors other than Notion.

By making part of their product modular and sharable, Notion was able to construct a very successful PLG flywheel. But it doesn’t end there.

By allowing search engines to crawl the templates, and by launching their own template marketplace, Notion was able to leverage more traffic engines (SEO and marketplace) to “speed up” and enhance the flywheel.

The most successful PLG businesses leverage multiple flywheels and have taken steps to enhance them.

Let’s take a look at another example.

DropBox is one of the legends of PLG. I covered them in detail in part 1 of this series.

As the image above shows, DropBox leverages multiple PLG flywheels.

The first is a classic “collaborative” loop where users of DropBox can use the product to share files with others, driving non-users to DropBox without DropBox needing to do anything.

The second flywheel is another “collaborative” loop where one DropBox user exposes the service to their colleagues, driving brand awareness and creating DropBox advocates who will introduce the tool to future employers.

The third flywheel is DropBox’s most powerful.

It leverages a two-sided incentive referral program to empower users to drive new signups.

What makes this referral program special is that both parties have a powerful incentive while the cost to DropBox is extremely minimal (the cost of storage is very low).

Product-Qualified Leads (PQLs)

Most PLG businesses drive the majority of their revenue through a freemium, self-service model.

The idea is to allow users to experience the product for free and once they are ready they can upgrade to a paid subscription to experience more value (or continue to receive value).

Once a freemium SaaS has enough paying users certain patterns emerge which can be used to predict the likelihood of a user becoming a paying user.

A product-qualified lead is a user, or account in the case of B2B, which has taken the necessary actions, or received enough value that they have a high chance of upgrading to a paid subscription.

Reaching the “magic number”

There is a fascinating story from the early days of Slack which PLG businesses should know about.

The founders of Slack noticed by looking through their data that 93% of businesses that wrote 2,000 messages ended up becoming paying users.

Since Slack had it’s “magic number” it could define users as being “product-qualified” once they hit that number.

Once a PLG business identifies it’s “magic number”, the entire focus of user activation should switch to removing friction and enabling users to reach that number.

The “magic number” doesn’t always exist in a vacuum.

Often the qualifications for a user to become “product-qualified” include a combination of product usage, depth of usage (number of features, number of integrations setup, etc), time of use (used the product for more than X months), and characteristics of the business itself.

Everything from the number of employees, age of the company, the culture of the employees, geography, and industry play a part.

Once a user, or account, gets “flagged” as a product-qualified lead, it’s common for SaaS business to start sending emails and other forms of communication (popups for example) to introduce the user to the benefits of the paid plans.

This little “push” helps improve conversion to paid and has no down side.

That’s it for part two, make sure you subscribe to receive part three in your inbox next week.

Subscribe now

Have a fulfilling and productive week ahead.

Justin

This legendary growth tactic is one of the best examples of how product-led helped a B2B SaaS business reach “unicorn” status.

In this two part series I’m going to be covering the topic of product-led growth (PLG) in all its glory.

In part one I’m going to introduce the concept of PLG and share 8 examples of companies that have grown to a billion dollar valuation using PLG tactics.

I’m going to share the main tactics each of these businesses deployed and why they were so affective.

In part two (coming next week), I’ll go into detail on core PLG concepts and the growth metrics PLG companies need to care about.

If you’re new to SaaS Decoded, welcome, I’m Justin. Each week I publish an in-depth, actionable guide to help SaaS operators grow their businesses. If you enjoy this content, consider subscribing below.

Subscribe now

What is product-led growth (PLG)?

The term Product-Led Growth (PLG) was coined in 2016 by Blake Bartlett, a partner at the venture capital firm OpenView Venture Partners.

Product-led growth is a strategy where the product itself acts as the primary driver of user acquisition. This is done typically through word of mouth, viral loops or a combination of both.

Software businesses were using product-led growth strategies much earlier than 2016, but until PLG was coined we didn’t have a term for the overarching strategy of using the product to drive the majority of user growth.

8 B2B SaaS “unicorns” that adopted a PLG strategy

Here are 8 standout examples of B2B SaaS businesses that scaled to over $1 billion dollar evaluation using a product-led growth strategy.

1. Slack

Slack is the “poster child” for PLG. It famously grew to a $1.1B valuation in just over a year without a traditional sales team or marketing budget in its early days.

Slack grew by users inviting teammates to collaborate within their workspace. This created a viral internal loop.

Slack’s freemium model allowed businesses to get a taste of the platform at no cost. Once businesses hit their 10,000 message limit they were hooked and converting to a paid subscription became a “no-brainer”.

The combination of a freemium model, network affects, and the internal viral loop turned Slack into one of the fastest growing software businesses in history.

Another powerful PLG tactic Slack used was the launch of Slack Connect, Slack’s cross-workspace collaborative feature.

Slack Connect allows businesses to connect with each other directly in Slack.

This allows B2B service providers, like agencies and freelancers, communicate with their clients directly within Slack. This reduces email load and helps keep communication all in one place.

Slack Connect helps promote word of mouth because it fundamentally changes how businesses that know each other communicate with each other.

2. Zoom

Zoom disrupted a market filled with legacy giants (Webex, Skype) by focusing on a frictionless user experience and a “1-to-many” viral loop.

Every time a host sent a meeting link to a non-user, they effectively “demoed” the product.

When your product, by it’s very nature, is organically shared with other potential users, you have the opportunity for viral growth.

Zoom experienced hyper growth during Covid because so many businesses were forced to move to virtual meetings.

3. Calendly

Calendly reached the $100M ARR mark with fewer than 250 employees, a testament to the efficiency of its viral “scheduling loop.”

Similarly to Zoom, when users share a Calendly booking link they introduce the service to potential users. Recipients of the Calendly link are introduced to the seamless experience and see the value the service provides.

4. Notion

Notion used a community-led and product-led hybrid strategy to grow the business into over a $10 billion valuation.

Notion allows users to create wikis, roadmaps and other templates which can be shared publicly. This allows users to expose the Notion brand and the modular nature of its product to potential users.

This has been such a successful growth strategy that for many years Notion has supported an entire marketplace of templates where creators earn revenue per sale.

Notion is built with both individuals and teams in mind allowing it to support a wide range of avatars, and online businesses of all sizes.

5. Dropbox

Dropbox pioneered the “referral loop” in the early days of SaaS, rewarding users with extra storage for inviting friends.

The genius behind Dropbox’s referrel loop was that both parties benefitted from it (both the referrer and recipient received extra storage).

In addition to the referral program, Dropbox used a second PLG tactic, the collaborative loop, to drive more growth.

Users of Dropbox can share folders to others, forcing them to sign up to the service to access the contents of the shared folders.

6. Figma

Figma took over the design world by being browser-based and inherently collaborative.

Before Figma, design tools were used exclusively by designers.

Figma changed the game by allowing everyone involved in the design process, from product developers and marketers to engineers, to collaborate in one place.

Each designer that signed up to Figma effectively became a promoter of Figma purely by the nature of how the product was used.

Since Figma has seat-based pricing, the more people that sign up to collaborate in Figma, the more the company makes.

For more on Figma’s PLG strategy, check out this insightful post by Aakash Gupta, The Figma Product Growth Strategy.

7. Zapier

Zapier, and similar companies like n8n, use an SEO-based “integration loop” growth strategy that ties back to the product.

It starts with potential users searching for “how to connect app X to app Y” and then finding a dedicated landing page that covers that specific combination.

Users then sign up to Zapier to set up automations. As the userbase grows so does the demand for more integrations.

As the number of integrations grows, so does the number of potential combinations that are covered through search engine searches.

8. Cursor

Cursor is one of the darlings of the agentic AI wave and has quickly become one of the most popular software products among developers in the world.

Cursor is a revolutionary product which is changing how developers are building software.

Cursor is also one of the main contributors to “vibe-coding” which is reshaping the entire SaaS market.

Cursor has deployed some smart community-led growth tactics but most of its growth has been through word of mouth.

Every now and then a product comes around that is such a game changer that people can’t help but talk about it. Social media is flooded with references to Cursor.

In cases where the product is so “mind blowing”, a company doesn’t need to invest in traditional marketing channels since word of mouth is viral in nature and enough to result in exponential growth.

How PLG companies grow

Let’s summarize what we know about the 8 PLG companies we covered above.

The most common PLG tactic used is a collaborative loop, where the product is introduced to team members, clients, or the general public through sharing or invitations.

In some cases, like Slack and Notion, there are network affects (each individual that is invited to the workspace benefits the rest of the users in the workspace).

Referral and integration loops are much rarer since they are hard to implement or very niche.

Many of the companies in the list have referral programs but they are structured, partner-based and not self-service. I don’t categorize these as PLG-based.

Word of mouth is the gold standard and the hardest to pull off. It requires a truly outstanding, revolutionary product.

A common tactic among PLG companies is to have freemium pricing (users can signup and use the service for free). Notice that every company in our list allows users to sign up and use the service for free.

The more loops a PLG company has, the higher the possibility of extreme exponential growth.

Combining freemium, multiple PLG loops, and a revolutionary product is the recipe for record-breaking growth.

For more examples of PLG companies, check out the product led growth market map by OpenView Venture Partners below.

That’s it for part one, make sure you subscribe to receive part two in your inbox next week.

Subscribe now

Until next week.

Justin

Subscribe now

Hey friends,

This weeks edition of SaaS Decoded is going to be different.

I want to experiment with a new format called “Justin’s Field Notes”, where I share some of the best social media posts, news items, tools and other tidbits I’ve come across in the last few weeks.

Since I spend a lot of time online and often come across very insightful and useful content, I think it would be a good idea to share some of my favorites with you.

If this post does well and the feedback is positive I’ll aim to share a post like this once a month.

Simple, affordable pricing + clear need + large TAM + good execution + time = massive success

Judge.me is a SaaS app operating in the direct-to-consumer eCommerce market that makes it easy for brands to generate customer reviews.

These guys have been in the market for a long time and have slowly grown to $15M ARR by being focused on solving a clear need for a large market at a great price.

What makes Judge.me stand out is their simple pricing. They have a free plan and a paid plan. The paid plan is just $15 a month.

Another great example that there are many ways to play the SaaS game.

Meet Viktor, my virtual employee

Last week I published a post teaching you how to add an AI agentic agent to Slack. In the post I covered a service called Viktor which was the best agent out of the two services I tested.

I’ve since spent some more time playing with Viktor and I’ve become a big fan.

Since I’ve been focusing on simplifying my day-to-day work I don’t yet have enough recurring tasks for Viktor to move from the free plan to the paid plan but I’m now convinced that using a service like Viktor on top of Slack is a no brainer.

Below are some ways I plan to use Viktor to improve my productivity:

• Create weekly recurring tasks in Asana and assign them to relevant projects.

• Let me know if any Tableau reports belonging to my clients fail to refresh (I have one remaining projectBI client).

• Help me draft SOPs in Slite.

I’m purposefully cutting tasks and drastically simplifying how I work throughout the week so the number of tasks I can automate through Viktor is minimal but I would still recommend giving the service a try.

I’ll report back once Viktor is doing a few more things for the business.

Wallet share, smart user interviews, and other insightful lessons from social media

Below are some of the best posts I’ve come across recently on social media.

1. That gap has a name: wallet share By Jeff Ignacio [LinkedIn]
   

2. They buried their most valuable feature in the Enterprise plan By Mayengbam Tommy [LinkedIn]
   

3. BOOOOOM! $1,000,000 ARR By Elston Baretto [X]
   

4. This is why i never worry about competition By Robleh [X]
   

5. We only had 50 users two years after founding Stripe By Startup Archive [X]

HubSpot Acquires Starter Story After Eight-Year Bootstrapped Rise

Yesterday the news broke that HubSpot has acquired Starter Story.

Pat Walls, the founder of Starter Story built the business from the ground up into a 7-figure a year media business with a massive audience.

Pat did a fantastic job telling the full story behind Starter Story in a recent threaded post on X which you should definitely check out.

Here are the highlights:

• Started Starter Story from a Starbucks while still working a job. Pat was 27 years old when he started the business.

• It slowly grew to $3k - $4k per month which is when Pat quit his job.

• He didn’t believe in Starter Story and tried many other ideas.

• At 29 he went all-in on Starter Story and grew it to $1M a year in revenue after 2 years.

• 5 years in he started publishing on YouTube.

• Today Starter Story has 4k+ founder stories, 1.6M+ followers, 250k+ newsletter subscribers, 10k+ paid members and millions in annual revenue.

Did you enjoy this format of the newsletter or do you miss the long-form guide style that I usually go with?

Please let me know in a comment below or by sending me a short email to justin@projectbi.net. Any feedback you have for me is helpful.

Until next week.

Justin

Share