[tyrw]

> Large companies didn’t want it enough to deal with our lack of “big company features” (enterprise SSO, compliance certifications...

> We spent a bunch of time on multi-tenant infrastructure...

I'm in a position where I talk to SaaS businesses all day about both of these. Probably over 1,000 at this point.

We help a lot of these companies add the enterprise features they need, but it's often a shame to hear they're just going to do standard login or build multi-tenancy themselves. Trying to sell to enterprises without meeting them where they are on login & compliance is asking for failure.

I think a lot of founders and early employees are true believers in their value prop, and in this case it blinds them to the fact that there are people in the world like enterprise CSOs who simply don't care and will shut down a product for any number of security reasons. You have to check the boxes, and figuring out what those boxes are on the fly is painful and costly.

[danielmarkbruce]

"build multi-tenancy themselves".... this is a weird thing to say. In the modern day, what product company builds single-tenancy..? Even if a customer explicitly wants it, you can make multi into single easily. The other way around is difficult.

[tyrw]

Depends on the app and the context. A lot of apps need multi-tenant access control but not necessarily separate containers etc. In those cases, "adding" multi-tenancy means maintaining an Organizations table, a Roles table, and a table to map them to Users.

[danielmarkbruce]

Maybe it's just different worlds, but in my world people wouldn't consider an app using isolation via containers etc "multi-tenancy". It would be a single-tenancy application. But I guess there are are hybrids these days with such granular database options in the cloud etc.

[DylanSp]

Question about multi-tenancy - do you recommend starting with a single-tenant approach, or are there off-the-shelf options for multi-tenancy that you'd recommend using, instead of building it from scratch?

[tyrw]

We build a system that is multi-tenant capable but can run as single tenant until you need it. Happy to chat if helpful

[paraknight]

Not sure how to DM on here, but I just checked your landing and wanted to ask in what ways you're better than clerk.dev?

[tyrw]

Clerk is great for new builds in the react ecosystem. We focus on more complex use cases where there are multiple user types (e.g. freemium, enterprise, partner, internal), multiple applications, or both. Having everything in one system removes a lot of tech debt and helps teams move faster.

And by "happy to chat" I meant by my email in my bio (which I just added to the public part), if it'd be helpful!

[thenobsta]

I'd love to hear more insights about on this. I'm just kicking off a B2B SaaS, have a rough idea of the checklist in my head, and am trying to balance core tech development with box checking.

[louthy]

GDPR & ISO27001 compliance are the important ones, but depending on the industry there maybe others (HIPAA for example). You need to hire an advisor and start writing everything down. Being able to hand over compliance documentation along with proof of an audit is absolute gold. If you don’t do this, be prepared for a mini-audit on every sale (if you get that far).

Sales to governments will likely come with even more compliance requirements, national security audits, and potentially staff vetting. It’s not worth it early on unless you’re really well funded.

Compliance does actually scale with the business, so it’s not particularly onerous at the start. Although it can get out of hand if you’re not careful. Compliance should be pragmatic.

SSO is clearly one of the major factors for integrating anything into an enterprise organisation. Their IT team will want to have complete control over who has access, when somebody leaves the company they want to make sure that they can shut them down immediately, not have to reach out to third-party providers, or login to multiple systems. Ignore this at your peril.

Independent penetration tests are also really important.

You can usually resist requests for self-hosting or multi-tenancy if you have all the above, but not always. If they don’t think you’ll be around tomorrow, then they won’t touch you.

[magicalhippo]

> If you don’t do this, be prepared for a mini-audit on every sale (if you get that far).

That's the position we're in, though as an older but still growing B2B we have to do this for existing customers as well.

We're in the process of getting ISO27001, meanwhile we got one guy out of 40ish almost full-time answering such questions now.

[louthy]

It never stops, but at least with evidence of audits, evidence of pen tests, and policy documentation, it can be a little easier!

[louthy]

Edit: meant to say self-host/single-tenant in the last paragraph.

[tyrw]

Sorry I got busy today (more convos!). I'd be happy to chat or email and try to be helpful -- if you want you can check my bio.

[jprokay13]

If you are going after enterprise early, I highly recommend putting them on their own system instead of in a multi-tenant system. Enterprise wants 30 days of immutable db backups? They need to be able to rollback within X time? They want guarantees that other people won’t affect them?

This all becomes easier if you turn it from an engineering problem to an operations problem. Enterprise really cares about how you operate in order to guarantee they won’t be negatively impacted by your system. SOC2 is much more about your operations than anything else.

My recommendation: have a multi-tenant system for the plebs and bespoke deployments for the enterprise. Save yourself the headache of trying to satisfy both with the same infrastructure.