What's the minimal set of user stories for a Micro-SaaS MVP?
As mentioned earlier, I am implementing a SaaS-base to be reused for every project idea I have and that makes it through the meat grinder. If you start building something without a clearly defined scope, you will find it very hard to stop and succumb to feature creep. So let’s define the scope an MVP for a Micro SaaS should have.
We have one general area of code that’s always needed in a new project:
- Transport and “glueing everything together” (orm, database & migrations, graphQL/REST, authenticating requests, frontend guards etc.)
- Layout & design
I don’t want to talk technical details in this post, so I’ll skip it. Let’s focus on the business logic side of things. So we’ll have three big blocks of logic on top of that:
- User management
- Checkout, subscription management
- The logic for the SaaS idea itself
User Management
The SaaS base would obviously not include the third point: logic for the app idea. I already completely implemented the first one, user management, by basing my app on a template for SvelteKit, which implements almost everything I need. I changed a few things here and there, but all in all everything is working just fine. So we can check the first big block off the list. The neat thing is, with Ory Kratos we can use cloud hosting but we can also choose to do it ourselves. No vendor lock-in.
This includes the following stories:
- As an unregistered user I want to be able to sign up (with Ory Kratos, this also means email verification!)
- As a registered user I would like to log in to the page
- As a registered user I would like to edit my account details (like password etc.)
- As a registered user I want to be able to change my password in case I forgot it
With the aforementioned template I actually get a lot more:
- Users can delete their account
- OpenID Connect log in (i.e. via GitHub)
And bunch of technical benefits like server-side rendering for this, cypress end-to-end tests, unit tests and nice UX around forms, validations, and errors, amongst other stuff (check it out here).
Checkout and Subscription Management
While I began to implement stripe, I actually started to model every entity I was consuming from stripe in a graphQL schema. I had to tell myself to stop, because I can always add fields and entities I need for specific features. You have to hold yourself accountable and stop if you notice that you’re teetering off. I stopped modelling the whole stripe API of which I needed only a few select entities anyway and voila, I was actually almost done.
What stories do we have for the stripe integration?
- As a new user I want to sign up and subscribe to the service and be able to use it (this entails the stripe checkout as well as a guard to the “subscribers only” pages/functionalities)
- As a subscribed user I want to be able to view the details of my subscription (this means we need to be able to fetch subscriptions, products, and prices from stripe)
- As a subscribed user I want to be able to edit or cancel my subscription and billing details (for this we need to implement the billing portal)
What can be argued about is implementing checking for failed payments. I’ll add that if I have no product idea yet and plenty of time, but this can also be added later. But that’s it (imho) as a first MVP. Users can subscribe, we get money, users can cancel, edit and view their subscriptions. Sounds good to me.
There you have it. A low number of user stories which give you a working MVP including everything you need to get started. It doesn’t sound much, and with the experience with both Ory Kratos (or something similar) and Stripe, you can build this in 1-3 weeks besides your main job. (Yes, psst, I’m leaving out having a nice landing page, templates and a layout etc., but that’s very individual so I’ll skip this for now.)