We are building a service that will provide authentication and payments to saas. The idea is that authentication and payments are necessary for almost any saas, but they are not part of the core set of features.
By providing this as a service our idea is to help saas developer to focus on what really matters and launch faster.
In addition by putting authentication and billing into one single flow we think that saas developers do not need to write the glue code to link two different set of features (or two different products like Auth0 and Stripe).
Anyone want to help me to validate?
Some candid feedback, many companies trying to do the same thing as yourself have come and gone in last 3 years.
The future of SaaS is something like https://supabase.io/
I run https://versoly.com/ and have a lot of paid SaaS customers. They want flexible designs (and building a page editor is hard).
If I was to start a new SaaS today I would use
I would look at building team management features on supabase (not sure how you would monetise). But that is a huge issue. Companies spend months rebuilding their MVPs to do it.
supabase.io looks cool but maybe i'm not understanding what's so special about their offering?
You can do what they offer for cheaper no? Use Firebase for authentication, and use AWS Lightsail for postgres that's cheaper than 25% a month and has a larger storage size of 8gb
Hey, thanks for the feedback, any comment is pure gold :-).
We know that there's competition and we agree that serverless is going to be part of the future of saas.
What we are trying to build can be easily part of the serverless approach, because it is external to the saas itself. The idea is that it handles the things that happens before your users arrive into the saas; then the saas itself can be done using any technology you like.
The flow should be something like:
The flexible design of the pages is something that we are considering. We know that building a page editor is hard, and we are not trying to solve that; we are giving the possibility of using custom pages for any step and we are thinking about providing pre-made themes and boilerplates for the various CSS frameworks so that it's easy to build your own custom page.
Why not just let the auth happen on app. ? What is the benefit of doing it on the marketing site?
Why would you spend time recreating the wheel? (templates)
I would ask myself where can I add value.
The marketing site is there new users land when they discover your product and where existing users arrive and push the login button. If they already are authenticated they are redirected to the saas, if they are not they are shown the landing page or the login/signup form.
The idea is that authentication and payments are two things that goes together well. You usually want users to enter you saas if they are known (authentication) and have a valid plan (payment) and if the developers use two different tools/services/libraries, then they have to write code to match the two things.
We are trying to get this overhead off from developers shoulders, so they can focus on what they really care (the core features of the saas). In a sense the value we add is the time that developers save, so they can launch faster.
I hate that so much when you go to the home page and get redirected to the app.
I would much prefer Supabase or as the other commenter said use the auth with the framework.
If you really want to save developers time look into team functionality as mentioned before at that stage companies have money and it is a huge problem.
I agree with everything Volkan has said above. Only slight disagreement I have is that I think there is value in having users authenticated on the marketing site – not for redirection to the app, I hate that too – but so you can show different or customized content to logged in users.
That said, I think this is a really tough idea, I would not recommend pursuing it.
Interesting, similar to what Stripe does.
I don't feel it is overhead. Any framework the developer is using has authentication baked in already. And payments are either easy to add, or you can buy a one-off package (probably around $100) to jump start that part. I believe there will always be a place for more advanced solutions like https://auth0.com/ but I think you are probably targeting a different end of the market?
Who is your target buyer?
Ideally people who want to start a SaaS and want to focus on core features and not on things they must have (like authentication and payments), but are not really part of the offering.
Of course as other have noted we cannot compete with Auh0, but we are open source (so you remain in control of your data and users) and we apply a 80/20 approach: we are providing the 20% of the features that should cover most of the use case and we try to do this in an integrated and organic way, so that you integrate literally in minutes and then you (theoretically) should not worry about authentication and payments anymore.
Does this make sense to you?
It sure does.