I will be honest about how Edventory is built, because I think a lot of software people would find it strange.
The architecture grew organically. I did not sit down and design a grand system. I started building module by module, solving one real problem at a time, and the shape of the thing emerged from that. The architecture was never the point. The work it does was the point.
Under the hood it is deliberately plain. There is no heavy framework doing magic I cannot see. The data lives in a straightforward database without a big abstraction layer sitting on top translating everything. When something breaks, I can read the code and understand exactly what it is doing, because there is not much hiding between me and the machine.
I think a lot of SaaS gets overbuilt. People reach for the most complicated tool first, stack five layers of framework on a problem that needed one, and then spend their time fighting the stack instead of shipping features. I went the other way. I kept it simple enough that one person could hold the whole thing in their head and keep moving.
That choice has paid off. Because the foundation is simple, I can add a feature in an afternoon when I run into a problem in my own districts. I am not unwinding three layers of abstraction to change one behavior. Boring on the inside is what lets Edventory move fast on the outside.
If you are building something and you feel pressure to use the fashionable thing, my advice is to use the simple thing you understand. You can always add complexity later. You can almost never take it back out.