Interested in why you'd recommend that? Event-driven architecture decouples everything up front and the benefits are immediate. In this scenario the introduction of billing is en excellent example. User does something they should be billed for? Raise an event. Listen to it to bill them. Next iteration needs to email the user or update some history? Listen to the event. And so on. All the ephemeral saas infrastructure stuff just hangs off of the domain. And writing the code that way really isn't much more onerous than otherwise so I wouldn't discourage it for an MVP.

It feels like having the architecture not be event-driven when the whole product is about dealing with events would be the same as going the event-driven architecture route for, let's say, a knowledge-sharing SaaS

But I will definitely keep spark in mind for the future, thank you :-)

Rails https://bullettrain.co/

Laravel https://spark.laravel.com/

They are good to get up and running quickly, I used spark on a SaaS and it worked well.

There are lots of great gems/packages that allows you to work without these though, if you want a little more control on how things are setup.

Thanks!

https://news.ycombinator.com/item?id=18010871

Maybe a good opportunity for a Python developer to put one together?