Project Details
Strive4Purpose is a real, operating South Dakota nonprofit client, named here with their permission.
The problem
A small nonprofit team was running donor tracking, board coordination, and grant work across a patchwork of spreadsheets, email threads, and manual processes. Workable at a handful of people, but genuinely fragile: nothing enforced who could see what, nothing kept a record of who changed what, and every recurring task (recording board decisions, tracking a grant deadline, confirming a donation) depended on someone remembering to do it by hand.
What was built
The engagement started as a public website and grew into a full team portal:
- Role-based access across the whole system: a small number of access tiers (an onboarded partner/volunteer, staff, admin), enforced on every API route server-side, not just hidden in the interface. Every route a person or an automated process can reach is checked against exactly what that caller is allowed to do.
- Donor/CRM management, synced with the organization’s existing CRM rather than duplicating it as a second source of truth.
- A shared task board doubling as both a human worklist and the landing place for anything an automated process raises (a feature request, a detected issue, a follow-up), so nothing generated by automation sits invisible in a log nobody reads.
- Board-meeting transcription and minutes generation, landing every set of minutes as a draft that a real board member must explicitly approve before it counts as the official record. Never auto-finalized.
- Grant discovery and tracking, e-signature contracts, and a content engine for social/board communications.
- An in-portal help assistant that answers from the system’s real, current feature list rather than guessing, and deliberately files a tracked request when someone asks for something that genuinely doesn’t exist yet, instead of inventing an answer.
This became the architecture behind a productized “business in a box” system for future clients (see the Maksym Pylypchuk Portal entry below).
One of the pages built on this system: a real, live coaching booking page with a structured rate, sliding-scale terms, and a working request flow, not a static “contact us” form.
Technology choices, and why
No single-provider dependency on any AI-touching pipeline. Meeting minutes, chat processing, and contact-note handling all try a primary cloud model first and fall back to a locally-hosted one rather than failing outright if one provider is unreachable. A nonprofit team depending on this system on a Tuesday shouldn’t be blocked by one vendor’s outage.
Draft-then-approve for anything an automated process touches that a person is meant to rely on. A detected financial entry, a generated set of minutes, a filed ticket: all land as a proposal a human confirms, never as a fact an automation asserted on its own. This is enforced structurally (the same role/permission layer that gates every route also distinguishes “a person did this” from “an automated process proposed this”), not just as a convention.
Cloudflare Workers + D1 for the whole backend: a serverless model that matches a small nonprofit’s actual traffic pattern (bursty, low-volume) far better than an always-on server would, at a cost close to zero at this scale.
Outcome
Live production system in real, daily use: public site, donor/board portal, board-meeting minutes automation, grant discovery, e-signature contracts, and a resilient LLM pipeline with a genuine local fallback rather than a single point of failure. This system’s real operating history is what proved out the architecture now being built into its own standalone product.