"The core of the software is ultimately pretty simple, however it really needs to be custom tailored to each organization. Some groups want to track whether artists are persons of color, some groups want to have explicit fields for evaluating, and some just want space for a recommendation and a way to attach an in depth review, and every organization believes that theirs is the one true method. These changes are all pretty simple to make, however they are large enough and sometimes architectural enough to make building one monster app and database with support for all the iterations rather imposing. Especially when I can't afford to work on this full time."

"Do I try to make one monster app that can serve every organization, risking complexity, less flexibility, and security? Do I just try and optimize and optimize until it can run happily on a less beefy machine? Or do I have too many pre-conceived notions about how customers think, and I just need to pump out a project, set a price, and start going? Help!"

This seems like a problem that can be solved with some pretty basic OO in your business logic layer, and a little creative database work. One system to run all of the sites will save you headaches in the long run. It will likely save you some money as well. Were I in your situation, I would certainly go with the one central system approach.

Off the top of my head, I'd be creating one set of abstract business logic classes that contain what your clients have in common; and a set of abstract methods that will return objects that contain data they do not. I'd create a class inheriting the abstract one for each client, each containing their custom requirements. I'd create a view layer that can adapt to the custom data, and a data layer that is capable of storing the custom data. Let me know if this is too vague.