How it works
For the people who want to know what's underneath.
Eighteen separate applications that feel like one product is a specific engineering choice, not a marketing line. Here is how it's actually put together, and where it's going next.
The shape of it
Four layers. Everything above the database is a consequence of everything below it.
One identity
You sign in once. That session is shared across every app, and carries which organization you're currently acting for.
- Single sign-on
- Organization context
- Switch roles without signing out
18 apps
Each on its own subdomain and a full application in its own right, with your permissions applied per app, at the organization level and again per member.
- A subdomain each
- Org-level access
- Member-level access
- Owners and admins inherit
One database
Every app writes to the same place, so a volunteer, a donation and a meeting action are rows that can actually reference each other, with nothing to synchronise between them.
- One shared record
- Row-level security
- One audit trail
- Nothing to sync
Connected outward
Where a tool already does the job well, Rypple talks to it rather than replacing it: directly for these, and through Zapier for most of the rest. A growing list.
- QuickBooks
- Givebutter
- Stripe
- Google Ads
- Google Analytics
- Zapier → everything else
Why one database matters more than it sounds
A suite of products that merely share a login still keeps its data in separate silos, which is why so much nonprofit software makes you export a CSV to answer a simple question.
A question you can ask
“Which of the volunteers who served more than ten hours this year also gave, and which campaign first reached them?”
Why it's answerable
Hours, giving and campaign attribution are rows in one database that reference the same person, not three exports to reconcile by hand.
If you want to nerd out about it
The usual way to build eighteen products is eighteen services with eighteen databases, and then a great deal of machinery to keep them agreeing with each other: event buses, nightly syncs, reconciliation jobs, and a support queue full of “why does this screen say something different from that one?”
Rypple has one database, partitioned by domain, with each app owning its own area and reading across into others where it makes sense. A donation row and a volunteer-hours row can reference the same person directly, in the same transaction, with the database itself enforcing that the reference is real.
The consequence is the interesting part: there is no synchronisation, because there is nothing to synchronise. No eventual consistency to explain, no drift between apps, and no class of bug where two screens disagree. Cross-app reporting is a query rather than an integration project.
The trade is that it demands real discipline: schema changes are migrations reviewed as one shared surface, and isolation has to be enforced deliberately rather than falling out of the architecture for free. We think that's the right trade for a platform where the whole promise is that your information joins up.
Security, for the person who has to sign off on this
A fair question, and one we'd rather answer plainly than reassure you about: you're considering putting your volunteers' and donors' details into something you didn't build.
Isolation is enforced twice
Once in the application, on every request, and again by row-level security policies in the database itself. A bug in a page cannot become a data leak on its own.
Authorization comes from your session
Never from a parameter in the request. You cannot reach another organization's data by editing an id in the URL.
Least privilege by default
Access is granted at the organization level and again per member. A volunteer in your org has no path to your finances. Not a hidden button, no path.
Managed, patched infrastructure
Run on established managed infrastructure, encrypted in transit and at rest, backed up, and patched by people who do that full time rather than as a side job.
Sign-in you already trust
Google, Facebook, LinkedIn or email. We never see or store your password from a social sign-in.
It's your data
Exportable whenever you want it, and deletable when you're done. Free doesn't mean you're the product. TOV is a nonprofit, and there is no advertising model here.
If you're the person doing due diligence for your organization and want more detail than this page carries, ask us. We'd rather have that conversation than have you guess.
Permissions, concretely
Access is decided twice. First at the organization level: which of the eighteen apps this organization is entitled to at all. Then at the member level: which of those a given person may open. Owners and admins are granted the organization's apps automatically; everyone else is granted explicitly.
Both checks run on the server on every request, and the database enforces its own row-level rules underneath. A permission error in the interface is not the only thing standing between someone and another organization's data.
Openness
A free platform is only genuinely free if you can leave it.
Your data is exportable
It's your organization's record of its own people, money and work. Nothing about the way it's stored is designed to make leaving difficult.
Integrations over lock-in
QuickBooks stays your books of record if you want it to. Stripe processes your donations. Zapier reaches whatever we haven't built a direct connection for.
Built in the open, with users
Rypple is developed by a nonprofit, alongside the ministries using it. Feature direction comes from the organizations doing the work, not from what upsells best.
On the roadmap, not yet available
Talking to your own data, through your own AI
We're building an MCP server for Rypple, a standard connector that lets you attach your organization's Rypple data to an AI assistant you already use, and work with it in conversation. Draft a strategic plan, turn a messy set of meeting notes into tracked actions, or ask a real question of your donor history without opening the interface.
Two design decisions are settled. It authenticates as you, through the same login you already have, not a shared organization-wide key. And every request runs through the same two-level permission checks as the rest of the platform, derived from your identity rather than anything the assistant supplies, so it cannot be talked into reading another organization's data.
This is designed and specified but not yet shipped. We'd rather say so than list it as a feature.
Questions we haven't answered here?
Create an account and have a look, or read about who each part of the platform is for.