Project Details
The problem
Strive4Purpose’s team portal proved a real client platform architecture works for a live nonprofit. The next question is whether that architecture generalizes: can the same system serve a genuinely different kind of business (this platform’s own operator’s consulting/development work) and eventually other clients too, without becoming a maze of one-off special cases for each tenant.
What’s being built
A standalone product built from that proven architecture: a central dashboard covering donor/CRM data, a task board, contract generation with e-signature, grant discovery, and a content engine, designed from the start as genuine multi-tenant SaaS rather than a single-client build, with a strict data boundary so no client’s data is ever visible to another.
Two features built this way, deliberately, as proof the multi-tenant pattern holds under real new requirements rather than just the original one:
- Account linking (Google and iCloud calendar/contacts): built as a provider-shaped integration behind one interface, keyed per user per provider, rather than hard-wired to one person’s account. The same mechanism designed to later let a future client using Google Workspace be onboarded with the same ease a Zoho-based client has today.
- In-browser meeting recording with chunked, resumable upload (its own case study above): built as a real, shared piece of infrastructure from day one, not a one-off feature bolted onto a single tenant.
The part most relevant to a prospective client: data residency
The multi-tenant design goes beyond “each client’s data is walled off from every other client’s.” A real class of prospective client (a licensed therapist, a small healthcare provider, anyone bound by confidentiality obligations that predate this platform) genuinely cannot send their client data to a third-party AI provider at all, no matter how the vendor markets its privacy policy. The platform is built with that constraint as a first-class design input rather than an afterthought: a tenant can be configured so its AI-touching features run against local, self-hosted models instead of a cloud provider, keeping sensitive data on infrastructure the tenant (or the platform operator, on their behalf) actually controls, rather than a blanket “we send everything to a cloud API” default that would rule those clients out entirely. This is real, built capability. The storage boundary and the tenant-level routing logic both exist in the codebase today, not a roadmap promise.
Technology choices, and why
Cloudflare Workers + D1, matching the pattern proven on the first client engagement: serverless compute and a per-tenant-scalable database model suit a platform whose whole premise is “many small tenants,” each with modest, bursty traffic, rather than one large always-on workload.
Provider-shaped integrations, not client-shaped ones. Every external integration (identity providers, calendar/contacts providers) is built behind a single internal interface with per-provider implementations underneath, so adding “a client who uses X instead of Y” is implementing one more provider, not forking the feature.
Encrypting third-party credentials at rest, independent of the platform’s other data, so a broader data export or backup can never itself become a credential leak.
Where it stands
Real infrastructure (a dedicated database, identity-provider integrations, the task-board API) is built and in daily use running the platform operator’s own work, seeded with the platform’s own first real feature requests: the system proves itself on itself first.