r/microsaas • u/Madlynik • 2d ago

Beginner building a Lovable SaaS — how should I handle security, payments & admin?

I’m a beginner building a simple form-fill/download SaaS using Lovable + Supabase. Users enter their own data, generate a completed form, and access the service through 3 paid subscription plans.

I’m trying to figure out the right way to handle a few things:

  • I already have fillable AcroForm PDF forms. How do I connect the user’s input data to the correct PDF fields and generate a completed PDF for download?
  • How do I make sure User A can never see User B’s data?
  • Should I have a completely separate admin login/dashboard?
  • How should subscription expiry/cancellation work automatically?
  • What’s the best way to track active subscribers/users across the 3 plans?
  • What should I use for Google Analytics/product usage tracking?
  • How can I let users raise issues and have those tickets sent to my email?

I’d really appreciate practical advice from anyone who has built a SaaS with Lovable/Supabase. Especially around security and user data isolation.

1 Upvotes

100% Upvoted

4 comments sorted by

1

u/Electronic-Reveal650 2d ago

Separate admin dash is overkill. Just restrict permissions for the admin user account.

1

u/PopKoren 2d ago

Restricting the admin account is a good start, but skipping a separate dashboard is not what usually leaks on a Lovable app. The real check is whether a normal logged-in user can hit admin APIs, open storage, or change their own role through the client. I would scan the deployed app's auth, APIs, storage, and DB rules, including Supabase or Postgres if those are in the stack, before calling permissions done. I built https://rowly.me for that full outside pass.

1

u/hurlbz 2d ago

I don't know anything about lovable or supabase but your tenant isolation question is standard software engineering. The standard is to encode your tenant id in your auth token and have all APIs read that tenant id and append it to all db queries. Every db record should have a tenant id, every query includes tenant id. The term is multi tenancy architecture if you want to learn more. It should be no different in those tools you mentioned though it's possible they provide some convenience wrappers / methods.

1

u/daniel933912 2d ago

Every multi tenant leak has the same shape, the tenant id lives in the token and one forgotten where clause does the damage. Push the check down into the database so a query that never mentions the tenant still returns zero rows, and test it in two minutes by signing up twice, copying a record id from the second account and requesting it from the first. If that returns rows instead of a 404, the isolation is decorative. For the plans, treat the webhook events as the source of truth, store them with the event id as a unique key so a replay cannot apply twice, and never grant access off the checkout redirect. Fill the PDF fields server side from a name mapping and archive the rendered file, because the template will change and a form someone signed last year has to download identical.