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).
Real screenshot captured (heroImage above): the live public site’s own
homepage — safe by construction, it’s the organization’s own public
marketing page, no client data of any kind.
Screenshot still needed (scrubbed): the task board and the meeting-minutes approval view are behind portal login and contain real donor/board/financial data — not captured. Either a throwaway demo tenant seeded with fake records, or a hand-picked crop with every real value blacked out, would be needed before either is safe to publish.
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.
Honest outcomes
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 — including things that broke and got fixed along the way — is also what proved out the architecture now being built into its own standalone product.
For Max, not for publishing: naming the organization is confirmed — Max has Strive4Purpose’s permission. Left out deliberately: the founder’s personal name, which was in the original draft’s frontmatter/title. Naming an org a client agreed to is a different thing from naming an individual — he’s a licensed therapist whose own clients may search his name — so that stays out unless Max says otherwise specifically for the personal name, not just the org.