The question that matters:

How much work will you have to (want to) do when you get a 3rd tenant?

Figure there's almost never just two of anything -- and there should probably be an acronym for that. Or if there really will never be a 3rd tenant, ever, then arguably both options are are a waste of time.

The answer for your situation depends on stuff you haven't specified, e.g., how much are the various tenants are likely to differ, how much pain is involved in writing a new class for (1) vs. a new constructor call for (2), or the extent to which it's appropriate that new tenant configuration be data-driven rather than code-driven (which would argue for (2)).

Not knowing any of the details, I would fall back on my own prejudice that I generally find inheritance to be overused (and would thus prefer something like (2))...

... it may seem "simpler" to just define a new subclass so that you can re-use a given piece of code, but if this governs how your hierarchy develops, then you risk ending up with a spaghetti hierarchy that's actually more difficult to maintain, whereas if you take the time to figure out where the code in question actually needs to live (so that it'll be where people are expecting to find it), that makes life simpler in the long run.

And one can, of course, take this too far and waste time pre-designing for cases that are never actually going to arise. YMMV