How would you handle a requirement to track something the Nonprofit Cloud data model does not cover?

I work down a ladder, and I try hard not to reach the bottom rung.

1. First, challenge the requirement. A surprising proportion of “we need a new object” requests are an existing object under a different local name — the organisation calls it a referral pathway, the model calls it a Referral.
2. Second, extend rather than replace: custom fields, record types and page layouts on the standard object keep you inside the shipped reporting, rollups and future enhancements.
3. Third, look at the configurable frameworks before building anything. A recurring assessment is a Discovery Framework assessment; a repeatable checklist is an action plan template; a scheduled aggregation is a Data Processing Engine definition.
4. Only then a custom object, and if I build one I plan explicitly for how it relates to the standard model and how it will be reported alongside it.
5. The cost I state out loud is upgrade friction: every custom extension is something the team maintains and tests against each release, and nonprofit customers are precisely the ones least able to carry that overhead.