Donor pipeline, grant calendar, board reporting, volunteer scheduling, comms. You own all of it when I'm done.
Most small organizations don't have an operations problem they can hire their way out of. They have six or seven processes that only work because one person remembers them. I map those, design the system underneath, build it, and hand it over.
Thirty minutes, no pitch. If I can't help, I'll say so on the call.
These aren't six products. They're modules of one build, and most organizations need three or four of them. Here's what usually breaks, and what replaces it.
Thank-you letters go out when someone remembers. Lapsed donors get noticed a year late, usually by accident. Nobody can say who gave last year but not this year without opening a spreadsheet and doing it by hand.
Gift intake, acknowledgment that fires on its own, and lapse and stewardship watchers that put the name in front of you while the relationship is still there.
Deadlines live on paper, or in one person's head. Reports get remembered the week they're due. Last spring's funder research is in a document nobody can find, so it gets done again.
Funder discovery and scoring against your actual mission and geography, deadline and report tracking that surfaces before it's urgent, and draft generation off your own past applications.
The packet gets rebuilt by hand every cycle. Financials get re-keyed out of three different places. It goes out the night before, or it goes out thin, and either way somebody apologizes for it.
Pre-read assembly that pulls from the systems already holding the numbers. Same shape every month, same cadence, without anyone sitting down to assemble it.
Coverage gaps get discovered Saturday morning. Scheduling is a group text. When the person who runs volunteers leaves, the schedule leaves with them, because it was never anywhere but their phone.
Shift scheduling with coverage watchers that flag the hole on Wednesday instead of Saturday, plus the reminder and confirmation messages going out without anyone writing them.
One inbox, no triage. The same six questions answered from scratch every week. The newsletter goes out when there's time, which means it goes out twice a year.
Triage rules that sort what's arriving, templated responses for the questions that repeat, and digest assembly so the recap writes most of itself.
Every post starts from a blank page. The voice drifts depending on who wrote it that week. Approval happens in a group text and then somebody forgets to actually post it.
Your brand voice captured once, draft generation that uses it, an approval step that isn't a text thread, and publishing out to the places you already post.
Every one of the six exists as software you can buy. I looked hard before I built anything.
The ones that do the job are priced for organizations with a development department. The ones priced for a team your size are thin. And most are built so that leaving costs more than staying, which is the real product.
That's why I started building my own for the organization I run. Then other people asked.
I don't quote a build before I've seen how the place runs. The assessment is the front door, and it stands on its own. Plenty of organizations take the assessment and fix things themselves. That's a fine outcome.
Two weeks. I map how work really moves through your organization, find where it stalls, and tell you what to fix in priority order. The document is yours regardless of what happens next.
The build. A data model and workflow logic underneath, and on top of it whatever your team already uses to get work done. Email, forms, a dashboard, Slack, or some combination. Nobody has to learn a new place to work.
This is the part that separates me from software and from most consultants. You own it outright, and it runs on infrastructure you control. If it only runs while I'm in the room, I haven't finished.
The evaluation layer beneath every build. It reads an organization's operational data and returns what's decaying, what's stalled, and what's about to become a problem, ranked by what to deal with first.
It's an API rather than a dashboard, so there's nothing to click yet. A walkthrough is the next thing I'm building.
Mission-driven organizations small enough that there are no departments and no middle layer. Usually founder-led, or led by someone who inherited a founder's systems and is holding them together.
The tell is simple. If one person went on vacation for two weeks, would something important quietly stop? If the answer is yes, that's the thing I fix.
I've built these for organizations in a handful of different fields. I don't put client names on my website.
If you want to see how this reads for your specific situation:
I spent a decade in supply chain doing demand planning and inventory management. Then I started running nonprofits, and found out that a volunteer scheduling bottleneck is a decoupling point, a donor lifecycle is an inventory problem, and event logistics is demand planning with different nouns.
I run two nonprofits. Small teams, no departments, no middle layer. I built every one of the six systems above for them before I sold a single one, because I needed them and nothing on the shelf fit organizations that size.
That's the whole background. I'm not a developer by training and I don't pretend to be one. I'm an operator who got tired of doing things by hand and learned to build.
One of the two is a songwriters' collective. I write songs myself, and working inside tight structural constraints taught me more about system design than any business book did, which sounds like a line but isn't.
Same tools, hosted, no engagement. Cheaper and less tailored. If your budget doesn't reach a build yet, start here.
Thirty minutes. I'll ask how work moves through your organization and where it stalls. You'll get my read on it either way, and I'll tell you if I'm not the right fit.
I speak on operational design and AI adoption for nonprofit boards, networks, and conferences. Most recently the South Dakota State Arts Conference, April 2026.
Essays on operations, systems, and what small organizations get wrong before they get it right. Not on a schedule.