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

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