When we know the project is going to see a lot of end-users that'll need their own "profile" styled page and/or if we know we'll see a lot of database changes o

When we know the project is going to see a lot of end-users that'll need their own "profile" styled page and/or if we know we'll see a lot of database changes over time. Which hasn't been a lot of times yet, if I'm being honest. One example that I can share, that would have also been a good Django candidate is our system for handling employee absence. When it launched it only let you report the two types of paid vacation we have, but being the public sector of Denmark, we actually have around 80 different types of legal absence, with various rules attached, and we knew we'd want to add more over time. We also knew every employee would need their own profile to keep track of their accounts, and we knew some managers would want to outsource the responsibility to secretaries and such. So that's what would be an obvious Django project to us, but it was build in .NET because that's what we were most comfortable with at the time.