The final week shifted from development to transition. A trial run on a staff laptop, a conversation about device risk, decisions about file storage, and finalizing five documents brought the project to a close. It also surfaced something that had been in the background all along: a system is only as useful as the person in front of it feels capable of using it.

What went well? The documentation held up under real conditions. When credential prompts appeared, when Power Query failed on a new machine's file path, and when questions arose about data sensitivity — the Technical Reference and Staff Guide could answer them without my involvement. That was the intended outcome, and it worked. The data sensitivity conversation also clarified something worth stating clearly: the workbook contains no client PII, and the communications data it tracks is drawn entirely from public posts and opted-in newsletters. The primary risk of device loss is operational continuity, not data exposure. Communicating that clearly to staff is as important as building the system correctly.

What could have been done differently? I built with a capable, engaged user in mind. I should have designed earlier for the transition moment — when the person who built the system hands it to someone who didn't, and that person eventually hands it to someone else. Nonprofits lose staff regularly. Projects get abandoned not because they were poorly built, but because the expertise was concentrated in one person and left when they did. Documentation should have been treated as a core deliverable from the beginning, not a final step.

What did I learn about myself when working with others? The decisions that felt smallest — where to store a file, whether to use a URL or a local path, how to phrase a callout box — turned out to matter most to the people actually using the system. Technical decisions have human consequences that are easy to underestimate when working alone.

What did I learn about leadership? The balance between technological sophistication and organizational sustainability is not a design constraint — it is a values question. A complex system that cannot survive a staff transition is not an asset. For a small nonprofit operating on limited resources and volunteer goodwill, simplicity and durability are not compromises. They are the right answer. This project reinforced that the most important thing to leave behind is not a system — it is a system that someone else can maintain, understand, and eventually hand off again.