Launching DIY Data Control for Nonprofits

Patrick, this is a genuinely valuable direction. Our experience suggests that the biggest gap is not the technology itself, but the journey from a promising data model to a trustworthy, maintainable operational system.

The pain points I would prioritise are:

• turning an abstract model into definitions that staff interpret consistently;
• matching and deduplicating records imported from unreliable spreadsheets or data sources;
• recording provenance, licensing, confidence and transformation history, not just the final value;
• designing roles around real responsibilities, including exceptions and sensitive fields;
• testing security from the perspective of each user type;
• handling corrections, approvals, audit trails and schema changes;
• separating development, testing and production, with recoverable backups;
• understanding ongoing licensing, administration and support obligations.

I would also treat reporting security as its own implementation topic. Model-driven apps can work closely with Dataverse security, but Power BI permissions and row-level security need deliberate design and testing; teams should not assume that every underlying access rule will automatically carry through to every report.

The most helpful resources may therefore be opinionated, end-to-end reference implementations rather than another catalogue of features: a small fictional nonprofit, realistic messy source files, a governed target model, documented decisions, import and reconciliation processes, security tests, deployment guidance and a “who looks after this after launch?” checklist.

I’d strongly support beginning with listening. Self-taught IT champions often understand their organisations exceptionally well, but are being asked to carry architecture, governance, privacy, security and operational support responsibilities without a map... or enough protected time. Designing for that reality could make this project unusually useful.