turning your replit app into a SaaS for multiple clients? here’s what to set up first

one of my clients was paying $50k a year for purchase order software.

they run multiple stores. been working with them for over a year now. and that software drove them nuts. couldn't tweak it. couldn't request features. every "can you add this?" got a polite no or a "maybe next year."

so they built their own on replit. exactly the workflow they needed, nothing they didn't.

then other store owners saw it and asked "can we get that too?"

and just like that, a $50k expense turned into a product other businesses want to pay for. it's not an internal tool anymore. it's a SaaS.

that's the part i love about replit. you can go from "this software sucks" to "we built something better" without a dev team. that's real.

but the next step is where most people get stuck. the usual move for client #2 is to fork the repl. then fork it again for client #3. i've seen a founder with 7 copies of the same app. every bug fix, done 7 times. by hand. one copy was 4 versions behind and nobody knew.

what you actually want is one app, one database, many tenants:

• app.yourdomain.com for signup and admin
• client1.yourdomain.com, client2.yourdomain.com for each business

the setup isn't complicated:

every table gets a tenant_id. stores, suppliers, purchase orders, line items, all of it. no exceptions.

middleware reads the subdomain on every request, looks up the tenant, and attaches it to the request. everything downstream uses that.

filter by tenant in one place, not in every query. this is the big one. if you rely on remembering WHERE tenant_id = ? in 60 different queries, you'll miss one. and that's how client2 sees client1's supplier pricing. in a PO app that's the fastest way to lose a customer. postgres row level security or a scoped query helper fixes this for good.

per-client stuff (logo, approval rules, tax settings) goes in a tenants table. not hardcoded.

and a wildcard DNS record (*.yourdomain.com) so onboarding a new client takes minutes, not a support ticket to yourself.

already forked a bunch of times? you don't have to start over. i've merged a forked setup into one multi-tenant app in about a week. messy but very doable.

quick test you can run tonight: log in as tenant A and try to open tenant B's purchase order by changing the ID in the URL. if it loads, that's your first fix.

anyway. it's been a while since i did these but i'm opening 2-3 slots for a free audit + consultation call this week.

best fit if you've got paying users already, or someone's asking to buy what you built and you're not sure the app can handle it.

here's what i'll look at: – your database setup (structure, indexes, how tenant data is separated) – security (auth, exposed keys, whether one client can see another's data) – what breaks when you scale (slow queries, stuff that works at 10 users and falls over at 500)

then we jump on a call, walk through what i found, and figure out what to fix first.

after that it's your call. you can take the list and fix it yourself (plenty of it the agent can handle if you prompt it right), or i can help you with it. either way you leave knowing exactly where your app stands.

drop a comment "help" if you needed

totally free.