I’ve been spending a lot of time on Project Echo lately as I try to build some positive momentum.

As I reported in part 6 of the $0 to $10k series, signups have dried up completely and I’ve felt quite stuck. I was honestly close to throwing in the towel.

While feeling especially low, I wrote an X post sharing my feelings.

This post got a bunch of replies by some experienced and highly successful indie developers and the feedback was very helpful.

The general theme of the feedback was that my messaging wasn’t good enough and there were too many red flags that were putting people off.

I took the feedback seriously and took a day or two to think it through.

Project Echo’s new positioning and refined ICP

I realized that going with the positioning of collecting, managing, organizing and sharing user feedback was quite weak. I also realized that my ideal customer profile (ICP) wasn’t clear enough.

The website looked outdated, “cheap”, and I hadn’t updated the open page in a while.

I needed to rethink my strategy and get clearer on Project Echo’s mission, unique selling proposition (USP), and messaging.

While this was going on I also managed, for the very first time, to get a Project Echo user fully integrated with the platform.

This was an amazing feeling since the user now fully understands the platform and is using it almost daily since getting set up.

The combination of getting this user fully integrated, discussions I had with a few indie developers, and a lot of thinking led me to come up with a new positioning for Project Echo.

Project Echo’s refined ICP is independent developers (indie developers and vibe-coders) who build with AI and want to integrate user feedback in their development process.

These individuals move quickly and need a tool which integrates into their existing process without adding friction.

Previously I expected users to spend time within Project Echo utilizing the roadmap, changelog and other features, but this isn’t appealing to most developers. Most don’t have a product roadmap and changelog, and aren’t interested in adding extra tasks to their busy week.

What most developers don’t have is a clear process for collecting user feedback, getting input from their users on feature requests, and for closing the loop.

This is the first big value add of Project Echo; the platform integrates with your SaaS and gives you the feedback portal which is used for collecting feedback. Users can vote for the requests they back, and share their thoughts as comments.

The next big piece of the puzzle is allowing users to pull all the useful information in their Project Echo workspace into their development process. Project Echo’s API and MCP now allow users to do just that.

The process has now changed from: Collect —> Organize —> Optimize —> Share —> Close the loop to,

Collect —> Prioritize —> Build —> Close the loop —> Share

The new and improved homepage

Now that I had my new and improved positioning, it was time to work on a new homepage and better messaging.

Along with a new headline and sub-headline, I also managed to implement the style guide for the Project Echo brand that I got a professional designer to create for me years ago.

I gave the style guide pdf to my design agent in Grok Bot and asked it to turn it into a design system I could share with my Cursor coding agent.

The change in the quality of the design of the site is remarkable. The colors, font’s, text sizing, etc is a massive improvement over the previous version.

Each day last week I spent some time tweaking the site. This lead to an improved footer section, the addition of the request page image above the fold (to show off the admin area), and other improvements.

For now I’m happy with the homepage and will keep this version running for at least the next 6 weeks to see how it performs.

The one piece I’m still missing is social proof which will come next.

Even though the signup count still hasn’t moved, I feel a lot better about things and now just need to give it some time.

My focus shifts again to driving eye-balls to Project Echo and in a few weeks I’ll know if this new positioning makes a difference.

Enhancements to the Open page

This past week I also made a number of improvements to the Project Echo Open page.

The biggest change is the inclusion of a “Recent activity” live feed showing anonymized activity across all the Project Echo workspaces.

I got this idea after adding a similar UI to the Project Echo app.

I’m a fan of this type of feature, especially in platforms where different individuals can take action and you aren’t necessarily aware of those actions. This UI allows admins to stay on top of everything going on in their workspace.

In addition to the new activity section, I also changed the P&L section to include the actual expense line items. Previously it was grouped by category only which isn’t that helpful. Now visitors to the Open page can see the exact items I’m spending money on each month.

Project Echo’s first fully integrated user, ibuildinpublic

A few weeks ago I connected with Ehsan Yazdanparast, the founder of ibuildinpublic, a new community for people that build in public.

Ehsan signed up to Project Echo and was interested in using it to collect feedback from early users of ibuildinpublic.

After a demo call, and a follow up call to help Ehsan set up his workspace and integrate Project Echo into his site, he was ready to start collecting feedback from his users.

Ehsan added a prominent “Submit Feedback” button on every page within the website which takes users to ibuildinpublic’s feedback portal.

Since ibuildinpublic has Project Echo’s embed code on each page of his web app, only logged in users who get to the feedback portal can actually engage with it.

Ehsan has sent me a bunch of useful feedback for improving Project Echo which is extremely valuable. I’ve returned the favor by using the new feedback collection funnel set up using Project Echo.

ibuildinpublic goes live soon and I can’t wait to see how Ehsan’s users engage with Project Echo and help him improve the site.

If you build in public and looking for a place to interact with other builders, then make sure you check out ibuildinpublic and join the waitlist.

Project Echo’s first AI feature

The last big Project Echo news item is that a few days ago I completed the development of Echo’s first AI feature.

The feature allows users to generate a detailed implementation prompt from any of their requests either manually, or via a dedicated MCP tool.

The idea is that once a user is ready to implement a request, he needs to write a prompt to his coding agent to implement it. Now with a click of a button, that prompt can be written automatically for the user.

The way it works is that Echo sends the title, description, comments and internal notes of the request to Claude and in return we get a detailed implementation prompt. The prompt can be regenerated once new information becomes available.

The cool thing is that the implementation prompt can be pulled directly into Cursor, Claude or any coding tool via Project Echo’s MCP server.

Right now it costs about 4c per generated prompt so I will have to limit the usage of this feature on the free plan but for now with little activity in Echo, I’m not going to block it.

This feature is meant to lean heavily on the new positioning and provide a way for developers to turn feedback into PRs quickly without leaving Cursor or Claude. Time will tell if its a hit.

Well friends, that’s it for this week. I’ll see you in the next one.

Justin

PS: I just published a detailed guide on how I use Grok Bot on my other Substack, Coffee + Revelation. If you aren’t using Grok Bot and want to know how I use a team of 8 bots to help me grow my businesses, make sure to check it out.

Share

From 2017 until around the start of Covid, I made my living helping early-stage SaaS companies set up their product analytics and reporting.

I’ve helped many startups “turn on the lights” to make better business decisions and in this post I’m going to help you do the same.

In this extensive guide I’m going to cover the following topics:

1. The 5 steps of the product analytics implementation plan.

2. The frameworks you need to understand to shape your product analytics strategy.

3. Best practices for building and maintaining a tracking plan.

4. How to scale your product analytics events, and tie it to your product development process.

5. Introduce you to PostHog, the king of product analytics.

6. How to setup and use PostHog.

7. The difference between client-side and backend events.

8. A list of the first events you need to start tracking.

9. A list of important product questions, and how to answer them.

By the time you’ve finished reading this guide you’ll know exactly how to gain visibility into your own SaaS product, the important questions you should be asking, and how to answer them.

You’ll know if you’re moving towards product-market fit, where users are getting “stuck”, and how many are experiencing your “wow” moment.

We have a lot to cover so let’s get started.

Subscribe now

The 5 steps of the product analytics implementation plan

Before jump into the “meat and potatoes” of this post, I think it’s a good idea to have a high level understanding of what we want to achieve, and the plan to get us there.

Our primary goal is to set up the necessary tooling, infrastructure, frameworks and processes to allow the key decision makers to answer business critical product questions.

To do that we will follow the product analytics implementation plan shown in the image below.

The plan has 5 main steps which will be covered in detail in this post.

Before we move onto step #1, building a tracking plan, I first want to cover 2 important frameworks.

2 important frameworks to help shape your product analytics strategy

While working as an analytics consultant, I developed two useful frameworks that are important to know before discussing the tracking plan.

Framework #1: The core funnel

If you’re a long-time reader of this substack then you should be familiar with the core funnel framework.

The 12 minute video below covers the framework in detail.

The main idea behind the core funnel is to map out the major steps in your users journey. Most SaaS typically have 3 - 6 major steps which make up the core funnel.

The reason it’s important to understand the core funnel is because it gives us a starting point for our event tracking plan, and forces us to stay focused on what matters. We first want to make sure we can track the core funnel before we focus on other areas.

A SaaS that doesn’t have visibility into how users progress through the core funnel are “flying blind”.

Framework #2: Include product analytics in your product development process

The second framework is to integrate product analytics in your product development process.

Product managers need to be trained on product analytics basics and include a section in their product requirement documents (PRDs) that cover product analytics. Some businesses hire product analysts who are responsible for covering this area instead of the product managers.

The kind of data I like to see included by product managers are:

1. A list of questions which the product analytics need to answer. For example, “how often is this feature used to users?”, and “can we track when this feature is enabled or disabled?”.

2. The actual events themselves so that the developer who builds the feature can make sure they are covered before the feature goes live in production.

In a few minutes of reading, you’ll have the knowledge you need to implement framework #2 in your startup. The main takeaway is that once you’ve decided to start adopting product analytics, it needs to become a part of your product development process.

We’re now ready to move onto the first step of the product analytics implementation plan, building a tracking plan.

Best practices for building and maintaining a tracking plan

A tracking plan is a company-wide resource to help everyone stay aligned on the events that R&D have, or will implement. It’s a “data dictionary” of sorts that help keep things organized.

A good tracking plan has an owner, usually the head of product, and is consistently maintained. A tracking plan has its own set of rules which should be written down in the internal knowledge base, and shared among the product and R&D team.

I recommend building your tracking plan as a table, either in Google Sheets, or an equivalent solution.

I created an example tracking plan which you can view here. Feel free to steal it: https://docs.google.com/spreadsheets/d/1JQ3WlxyCwYFeHi2TjS_aTizm_vSHkaQS8lnI2leM18A/edit?usp=sharing

I only filled out all the details of the first 4 events, but you have enough to get a good idea of what a tracking plan should look like.

Let’s go over the columns I’ve included in my version.

• # - The “id” of the event in the document. It also acts as a counter so you can see how many events are in the document. Having a number for each event is also helpful for referencing events in the document (“check out event #4 in the tracking plan”).
  

• Event name - Standard. Each event needs a name. This name is what will appear in PostHog.
  

• Date Added - Just good to have. Helps see how the event list grows over time.
  

• Added By - The individual who added the event to the plan. Helps involve the product managers, analysts, etc. Helps everyone understand ownership.
  

• Status - You should have different statuses for each step in the funnel of taking an event from concept to live in production. This way it’s easy to see where the event is in the process. Use statuses which make sense to you based on your own process. In my example I have “Work In Progress”, “Ready for Dev”, “Ready for QA”, “Live” and “Canceled”.
  

• Default properties - This column is optional but it does help having it to remove confusion for QA. PostHog has certain default properties which are out-of-the-box and can’t be manipulated. You can list those in the tracking plan so QA knows to ignore them.
  

• Custom properties - This is by far the most complex field in the tracking plan. In this column you need to list all the properties you want to include in the event. Here are a few helpful guidelines to know for assigning properties:

  • Include ids - This helps analysts (and also agentic agents) run joins and connect events to each other, or other entities in your database.

  • It’s fine to include ids and their values as separate properties - Notice I included both “source_id” and “source” as properties for the Request Created event. Having both allows for quick understanding in the PostHog interface, as well as allowing for a join.

  • Reuse properties to keep the distinct list as small as possible - For example, don’t have two properties, “button_color” and “color”, just use “color”. Use common sense, and try and keep the names of properties “high level” so they cover a wide range of use cases. Use simple, descriptive words to avoid confusion.

  • When you need more than one property to distinguish between possible actions, use multiple properties, don’t create a unique property - Lets say you have multiple red buttons on a page and want to track which button exactly is being clicked. How would you do it? In such a situation I would have an event called “Element Clicked”, and 3 properties, type = Button, color = Red, and location = top right corner. Notice I have 2 descriptive properties to help me distinguish between the actions. I would map each button’s location clearly in the PRD when these events are created and create a button click event for each button.

  • Be consistent - This includes maintaining the naming convention rules, using the same relevant values across multiple events, etc.
    

• Trigger - The trigger column is used to explain clearly the trigger logic for each event. Make sure it’s clear when the event should be triggered and cover nuances and rare situations so the developer creating the event can cover all scenarios.
  

• Task URL / Story URL - Depending which product development tool you use (usually Linear or Jira, but sometimes Notion, Trello, or some other solution), you would have a url to a document, table entry or “story” related to the event. Whoever is working on the product update that is related to the event should include the url to the document in the tracking plan. This allows others to click through and see the full context behind the event. We only need to include the link to the document or story for the first time the event is created.
  

• Notes - A general field for notes by the person who added it, or the head of product. It could be used for starting a comment thread where a discussion on the event might be needed. This field is very much optional.

Now that you’ve got the outline of your tracking plan ready, which events should you add first?

A list of the first events you need to start tracking

Each SaaS will have it’s own initial set of events so I can’t give you an exact list of events to add to your plan. What I can do is give you some guidelines to help you come up with your initial list.

Limit your initial list to no more than 10 events, and focus on the core funnel

As the headline above says, start with no more than 10 events.

That usually involves 3 - 6 core funnel related events, and a few others related to primary usage / value exchange.

For my SaaS, Project Echo, a user starts his journey by signing up, going through a short onboarding process and then landing on the request page.

During the onboarding the user picks a few requests to help seed his workspace but the real “wow” moment is when one of his users submits a request.

To help map out this process using events, I need the following events:

1. User Created - The first step. It’s triggered when a user either signs up using email, or their Google account. Since one user can have multiple workspaces, I need an event that specifically indicates a new user signed up.

2. Onboarding Completed - Triggered once a user has completed the onboarding process. At this stage the user is ready to see value from the SaaS.

3. Member Created - A member is an end-user of a Project Echo user. A member is either created manually, or automatically if the user integrates their SaaS with Project Echo. A member needs to be created before that individual can submit a request (the “wow” moment), so we need to track this event.

4. Request Created - The first real value exchange is when a user creates a request in their workspace. This can be done manually by the user, via an agent they have connected to their workspace, or via a script leveraging the API. Either way, when a user creates a request its a good sign and we want to track it. This event is also triggered when a member creates a request (the “wow” moment). We would use specific properties such as created_by_id, to distinguish if this request was created by a user, or a member.

So in total I just need 4 events to map out the most important part of Project Echo’s core funnel. I could add a few more such as “Subscription Started”, or “Invitation Sent” (for when a user invites their team to their workspace), but at the end of the day I need to first nail the value exchange part of the funnel before I focus on anything else.

Include events which help you understand usage patterns

I recommend including events which tie to direct, primary usage of your SaaS. In my case it’s Request Created but in your case you might have multiple features you expect users to use repeatedly.

The reason it’s good to have events for each feature use is because it can help you identify usage patterns that could change your product roadmap.

You might expect users to do A but you see in the data they do A once and then come every day to do B. Now you can focus on trying to understand what is special about B.

Usage patterns are really useful to know early because it can help you pivot in the right direction, rather than guessing.

Well done, you’ve built a tracking plan, decided on your initial list of events, and you’re ready to implement them, but which tool do we use to collect and house these events?

The king of product analytics: Introducing PostHog

PostHog is an all-in-one product analytics platform that was founded in 2020. Over the last few years the company has grown into a “unicorn”, and become extremely popular among early-stage SaaS startups.

The two main reasons PostHog has become so popular is:

1. It’s multi-tool approach.

2. Its extremely generous free tier.

Read more

It’s been almost 2 months since I published the last $0 to $10k MRR post so an update is way over due.

As you can see in the screenshot above from the Project Echo “Open” page, things aren’t looking good. It’s now been a month since the last new signup.

I’m going to address this in detail later in this post but before that I want to focus on a far more interesting topic, “agentification”.

The “agentification” of Project Echo

Earlier this month I briefly mentioned an email service provider by the name of Sequenzy. I’ve become a big fan of the service as I slowly set up all my SaaS emails on the platform.

What I find very interesting about Sequenzy is the deliberate effort of the founder to make Sequenzy “agent-friendly”.

The thinking behind this decision is that once a user connects their agent to the platform, the likelihood of them setting up sequences, and landing pages increases significantly.

The idea is that setting up email sequences and landing pages kind of sucks and we might as well let an agent work it out.

I tested out Sequenzy’s AI agent setup flow and managed to connect my account to a dedicated Grok Bot in just a few minutes.

I then asked my new “Email Specialist” to set up a sequence in Sequenzy with a simple prompt.

In just a few seconds the sequency was built as a draft and ready for my review.

The sequence was set up perfectly with the correct trigger and settings so that subscribers would only go through the sequence once.

The email itself needs a bit of work but that’s to be expected from my basic prompt. I was more interested to see if the agent could build the actual sequence and set up the logic correctly.

As we move closer to a world where the majority of the work is done by simply chatting with agents; SaaS will need to prioritize “agentification” of their platforms.

As a general rule, the more an agent can do in your SaaS, the better.

The fact that Sequenzy is so “agent-friendly” gives it a clear advantage over the competition, especially among potential users that want to work via agent prompts.

The X post above sums it up perfectly. SaaS that don’t support this way of working will be beaten by those that do.

How am I making Project Echo “agent-friendly?

The first major step I took to make Project Echo “agent-friendly” was to launch an API and MCP. I launched the first version back in July.

Around that time I started using Viktor, my Slack-native agentic agent for more tasks and I wanted the ability to ask Viktor to pull data from Project Echo.

This was a good start but there was more work to be done.

The next iteration involved enhancing the API, providing documentation, setting up an npm account for hosting the MCP package, creating a Project Echo skill, and adding useful links in the UI.

All these changes went live today and I now had enough in place to set up my own “Product Manager” bot that could help me get more done in Project Echo.

The first thing I asked of my “Product Manager” bot was to draft a new changelog that included all completed requests since the last changelog entry.

The outcome of my prompt was a fully fleshed out changelog entry with 20 requests connected to it. At this stage I would go in, do some editing, add some images and publish it.

The API does support the ability for agents to add images, YouTube video embeds and other formatting options. I’m yet to test these options but I’m happy that the standard use case is working so well.

The next use case I tested was request prioritization.

Project Echo already has built-in request scoring, but since an agent has access to both Project Echo data, and the web, there are some interesting possibilities.

Here is the prompt I used.

And the result.

I actually found some gaps from running this analysis which I turned into requests for the next version of the API.

Users will soon be able to push custom user data to Project Echo. These custom fields will be available via the MCP which would allow agents to run very interesting analyses based on your own user data, and their requests.

Request and user tagging, and user segmentation are other features in the pipeline which will work well with agents.

I also want to allow agents to create new boards, change feedback portal settings, and maybe even change scoring logic.

Another big piece of work that took place since my last $0 to $10k MRR update was the implementation of Mintlify for hosting documentation.

I initially thought I would use Intercom’s knowledge base feature set but I decided to drop Intercom entirely.

Mintlify is an amazing service which connects directly to Cursor and allows me to publish documentation right after making product updates. I love the UI, navigation, and useful buttons. It’s free to use and self-hosting.

I’ve created multiple documents related to Project Echo’s MCP and how to use it with your favorite agent. This should also help get Project Echo recommended by Chatgpt and other LLMs.

The API & MCP sections in the app have also been updated to include buttons to useful documentation.

The last big piece of work related to this major update to the MCP was the creation of a dedicated Project Echo skill.

This early version sits in a public repo under my personal Github which isn’t ideal but fine for now.

All in all I’m really happy with the work I’ve done in this area and I’m excited to continue on the path of making Project Echo as agent-friendly as I can.

I’m confident this is the direction software is heading and I want to make sure Project Echo matches future users’ expectations.

Dealing with zero growth and my plans to get unstuck

Now to address the elephant in the room; Project Echo is not growing.

The app currently has no active users and it’s been a month since the last signup. Honestly this is difficult for me to write but it’s the truth and to solve problems, we must face them.

The truth is that I purposefully put Project Echo aside the last 2 - 3 weeks since arriving in Thailand. I desperately needed to get through a backlog of admin and client-related tasks which had grown over the 3 months I was traveling in Japan.

Last week I finally managed to finish the backlog and allow myself some breathing room. I can now put my focus back on Project Echo and get out of this slump.

But first we need to try and understand the problem.

The fact that no one is signing up to the service comes down to three possibilities.

Possibility #1: There isn’t enough traffic to the site

Traffic to the site is low. The screenshot above shows that when filtering out Thailand and South Korea (my best attempt to filter myself out of the data), there have been less than 100 unique visitors to the site. Some of those are existing users, readers of my Substacks, and fans who want to check if the numbers have moved on the Open page. The absolute number of potential users visiting the site in the last 4 weeks is probably 25 to 50 at most if I had to guess.

Assuming a conservative 2% conversion rate, that would be less than 1 expected signup. You don’t even need a lot of variance to acknowledge that having zero new signups during this period is reasonable considering the low traffic.

Possibility #2: The website is hurting conversion

Before landing in Thailand I spent a full day rebuilding the Project Echo homepage. I also added a lot of supporting pages to help with conversion and SEO / AEO.

The feedback I received on the new homepage was positive but I still think its weak and hurting conversion. I’ve decided to hire a very talented and experienced designer I’ve worked with before to redesign the look and feel of the site.

It’s going to take a few weeks before this project is done but when it is, I’m confident that I can eliminate this possibility from the risk.

Possibility #3: The market has changed and there is no longer any demand for tools like Project Echo

This one is hard to assess but I don’t believe it’s the case. I don’t see anything in the market that would make me believe that the product feedback management space is dead.

If anything demand should be up. The number of SaaS products being developed is growing exponentially and the need to collect, manage and prioritize product feedback and requests is an “evergreen” need.

My competitors are still active and publishing updates.

The bottom line is that I believe I’m dealing with a combination of low traffic and poor visitor-to-signup conversion.

I’m going to work on addressing both of these in parallel. I want a new, beautifully designed homepage simply because I can’t stand looking at the current version. A new and improved homepage can only help. I don’t mind spending a bit of money to address this need.

Solving the traffic problem is much tougher. It’s a major chicken and egg problem.

I need a scalable traffic engine but building one takes a lot of time and focused energy. SEO takes 6 - 12 months to see results, and since I don’t have signups, I can’t rely on product-led growth and word of mouth.

I need to spend more focused time marketing the service but finding that time has been challenging.

One marketing-related project I did complete recently was the development of a free tool to help with SEO. I built a fully functioning, interactive MRR calculator. Give it a try.

Developing free tools is a common SEO growth tactic but just like content marketing in general, it takes time for these tools to gain backlinks and SEO authority. When it works it works really well, just ask Hubspot and PandaDoc (see examples of how these companies use free tools in the post below).

I’ve also started to post more frequently on X with the Project Echo account.

I’m slowly systematizing all my content creation and part of that plan is to become a lot more consistent with posting about Project Echo on social media.

The final growth tactic I want to mention is using DMs on X to promote Project Echo. I absolutely hate cold outbound so I’m only doing this when it is a natural continuation of a prior engagement with the individual. I want it to be as organic as possible and not appear too aggressive.

So far it’s worked well but not easy to do at scale.

I’ve been taking X a lot more seriously lately and my numbers are looking very good!

My audience of potential Project Echo users is growing every week and I know I just need to keep pushing, learn as much as I can, and to give it time.

A week ago Nic Polotnianko, the founder of Sequenzy, shared that his SaaS had passed $10k MRR just 9 months after launch.

Nic is an incredibly hard working and experienced SaaS operator and I’m glad I’ve been able to connect and learn from him.

The bottom line is that Nic has the skills to grow a SaaS to $10k MRR (he’s done it twice now) and I don’t. Not yet but I’m working on it.

That’s it for this week friends. Thanks for reading.

Justin

PS: If you know a SaaS founder who is struggling to grow their app, click the button below and share this post with him or her, I’m sure it will make their day.

Share

I started to use Stripe back in 2022 when I made my first SaaS acquisition.

Four additional acquisitions, over 6-figures in SaaS revenue, and years managing hundreds of subscriptions has taught me many interesting lessons.

In this post I’m going to share with you some of the advanced concepts I’ve learnt working with Stripe.

Lets jump right in.

Advanced concept #1: Stripe can be used to track multiple steps in the core funnel

The core funnel is a product analytics concept I first covered in my BI blueprint for early-stage SaaS post.

In a nutshell the idea behind the core funnel is to map the major steps in the user’s lifecycle and structure it as a funnel.

In the video above I share a very standard “core funnel” of:

Signup —> Completed onboarding —> Wow moment —> Started trial —> Paid —> Paid again.

Payment service providers (PSPs) are typically the source of truth for later stages in the core funnel, namely “started trial”, “paid”, and “paid again”.

Stripe can however be used to cover more steps in the funnel, even the first step, signup.

Stripe in of itself is structured kind of like a funnel. The first entity that is relevant is “customer”.

A customer in Stripe then gets a subscription which has a payment method. Invoices are then created for the subscription and finally we have transactions which are related to invoices.

It’s possible to set up your apps backend so that when someone signs up, or installs your app, like in the case of a Slack app, that they are created in Stripe as a “customer”.

I have a number of Slack apps that are set up this way which means that I can easily see how many new, unique Slack workspaces have installed my apps directly in Stripe.

There’s really no down side to push new signups into Stripe. It really comes down to how you define things internally.

You may prefer to define “customer” as someone who has entered their credit card; in which case you create the Stripe customer record at that point in time and not earlier.

I think this approach works best for marketplace apps like Slack apps where you expect the user to interact with your app within the host platform, and not your own web-based interface.

Advanced concept #2: Churn trend analysis, and MRR “bleed”

Many SaaS founders don’t truly understand the difference between churn rate, new MRR, MRR “bleed” and net MRR growth.

Thankfully Stripe gives us the tools we need to make sense of all these numbers.

Read more

I’ve had a busier than normal last two weeks finishing up my time in Seoul, spending time with a good friend in Bangkok, and getting settled in my new home for the next 6 months, Chiang Mai.

Now that I’m done with traveling for the year, I’m more than ready for a highly productive period where I can push this newsletter to the next level.

So how are things looking at the moment for SaaS Decoded?

At the time of writing, SaaS Decoded has 28 published posts, 141 email subscribers and 206 Substack followers.

You can see that the follower count has risen quite sharply over the last 2 weeks, mainly thanks to Substack pushing the newsletter within their network.

The newsletter did also recently receive a recommendation by MRR Unlocked, Alexander Estner’s GTM-focused Substack.

New subscribers of MRR Unlocked are now being recommended SaaS Decoded which has helped get the newsletter some new subscribers.

Make sure to check out Alexander’s substack if you’re looking for help with your GTM strategy and implementation.

All-in-all I’m happy the newsletter is reaching more people very month and I’m excited to see how things look in a year from now.

It’s time to monetize

I’ve decided now is the time to start monetizing SaaS Decoded.

Up until now all the content I’ve published on the newsletter has been free, but moving forward I’ll be publishing a mix of free and paid posts.

To read the paid posts, you’ll need to become a paid subscriber of the newsletter.

Currently there are three plans, a monthly plan for $14, a yearly plan for $99, and an insider plan for $299 a year.

I’m offering a one-time discount to you, my early readers, of 25% off the annual subscription. This means that for $74.25 a year, you’ll have access to the entire SaaS Decoded library, including all paid posts I publish.

To take advantage of this discount, visit https://www.saasdecoded.com/cfc93481, enter your email and you’ll then see the subscription options.

This discount is valid until the end of the month and then will be gone forever.

I’d like to give a shout out to Luke and Chris, the first two paid subscribers of SaaS Decoded. They both subscribed to support the newsletter early on, even though I hadn’t yet published any paid posts.

So why now?

Back in January of this year I published a post on my other Substack, Coffee + Revelations, covering my desire to make a complete pivot away from consulting to content.

Coffee + Revelation

The time has come for a big change

Hey friends…

Read more

9 months ago · 6 likes · 4 comments · Justin Butlion

Now that I’m 8 months into this transition I’ve learnt many key lessons.

The main lesson I’ve learnt is that building a newsletter takes an incredible amount of work, patience and grit.

It’s a game of gaining awareness and trust in a world of unmeasurable distractions and noise.

I’ve had to completely switch my mindset from thinking, “why is the newsletter growing so slowly”, to instead celebrating every new subscriber and follower.

I’ve also developed the habit of reminding myself that those that win this game are the ones who simply didn’t quit and push through the “valley of despair”.

Coffee + Revelation

Crossing the Valley of Despair

Hey Friends…

Read more

7 months ago · 4 likes · 2 comments · Justin Butlion

In the content game, the real gains come years after starting.

I decided a few months ago that 200 followers was enough proof that SaaS Decoded was serving a need in the market, and that I could start monetizing through subscriptions.

The fact that the newsletter has a >40% open rate and is growing month over month, with few unsubscribes, tells me there is product-market fit.

Now that I’ve passed the 200 follower milestone, it’s time to make this change.

One argument against monetizing is that it will hurt growth, but based on my research, this belief doesn’t seem to hold any water. If anything, publishing paid posts sends a positive signal to the market that could help increase traffic and word of mouth.

I’ve also read time and time again from very successful substack writers that they wished they’d monetized sooner.

This change will also force me to raise my standards and make sure my content is so good that people will literally pay to read it. That’s a bar I want to set and thankfully Substack gives me the tools to enforce it.

The last main reason to start monetizing is because there’s really no reason to hold myself back from making some money as the newsletter grows. Money is a strong motivator and seeing my monthly recurring revenue grow over time is not only incredibly motivating, but ties directly to my main business goal; getting to $20k MRR.

Coffee + Revelation

The Empire In Review #2

Hey Friends…

Read more

a year ago · 1 like · Justin Butlion

I want to get to the point where SaaS Decoded is paying me enough from subscriptions and affiliate sales that if all my other businesses went to zero, it would still cover my living expenses.

The Vault is growing

A quick reminder that all of you can take advantage of the many perks in The Vault, my benefits program for SaaS Decoded email subscribers.

The number of perks has grown to 11 and my goal is to hit 25 before the end of the year.

The latest addition to The Vault is Sequenzy, an amazing email platform for SaaS, built by a very talented indie developer, Nic Polotnianko.

I still need to add the subscriber-specific perk to The Vault so if you decide to sign up to Sequenzy via the link above, just send me a short email and I’ll make sure you get the perk once it’s available.

I plan to publish more content about Sequenzy since I’m now using it for my own SaaS, and it really serves a big need in the market.

Subscribe now

What else has been happening?

Here’s a quick list of some things I’ve been thinking about, playing with, and investigating.

1. I spent about 8 hours this weekend setting up my AI workforce using Grok Bot. It’s amazing and you should definitely give it a try, especially if you’re already paying Cursor.

   

2. Project Echo is a bit stuck. Traffic is low and visitors aren’t signing up. It’s a source of frustration but I’m still in the fight and will share more in a future post on what I’m doing about it. Check out the most recent product updates here - https://feedback.projectecho.io/changelog/linear-integration-votes-tab-deep-linking

   

3. If you’re curious how I’ve seen the 1st half of 2026 across all my businesses, check out the post below.

   Coffee + Revelation

   1st half of 2026 in review

   Hey friends…

   Read more

   3 months ago · 1 like · Justin Butlion

That’s it for this week friends, thanks for reading.

Justin

Subscribe now

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

7 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

a year 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

a year 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