April 15, 2026

The client’s first online talk was in 30 minutes.

Guests were registered. The speaker was ready. The “we finally did it” energy was real.

The venue was a really cool, unusual place. It did not have Wi‑Fi, so we were streaming over my phone. We tested it. We even did a full multi-country test run.

And then my phone did the thing phones do at the worst possible time.

My not-unlimited Verizon minutes for the month ended. Not “low.” Not “almost.” Ended.

This is the part where you think, “Surely there was a responsible adult in the room who had checked the cell plan.”

Reader, I was the responsible adult.

And that is the prequel.

The fix was not heroics. The fix was a boring plan I should have had before we walked in. Documentation, access control, and a backup plan. Even for a livestream.

Now let’s talk about the other ways “it’ll probably be fine” tries to ruin your week.

Scene 1: The Password Spreadsheet (aka “The One File to Rule Them All”)

You know that moment in a horror movie where someone says, “It’s probably fine,” and then opens the door anyway?

“It’s probably fine,”

This was that moment. Except the door was a spreadsheet.

A client sent me “the login doc.” Reasonable. Normal. I braced myself for the usual. A Google Doc with a few passwords. Maybe a shared vault link if we were lucky.

Nope.

It was a spreadsheet. With logins to basically every single IT provider they had. DNS. Domain registrar. Website hosting. Email. Payment tools. The whole stack. The keys to the kingdom.

And then, because the universe loves comedy, it got shared in a full-company Slack channel. Not just to me. Not just to the one person who needed it. To everyone.

At which point I got to have my favorite kind of conversation. The one where I say, calmly, “Okay. We’re going to fix this. Right now.” While my internal narrator is screaming.

What actually went wrong

When there’s no clear way to store and share access, teams invent one. Spreadsheets are familiar, fast, and catastrophic.

The fix (minimum viable, grown-up):

• Pick one password manager and make it the default. Shared vaults by role (not by person), with an owner.
• Set a simple rule for sharing access. No passwords in docs or chat. Ever. Share access through the vault.
• Turn on 2FA everywhere it matters: email, DNS, domain registrar, hosting, payment tools.
• Reduce the blast radius. Fewer admins. Least-privilege access. Remove access when roles change.
• Assume exposure and respond. Rotate anything that may have been shared, and document what you changed.

Because the real horror isn’t that someone shared a spreadsheet.

It’s that the spreadsheet was the system.

Scene 2: The Board Member Who Bought Software on a Tuesday Night

There is a special kind of nonprofit tech horror that starts with a cheerful sentence.

“Good news. A board member found us a solution.”

In this case, the solution was Salesforce.

Now, before the Salesforce people come for me, let me say this clearly. Salesforce can be amazing. It can also be a full-contact sport. It is not a casual Tuesday night purchase.

A well-meaning board member got excited, heard the words “nonprofit discount,” and clicked Buy like they were ordering toilet paper. Then the invoice hit. Then the staff got voluntold. Then everyone looked around for the responsible adult to lead them.

Hello, me again.

Because here’s the part nobody puts on the pricing page: the software is not the project. The implementation is the project. The training is the project. The governance is the project. The “who owns this now” is definitely the project.

What actually went wrong

Without a decision process, software is not a solution. It’s a new job. One you didn’t post, budget for, or assign on purpose.

The fix (tiny governance that saves your sanity):

• No purchase without a one-page decision note. Problem, options, total cost (licenses + implementation + staff time), and a named owner.
• Name the owner before you buy. A real human with a calendar and authority.
• Pilot one workflow for 30 days. One team, one use case, clear success criteria.
• Budget the implementation, not just the license. Time, training, data cleanup, and ongoing admin.
• Decide what you are not doing (for now). Scope is a strategy, not a failure.

Because “we bought Salesforce” is not a plan.

It’s a jump-scare.

Scene 3: The Spreadsheet That Ate the Donor Database (The Mail-Merge Horror)

It starts with the most dangerous sentence in nonprofit operations.

“Ima just gonna download the donor list real quick.”

Someone exports. Opens Excel. Decides to “clean it up.” A little sort here. A little copy-paste there. A quick “remove duplicates” that feels productive.

Then they upload it back.

And for a brief, beautiful moment, everything looks normal.

Until the next donor emails go out and someone does a spot-check and goes, “Wait a minute.”

Why is this address attached to the wrong name? Why are phone numbers… shuffled? Why is Jane Doe suddenly a super-donor when that was Annie Lee? Why did we just mail-merge a parallel universe?

Oops.

This is the part where the horror movie soundtrack kicks in and the team tries to fix it manually. One row at a time. Like defusing a bomb with oven mitts.

But in this story, there was an adult in the room.

Someone had paid for daily full database backups.

So instead of spending three days playing “Which Annie is the real Annie,” the team rolled the database back.

What actually went wrong

There was no safe, governed way to export, edit, and re-import donor data. Excel was not the villain. The lack of guardrails was.

The fix (without shaming anyone):

• Name one source of truth (and mean it). The CRM is the system of record. Spreadsheets are working copies with an expiration date.
• Create a safe import path. One documented process, one owner, and a short checklist for exports and imports.
• Limit mass edits to trained staff. Fewer hands on the “update thousands of records” button.
• Test before you touch production. Do a small sample import first, then spot-check 10 records before anything donor-facing goes out.
• Use backups like a seatbelt. Daily full backups, plus a restore test so you know it actually works.
• Make spreadsheets temporary by design. Owner, date, purpose, delete-by date.

Because the real nightmare isn’t that someone made a mistake.

It’s that one normal mistake could quietly rewrite reality.

Scene 4: The Workaround That Became the System (Because They Said No to Tableau)

A nonprofit finally got a real data warehouse. Big win. Impact data started flowing. Dashboards. Reports. Board-ready numbers.

Then a staff member’s personal laptop died.

And everyone realized the “impact reporting process” wasn’t in the warehouse.

It was on his laptop.

He’d been pulling data down to his personal machine, manipulating it locally, and generating the final numbers from there. So when the laptop died, the reporting died with it.

Then came the second realization. The one that makes you sit up straight.

Security.

Because now the question isn’t just “How do we rebuild the reports?” It’s “What sensitive data has been living on a personal device, outside our controls, this whole time?”

And here’s the part that matters. He didn’t do this because he was careless. He did it because he was trying to do his job.

He had asked for Tableau (or any real BI tool). The organization said no. Too expensive. Not a priority. Maybe next year.

So he built a workaround. The only way he could. With the tools he had. On the machine he controlled.

It worked.

Until it didn’t.

What actually went wrong

If the org says no to the tool but still expects the outcome, the process becomes “whatever one person can hack together.” The hidden price tag is fragility and risk.

The fix (the grown-up compromise):

• If you say no to a tool, say yes to a process. Define the approved path for getting the work done.
• Set the minimum standard. What “good enough” looks like right now (accuracy, turnaround time, security, auditability).
• Make it org-owned by default. Org accounts, org storage, org permissions. No personal devices as the system.
• Remove the single point of failure. Name an owner and a backup. Document the steps on one page.
• Put a review date on the “no.” If it’s “not this year,” schedule the revisit. Otherwise the workaround becomes permanent.

Because the real horror is not the laptop dying.

It’s realizing the laptop was production.

Scene 5: “It Uses Stripe Too” (The Great Payment Migration Lie)

A client came to us with what sounded like a totally reasonable plan.

“Can we move our payments into WooCommerce? It uses Stripe too.”

They had a custom system. They wanted something more standard. They were also moving CRMs, and a vendor had promised WooCommerce would integrate “seamlessly.” They weren’t being reckless. They were trying to get out of the business of maintaining a one-off payment setup.

They asked us to manage the project.

Which is how this became a horror story that didn’t happen.

Because the first thing I asked wasn’t, “Sure, when do you want to launch?”

The first thing I asked was, “Okay. Where do your recurring donations live right now, and how many do you have?”

The room did that little pause. The one where everyone realizes they’ve been saying the words “easy integration” the way people say “it’ll probably be fine.”

Because here’s the part nobody wants to learn during launch week.

Credit cards don’t “move.” Not really. Not the saved payment methods. Not the subscription tokens. Not the invisible machinery that makes monthly giving quietly work in the background while everyone’s busy ordering toilet paper and planning the gala.

If you rebuild checkout on a new platform, you’re not just changing a form. You’re potentially asking every monthly donor to re-authorize their gift. And if you do that without a plan, you don’t get a clean migration.

You get a slow leak in revenue that nobody notices until the numbers look weird and someone starts blaming “donor fatigue.”

So we stopped. We mapped the current system. We counted active recurring donors. We identified what could be migrated and what couldn’t. We planned donor communication before touching the tech. We made sure the “simple integration” did not quietly become a recurring-revenue incident.

What actually went wrong

“It uses Stripe too” confuses the payment processor with the system built on top of it. Recurring giving is a system. When you change platforms, you rebuild the system.

The fix:

• Start with the money map. List every payment flow (one-time, recurring, event, refunds) and where each one lives today.
• Make recurring giving a protected asset. Get the count, the dollar amount, and the failure modes before you change anything.
• Decide the migration truth early. Can subscriptions migrate, or will donors need to re-enter cards? If it’s re-entry, plan the campaign like you mean it.
• Separate “launch” from “cutover.” New checkout can go live without flipping recurring donors on day one.
• Assign an owner for donor experience. Not just the tech build. Someone owns comms, timing, and monitoring for the first 30 days.

Because “it uses Stripe too” is not a plan.

It’s the opening line of a recurring revenue horror movie.

Scene 6: The Budget-Budget Tool (That Everyone Immediately Replaced)

A nonprofit built a budget tool.

A budget-budget tool.

I love the optimism of that sentence. I truly do.

They had outgrown spreadsheets. They wanted something more structured. Something that would “standardize the process.” Something that would make budgeting feel less like herding cats.

So they built it.

And it kind of seriously sucked.

Not because the team was incompetent. Because budgeting is messy, and tools that look simple usually aren’t. The first version did not match how humans actually budget. It was slow. It was clunky. It did not give people what they needed when they needed it.

So nobody used it.

Instead, everyone made their own budget tools.

Spreadsheets. Templates. Personal trackers. Files emailed around. Attachments with names like “JohnDoe-2023-April-FINAL_BUDGET_v7_REALLY_FINAL.xlsx”.

And because this is nonprofit life, those files did not just contain budget numbers.They contained personal information. Social Security numbers. Bank account numbers. Passwords. Notes that were never meant to be shared with, well, whoever.

All floating around in inboxes and desktops like it was 2009, and pasted into ChatGPT for analysis like it was 2025.

What actually went wrong

When the official tool does not work, people will still do the work. They’ll just do it in the least governed, least secure, least recoverable way possible.

The fix:

• Secure the reality you have. If budgets are shared by email, require secure email for sensitive attachments (encryption, access controls, expiration). Better yet, send links with permissions instead of files.
• Fix the workflow before you fix the tool. Design around how budgeting actually happens, not how you wish it happened.
• Set hard data boundaries. No SSNs, bank info, or passwords in budget docs. Ever. Put sensitive data in the right system and reference it.
• Make it recoverable. Use tools with version history, audit trails, and access logs. “Who changed what” should be answerable.
• Train for modern risk. Set clear rules for what can be pasted into AI tools, and a default “ask first” path.

Because “FINAL_v7_REALLY_FINAL.xlsx” is not a budgeting system. It’s a warning label.

Scene 7: The Nephew Who Became the IT Department

Every nonprofit has a version of this story.

A volunteer. A board member’s nephew who’s “good with computers.” Someone smart, well-meaning, and available.

They set up the email. They run some cable. They configure phones. They point the DNS. They fix the website. They “tweak a few settings.” They do the kind of work that quietly becomes mission-critical the second everyone starts relying on it.

And for a while, it works.

Then comes the plot twist.

The nephew trains an intern how to log directly into a production server and change configuration files. Not in staging. Not through a ticket. Not with a checklist. Not with a rollback plan. On the live server.

And one day, something breaks.

And the nephew is long gone.

Which means the organization is left with the worst kind of technical debt. Not the messy kind. The kind where systems are down, a few hundred people are calling, and the only documentation is a vague memory that someone once said, “Oh yeah, my nephew set that up.”

What actually went wrong

The organization outsourced institutional knowledge to a single person who wasn’t accountable, not documented, and not there for the long haul.

The fix (without losing the volunteer spirit):

• Volunteers can help. Volunteers should not be your production change process. Treat production like a controlled environment, even if the team is tiny.
• Make access org-owned and auditable. Real accounts, 2FA, role-based permissions. No shared logins. No personal emails as the keys to the kingdom.
• Reduce the blast radius. Fewer people can touch production. Everyone else works through a documented request path.
• Require a rollback path. If you can’t undo the change, it doesn’t go in on a Tuesday night.
• Write down what exists. A one-page “here’s the stack, here’s where it lives, here’s who to call” doc is a gift to Future You.
• Schedule a quarterly access and continuity check. Who has access, what they can change, and what happens if they disappear.

In nonprofit tech, “we have a guy” is unfortunately how many stories begin.

The ending needs to be way more boring.

Documentation, access control, and a plan.

The Pattern Underneath All These

These stories are funny now (mostly) because we got through them.

But the common thread isn’t “bad tech.” It’s missing decision systems.

When you don’t have a clear way to make choices, manage access, protect sensitive data, and run projects, your organization will still move forward.

It will just move forward on heroics.

We’ll Help You Build the Systems So You Don’t Need Heroics

If you want a “responsible adult” in your corner (the kind who asks the annoying questions before launch day), that’s what our retainer is for.

It's an ongoing partnership for nonprofits who need steady tech leadership. Not just projects. Not just emergencies. A real operating rhythm.

If that sounds like what you’ve been missing, reply and tell me what kind of horror story you’re living through right now. I’ll tell you what I’d fix first.

Because the goal isn’t to survive sequels. It’s to stop making them.