Use django-debug-toolbar and keep it turned on . And look at it regularly. OK, point made.

This project was quite a lot easier to fix than django-cms, because it is much newer, and so has less code, and - more importantly - far fewer compatibility issues to worry about with 3rd parties who depend on certain features.

You should think about big O scaling issues fairly early, because you can easily put yourself into a situation where things are hard to fix, due to:

schema design.

promises you’ve made regarding functionality to 3rd parties.

For example, django-fiber has a concept of ‘current’ pages (pages which would form part of the bread crumb for the page you are on) and, in addition to the obvious ones (the ‘ancestors’ of the active page in the tree of pages), it has a feature which allows any page in the database to be a candidate ‘current page’ for any other page, based on a regex field. And so you have to check all these pages when rendering any page.

This does not scale well. Thankfully, it’s not too much of a problem if you don’t use this feature, since you can do DB level filtering to eliminate most of the pages as potential candidates for this.

But if you do use it, you have a scaling problem - for every time you use it, then the amount of work you’ve got to do to render any page increases. (And, if the DB filtering isn’t efficient, you may still be paying an increasing penalty for every page added to the system even if you never use the feature).

EDIT: I should have mentioned on the positive side that django-fiber has obviously given thought to general scaling issues, and used django-mptt for the tree structure of their Page model. This made it relatively easy to fix the ‘show_menu’ template tag to do everything in 2 queries. Otherwise it would have been a nightmare.