Multiple Signups allowed and Tenant per signup

[darrenferguson]

Hello,

Firstly - thanks for the effort put into this. It has been really helpful.

I have a suggestion - I'm happy to put in a PR for this - but wanted to run it by you first in case the current implementation is for a reason.

Currently

• Signup: Creates a user and a new Tenant
• Login: I think logs you into an arbitrary Tenant and allows you to change from the top nav

Suggestion

• Add the ID of the Owning user to the Tenant table
• Signup - check that a user with the given email doesn't already own a tenant before proceeding
• Invitation - User is invited to a specific tenant
• Login - Where multiple tenancy is available to the user - they are presented with an option as to which tenant they would like to login as part of the authentication process.

Hope it makes sense?

[tjementum]

Hi @darrenferguson

Thanks for the kind words and for reaching out before making a pull request – I really appreciate that!

First, to clarify: allowing the same email to sign up for multiple tenants is by design, not a bug. Consider an ERP system where each tenant represents a different company – it's perfectly valid for the same person to own or manage multiple companies. That said, you're right that we should handle this more gracefully. The current flow could definitely be improved by informing users during signup if they already have access to existing tenants with that email, rather than silently creating another one.

Now let me explain the current multi-tenant login implementation:

When a user with access to multiple tenants logs in, they default to the first tenant they were invited to (technically the first user ordered by UserId, as all IDs in PlatformPlatform are chronological). If the user switches to a different tenant, that becomes their default for that browser – it's stored in local storage as shown here:

This means a user with two computers/browsers can have different default tenants on each.

Depending on the SaaS product you're building, this may or may not be ideal. A "Select account" screen at login is definitely a valid alternative – I've seen SaaS products do it both ways. I went with the simpler approach to avoid extra UI and logic, but it's a reasonable feature to add.

To address your other suggestions:

Add the ID of the Owning user to the Tenant table – A tenant can have unlimited owners, so a single owner ID wouldn't work. But detecting if a user already owns a tenant is still straightforward.

Login – present tenant selection during authentication – Definitely doable, I just wanted to keep the initial implementation lean.

On the topic of PRs: I've found that external contributions, while well-intentioned, often don't fit my workflow. I like PRs to be merged within hours, not days or weeks – and when feedback requires changes, I can't expect volunteers to drop everything and respond immediately. By the time the back-and-forth is done, I've usually just built it myself using my Agentic Workflow with Claude Code, which writes a full unit tests suite, working end-to-end tests, and follows my conventions perfectly. And I can quickly try a couple different variations 😅 Especially for relatively trivial CRUD features like this. I do work with a few long-time collaborators – particularly on frontend where I need the help.

If you're building something with PlatformPlatform and need these features for your own product, I'd suggest trying the Agentic Workflow with Claude Code (although I'm not sure how well it works on Windows as of writing). But with a single prompt 9 out of 10 times you will get a production-grade solution with unit tests, end-to-end tests, and code that follows all the conventions in a couple of hours.

[darrenferguson]

Thanks for the reply!

It all makes sense - I guess I could change the wording on the homepage - maybe saying "Create a new Tenant" and "Sign in to a Tenant". (or maybe use a more end user friendly term like 'workspace' or 'company'). I guess from a point of extensibility - having some kind of cancellable event pattern may be a good addition - custom code can subscribe to events when entities are about to be created etc and do their own checks (or maybe Mediatr pipeline behaviour).

I did have brief attempt at the Claude workflow - but there is something not quite right with the communication between agents. Initially the co-ordinator tried to delegate out to the backend engineer and hung. I somehow managed to get that delegation to happen (I think I pressed enter in the backend-engineer agent) and it started working on the task. When it was done, I couldn't repeat the trick I couldn't get it to delegate to the next agent, I ended up hung again. I haven't really spent much time trying to work it out - but I think it is just MCP server to agent communication.

I guess from your comments on your workflow though, that this is more of a curated project than an OSS with a lot of active contributors. Do you see it as something people would base real projects on - or maybe just a useful reference point? I'm imaging getting into trouble trying to take later updates from your repo and getting lots of conflicts if for example I've updated login and registration :)

I'd already started to look at a PR that localised email content and subjects and allowed you to use files for templates - but by the sound of it the best thing to do is to discuss things here and maybe see if they are on your roadmap?

Thanks again for publishing this - it has been really useful to date.

Darren.

[tjementum]

On the wording – I use "Tenant" in code and "Account" in the UI. The distinction between creating a new account vs signing into an existing one is already clear in the current UI, but I understand the underlying concern: if an existing user forgets they have an account, they might sign up again and end up with two accounts. That's a fair point, and informing users during signup if they already have access to existing accounts (as I mentioned earlier) would address that. It's on my radar, but not something I'm prioritising right now.

As for the cancellable event pattern / MediatR pipeline behaviour – I'm actually planning to add distributed event and async command support between self-contained systems in the near furture. I already have this running in a downstream project, but it's not production-grade yet. I'll likely do this in multiple iterations – things like dead-letter queues, reconciliation, and message versioning contracts might be postponed to later iterations. So some of what you're describing may become possible once that's in place.

I have clients building on PlatformPlatform that I help, so I often avoid breaking changes because it's a hassle to propagate them downstream. At the same time, I don't want to be in a position where I can't evolve the tech stack or architecture. It's a balance. For example, I'm very likely going to change the frontend from React Aria Components to ShadCN, which will be a big "breaking change" (there's an open branch with work in progress).

So you're completely right if you think of this as a reference architecture or boilerplate. You take a copy of the code, and then you make it your own. If you avoid making changes to Shared Kernel, Shared WebApp, and Account Management, you will be able to pull updates from PlatformPlatform, but realistically, you will make some changes. I'd claim you can kick-start a SaaS product quite significantly if you build on PlatformPlatform, but only if you value the architectural choices and have the need for what it offers. The target audience is senior engineers, and these people often have their own ideas and opinions (it's called experience 😅) that likely does not align with mine. So while this is 100% open source, I'm not actively seeking contributors, as it's unlikely that qualified engineers will share my opinions unless we've worked together. Almost all contributors are people I've worked closely with in the past.

I will say that there are things in PlatformPlatform that the majority of startups don't have in their product/platform – things that are required if you want to build software for enterprise customers, and things that provide a great developer experience that I've yet to see at any company I've worked with or helped. But PlatformPlatform lacks documentation, which means it's hard to get started if I'm not personally helping. I'm also well aware that it's not feature complete, so there are still things you have to build yourself. In the coming months you'll see me catch up quickly on many of these shortcomings.

The clients I'm helping, use the pull-platformplatform-changes CLI command to pull changes from PlatformPlatform into their projects. But it's error prone, and if you made even the smallest changes you'll get merge conflicts. I'm considering building an AI agent that can help with pulling changes, but it will never be perfect.

As for your experience with the Agentic Workflow, from what you describe, I suspect you're running on Windows. I've only tried it once on Windows, and it wasn't a good experience - the agents started new windows, and it was very confusing, and as you described, it did not really work. I hope to improve this in the near future. However, if you're on Mac, you should be able to get it working by first creating a branch, then starting all the agents in separate terminals.

Regarding email localisation – I actually have it all working in another system built on PlatformPlatform. But I'm not happy with the templating approach and the flow, so it's not something I want to prioritise right now. I have a few higher-priority items that are blocking some downstream projects.

I hope I addressed all your comments :)

[darrenferguson]

Thanks again - it all makes complete sense.

It would be a real challenge to maintain a democratic OSS with multiple contributors (and multiple opinions)! It would probably be a full-time job and not leave any time for client work..

I'll continue to watch your progress - and contribute if I can. I can see projects where I may want to start with your platform as a base, but I think they would diverge fairly quickly :)

Regarding the agentic workflow - I am running on Windows - as I'm interested in seeing it work end to end, I'll spend a little more time on it - and if I get it to work, I'll let you know so you can add any notes into the docs etc.