You know, or should know, that the multiple layers of abstraction between *your* code and the database will one day come back to bite you. Badly.

It's good that you now see that CRUD is not the pinnacle of the web application user experience. However, it appears that rather than developing from the Database up, you've developed from the User experience down. You mentioned the problems you've run into when the database structure had to be changed...what happens when the user experience changes?

Although you now see that Users do not necessarily need to interact with a poorly-disguised database layer (i.e. simple CRUD), there is often more to the relationships between "Things" than we typically express in our Perl code. That's why we use the database to help define those relationships. That's why we call it a Relational Database.

Moose is no free lunch. While it does offer some grace and power, it does not abrogate the need for a clean database design and a sane MVC architecture. If you somehow saved yourself from writing the database and MVC, then great - that's sort of the whole point of using modules other people write. However, storing things in the Session or in RAM and just expecting things to Just Work Somehow is not how development works in the long run.

At some point, your code will need to be changed. If you have 100% code-coverage from a well-designed set of unit tests, then you will be able to make those changes without worry that the changes you make have broken something else. If you don't yet have a full set of unit tests, now is the time to write them.