Managing SaaS / Software-as-a-Service Subscriptions - in Stripe or Otherwise

Hi!

Has someone managed to successfully implement a production SaaS app in Adalo? How would you manage entire subscription flow with / without Stripe Subscription component? EG if there is any transaction ID sent back by Stripe to Adalo, flags / Booleans to be flipped in Adalo Users Table after stripe confirmation, etc.

I think all the features of a SaaS app are possible to be built in Adalo, but I’m trying to think of the right way to implement User Management within the platform and minimize using external services (Zapier, Airtable, Zuora/Recurly, etc).

Appreciate if anyone can help.

SaaS for apps? Or would you build a app in Adalo for the user to manage their subscription to a 3rd-party SaaS solution?

Build a Product within Adalo to offer as to customers as a SaaS…
Not the 2nd option you mentioned

@tjd_15 did you get any further along on this? Curious if subscription flow was the only sticky point for you. I’m working on exact same.

Yeah I’ve discussed this with Ashley from Adalo, but haven’t found a straightforward solution.

There are just too many possible states of subscription, upgrade, downgrade, cancellation etc. to be covered entirely by building something within Adalo as a user vs. Adalo offering it as a fully functional module. In my case I think building something is a little more risky in case some use-case is left out as not built.

Best solution I could think of - You need to separate the gating from the Adalo App itself. Gating happens at Site A, and App is hosted at Site B.

You should have all your gating externally (because you can’t pass login information from another service into Adalo), say Webflow checks for a Unique Account ID, use Memberspace for gating a webpage which redirects to Adalo sign-in links (eg buttons to login to your app), and then users are able to access your Adalo App by logging in with their email & password.

  1. Within Webflow, you would have to constantly update Adalo App Link
  2. Within Adalo, you would have to make copies of your app every week or so, and paste the new link into webflow, and delete ‘old’ apps

This is done so that your users don’t bypass the gating mechanism in webflow by bookmarking your Adalo app domain (where previer.adalo… or your custom domain), and just access the app directly via the bookmark.

Creating copies of new apps and deleting would ensure even saved bookmarks would stop working after a while, and only paid members would have access to the latest ‘builds’ or links of your app.

Ideally you should not have a custom domain, and use only adalo’s previewer… sub-domain, to avoid the bookmarking of sub-domain for permanent access without paying subscription.

Worst case scenario is a non-paying customer is able to access your previer.adalo.com app for a duration until you delete it and replace with the latest version of your app. So it depends entirely on your build/update frequency.

To summarize - www.myapp.com (in webflow) -> Entering Unique ID leads to accessing app.myapp.com -> on this page is the a button, which links to most updated & only active version of your app, hosted on previewer.adalo.com…, which you keep replacing by making new copies of your app very frequently.
This would still involve a user going to your www.myapp.com domain, entering a unique userID, then one more click, then entering email & password, then one more click to access app, which is terrible UX.

Its ugly & got too many moving parts, even I have not implemented it. But its the most reliable solution I could think of thus far.

1 Like

Thank you for the generous walkthrough! Glad to see it’s feasible but it will be difficult to manage this so diligently on my end. And, from a UX standpoint, I’m not certain I can get away with it but I’ll need to think on it some more.

I connected with Ashley briefly but did not go into great detail about what I’m looking to accomplish. Waiting for some clarification and in touch with Stripe. I have an MVP built on another platform that’s live - the app’s in use - and I have regional pilots around the corner.

At this stage, I’m slightly less concerned about perfecting subscription payment (not charging yet) than figuring out if it’s possible to deploy a single app that can accommodate more than one use case. It’s not sustainable to continue doing it as I have been given increasing participation.

Use case #1: App is used by an individual Seller, transacting with their individual customer base (existing and new, not a global pool of customers).

Use case #2: App is many-to-many; think multiple vendors at a popup market as Sellers. Effectively a marketplace.

This is what I am thinking about now. I want to launch a subscription only app available on iOS and Play. I want members to be able to sign up on a website and then download the app from the app store. This is how Netflix does it.

Following this thread for future updates.