I recently decided to start a Six Saas in Six Months project to showcase the possibilities with Parthenon while possibly creating extra revenue streams.
The idea is I build six different SaaS applications within a six-month time period. This will provide me with some solutions to problems I already have, SaaS platforms that can be bundled with Parthenon to provide extra value, and a chance to QA Parthenon fully with applications. If any of the SaaS gets traction and generates €500 revenue, then I'll stop and focus on that SaaS to build up.
1st SaaS - RepoHealth
Website: RepoHealth.io
This was created to solve problems I experienced while developing Parthenon. It allows for sending Slack notifications based on how GitHub Action jobs finish.
The Problems I experienced:
- Only being able to every failure or every success.
- Not being able to trigger other workflows in other repositories upon the success
How I solved these problems:
RepoHealth installs a webhook onto chosen repositories so that when a GitHub Action is updated, it sends an update to RepoHealth.
Then RepoHealth allows you to choose when you want to receive a slack notification. The options are: on every successful job, on every failed job, when the build goes from success to fail for the first time, and when the build goes from was unable to succeed.
Then RepoHealth has options to trigger other GitHub Action workflows when a workflow has been successfully built.
How it went.
- One week of development to build the MVP to launch.
- Week two, I added more features, such as custom messages and the build triggers. I got 100 visitors with 0 signups.
- Week three, I added some fun features such as weekly git stats announcements. Did some marketing. I got 30,000 visitors to a blog post, 300 of which went to the landing page, 2 of which signed up, 0 paid.
Two issues:
I had two marketing ideas which needed development, both of which ended up not really being that feasible.
One was to go on the GitHub marketplace. This wasn't feasible because GitHub has a requirement that paid apps have 100 users before being listed. So to get on the GitHub marketplace, your app already has to be used instead of publishing new apps and getting users that way.
My second idea was to create a tool that would look at a public git repository and give it a score on how active it is. Rating it based on how quickly maintainers respond to issues and PRs, to how long issues and PRs are open. It would provide a score which could be embedded onto the GitHub repository via the readme as a vanity metric. This, however, is quite a time-consuming exercise. If I was just going to work on RepoHealth until it got revenue, then I would continue to develop this tool as it is possible and the problems with how time-consuming it is could be worked around and improved but considering I am building Six SaaS in Six months, it didn't make sense to me to invest that much time and effort into it.
Plans going forward
I've decided to stop focusing on RepoHealth, as it solves the problem I experienced and wanted to be solved. And move on with the next SaaS. The next SaaS will be Blether.chat, a visitor chat widget that can be used with Slack.