01 — The friction
Small nonprofits do not have small operating complexity.
Board work, grant obligations, insurance renewals, policy reviews, employee cycles, government filings, donor commitments, and recurring internal tasks all arrive on different schedules. The organization may still have only a handful of people available to notice, interpret, assign, document, and complete them.
The work becomes distributed across inboxes, spreadsheets, calendars, shared drives, meeting notes, and memory. That makes ordinary handoffs fragile, onboarding unnecessarily archaeological, and institutional knowledge far too easy to lose.
“What needs attention next?” should not require a scavenger hunt.
02 — The system
Make the work visible, owned, and repeatable.
The pilot brings intake, ownership, recurring obligations, documentation, handoffs, and institutional knowledge into one operating structure. The first design constraint is deliberately narrow: surface the work that needs attention during the next 30 days, with enough context to act on it.
Bring recurring work and incoming obligations into one visible operating horizon.
Make responsibility explicit before a deadline becomes an emergency.
Connect the task to its supporting documents, decision history, and evidence.
Preserve the cadence, handoff, and instructions for the next cycle.
03 — The rolling view
The next 30 days, without the archaeology.
The rolling calendar is not meant to become another calendar to maintain. It is the front door: a prioritized view of what is coming, who owns it, what kind of obligation it is, and where the working record lives.
Today → Day 30
Illustrative prototype data. The pilot is in active product validation.
04 — The operating model
It is less about reminders than continuity.
A reminder can tell someone that a filing is due. An operating system should also show who owns it, what happened last time, which document is authoritative, who must approve it, what completion looks like, and when the cycle begins again.
Capture work without requiring everyone to understand the whole system first.
Show who is responsible, who contributes, and who needs visibility.
Keep context attached as work moves between staff, board members, and partners.
Turn experience and recurring knowledge into an organizational asset.
05 — Current status
The current work is focused on validating the problem, narrowing the first useful operating view, and testing whether the model reduces the cognitive load of recurring administration without creating another burdensome system.
Test the recurring-work model with small nonprofit operators.
Refine the rolling view, ownership model, and supporting task context.
Separate genuinely useful structure from features that merely look organized.
06 — What it reveals
The product idea began as an operations question.
Nonprofit Ops OS grows out of the same pattern that drives much of my work: notice where skilled people are compensating for an invisible system, make the operating logic legible, and build the smallest structure that could give them time and judgment back.
This is product design grounded in lived operational constraints—limited capacity, high consequence, many stakeholders, and no appetite for software that creates more work than it removes.