Personally, there's no way I'd want a customer initiated operation to trigger something like terraform or mess with DB schemas. On the security side, it would significantly complicate the permissions structure from the application to the database. And on the performance side, I have absolutely no mental model for how operations like that scale, and how trivial of a DoS I'm exposing myself to. At the same time, I love the isolation (mostly operationally, the security & privacy side is also nice) that db-per-customer would bring. If this product helps bridge the gap, then it sounds good to me.

Last project I worked on was a mix of on prem software and cloud software.

The cloud counterpart had 600+ mongodb databases split amongst 3 Mongo clusters.

The integration team took usually 2 weeks to setup the on premises software, and the cloud stuff took about a minute. The entire setup for the cloud was a single form that the integration team filled in with data.

The point I'm trying to make, is that if your customers require separate infra, they can wait a bisuness day to be setup. Meanwhile they can play on a sandbox environment.

It's also doable in fully automated fashion, but you will have to have strong identity and payment verifications, to avoid DoS, and in those cases usually contracts fly around.

That's for the b2b side.

For b2c, usually you rely on a single db and filter by column ID or similar, which can easily be abstracted away.

You rather explained the value prop of this product then. The benefits of isolation without the 1 business day wait.

What exactly is the value prop tho? To a technical person 1 business day wait seems dumb, but few businesses move that fast where waiting a single day matters.

But it'll take 10 business days to get an OK from management and other departments.

you might consider that it's precisely your depth and breadth of experience, which isn't common across most teams, might actually highlight why a solution like Fortress is valuable

A blog post explaining these two common approaches would solve the same problem though

"Speaking as a dev with over 12 years of experience in both dev and ops"

I think you aren't the target market. The target market is probably people who are new to coding or even self-taught indie hackers who aren't too technical but oriented towards building a product as quickly as possible

OK I have been the ultimate decision-maker in a number of SaaS vendor selection situations so I am the target market for people who would build an offering using this. I can tell you that multi-tenant shared anything is pretty much an absolute dealbreaker for me and most people like me. Why?

1) In any financial regulated environment your regulator will usually specifically require this (at least in jurisdictions I'm familiar with). Am I prepared to go to battle with my regulator on behalf of a vendor? Most definitely not.

2) Even if I'm not in that situation, do I trust the vendor to have tech protections that work well enough that my customer data won't leak if there's some sort of problem, leading to a GDPR/data protection nightmare? No. No I don't trust anyone that much. I wouldn't even trust code that I myself had written that much (ie when I have built b2b saas solutions I have insisted on single tenant shared nothing). I've actually used (a demo of) a multi-tenant saas where the vendor has insisted on the security of their multitenant solution and been shown another customer's data on more than one occasion.

3) Even if I did trust the vendor and wasn't in a regulated environment which required single tenant, would I be prepared to go to war with my internal legal counsel over the data protection implications of multitenant? No. I want to keep a good working relationship with them and their life is hard enough as it is. They want single tenant shared nothing that's good enough for me.

4) Even if none of the above applies a lot of big corporates will want the option to host a solution in a cloud subaccount that they own. That's clearly not on the cards with something like this.

As someone whose background is primarily in embedded systems, how common are single tenant SaaS architectures?

The only webapps that I've released commercially were all intended for internal use by a single customer, running on their private hardware, with usually only a single login, so I'm about as far from this space as you can get and still be a dev...

I was always under the impression that most SaaS was multitenant, with the individual tenants sharing tables, but being disambiguated by customer ID. Am I that far off?

A lot of "enterprise" b2b saas systems with relatively low customer numbers, relatively high ticket price per sale are going to be single tenant. Think things like core banking systems[1] which have very sensitive end-customer data (in that case balances and transactions) in them. No bank would be allowed by their regulator to put that in a multi-tenant system even if they would want to which I don't think they would.

Also any system which could notionally be multitenant but the customer is a tech-savvy large enterprise and wants to bring their own cloud. That's de facto single tenant because they're not going to host anyone else's instance are they? So where I work there are a few saas vendors we deal with where we have set up AWS subaccounts where they have some access and they host an instance of their thing in there just for us. Saas vendors will frequently do this if the contract /client is valuable enough, so it's pretty common in an enterprise context.

[1] Mambu, Thought Machine etc

Is there a list anywhere of these types of checks you do which are critical to approving a saas vendor?

I don't know, but search for "saas vendor due diligence" and you should find a bunch of stuff. Every big corp I've been in the approval seat has a different process so it's not standardized for sure but generally the basic process is the vendor sends out the questionnaire as an excel sheet and provides a box folder or something to dump the evidence in, and then there are a couple of zoom calls to talk through any questions or concerns. There are certification type things like iso 27001 and isae 3402[1] and although they make this process easier because you will rip the bandaid off and take all the pain in one hit I wouldn't recommend a startup go for those right away[2].

[1] https://isae3402.co.uk/isae-3402-and-iso-27001

[2] Going for them will suck up a lot of energy, focus and time and you can't really tell which ones your clients are going to ask for in what order so there is the danger that you get the priorities wrong which would be a bad mistake in the early stage of a saas startup. So what I would recommend is you read through those and whatever nist guidelines and stuff like that and bear them in mind as you build your product, then start researching who you will get to do your ISAE/ISO27001/SOC1/SOC2 audit when you need one, then when the first client says have you got ISAE3402 (or whichever other one) you say "we're working towards it" (which is true) and as soon as you get off the call with your client call your preferred audit vendor and start the process. "We're working towards it" is an acceptable answer for most big corps because they know the process is slow (iirc it takes a minimum of 6 months for any of those because you have to demonstrate the process over time) and they are slow anyway so they don't mind it taking a minute for you to get it done. Then once you have one, the next time a client asks you for that one you have it, and if they ask you for a different one you say "we have <x> already and are working towards <y>" and rinse and repeat. It's going to be easier this time because you'll be able to repurpose some of the stuff you produced for the first one for the second and so on.