How to run several SaaS products with one admin

The first product gets an admin page because you need one. You need to look up a user, fix a plan, and see who signed up this week. It takes an afternoon.

The second product gets a copy of that page. The third gets a copy of the copy. By then you have three logins, three sets of tables that drift apart, and none of them show revenue, traffic, or errors. Those live in Stripe, PostHog, and Sentry, in three more tabs per product.

Here is a way to set things up so the next product costs you almost nothing in admin work.

1. Decide what "admin" actually means for you

For most small products it is the same short list:

Look things up. Find a user, their plan, their recent activity.
Fix things. Grant credits, extend access, resolve a report, publish or unpublish content.
Watch things. Revenue, signups, active users, errors, search traffic.
Know what changed. Who did what to which record, and when.

Write that list down for each product. You will notice the products differ in their records, not in the shape of the work.

2. Separate your records from your tools

Your product owns its records: users, subscriptions, content. Your tools own everything else: Stripe owns payments, PostHog or Google Analytics owns traffic, Sentry owns errors.

A good admin setup reads the tools and asks your product for its records. It should not copy your database, and it should not need a database password. Expose a small, explicit list of records and actions from each product, over HTTPS, behind a token.

3. Make every change a named action

"Edit any field on any row" is how data gets broken at 11pm. Instead, give each change a name and typed inputs: grant_credits(userId, amount), extend_access(userId, days). Named actions are easy to confirm, easy to permission, and easy to record.

4. Record the before and after

For every action, keep who ran it, which product, which record, the time, and the exact values before and after. When a customer asks why their credits changed, the answer should take one search. We wrote more about this in what an admin audit trail should record.

5. Put the numbers side by side

The reason to keep products in one place is comparison. Which product grew this month? Which one has a spike in errors? Which one lost search traffic? That only works if revenue, users, errors, and search sit on one screen with one row per product. If you are adding up MRR across several Stripe accounts by hand, this calculator does it in a minute, and this post covers the details that trip people up.

6. Make the next product a config change

With the above in place, launching a new product means describing its records and actions once and connecting its tools. No new admin pages, no new auth, no new tables of logs.

Doing it with LopeBase

This is the setup LopeBase is built around. Each product connects through a small adapter you host, connectors read Stripe, PostHog, Sentry, and the rest, actions run with a confirm step, and the audit log keeps the before and after. We built it to run our own products.