Case study · SOMOS.tech · Platform and cost · 5 min read
A whole community platform for a nonprofit, on donated cloud credits
Nonprofits usually rent their community: a website builder, an event platform, an email tool, a chat app, each priced per seat or per contact, each holding a slice of the members' data. I replaced that stack with one platform and kept it inside nonprofit credits from Microsoft and AWS, with Google's nonprofit ad grant covering marketing.
- $2Ka year in Azure credits covers the core platform
- $120–165a month in Azure usage
- ~$92a month cut, without slowing anything down
- 3,685emails delivered in one newsletter send
In short
- One platform now runs direct messages and group chat, email and newsletters, events and ticketing, mentorship, scholarships, local chapters, and our AI programs.
- Each capability runs on whichever donated cloud does it best for the money: Azure for the app, data, and AI; AWS for email and real-time chat; Google for maps and search ads. Cloudflare runs the edge and Stripe handles ticket payments.
- Azure usage runs about $120 to $165 a month, inside Microsoft's $2,000-a-year nonprofit grant. Almost everything is pay-per-use, so cost follows the community, not a seat count.
- Cost is treated as a product metric: every change is explained, and I keep spending that buys security or speed even when cutting it would look good on a chart.
The problem
SOMOS.tech started the way most volunteer groups do: a website builder for the site and the mailing list, an event platform for RSVPs, and whatever chat tool people already had. By the time we moved, 3,406 of our contacts lived in the website builder, events lived somewhere else, and conversations lived nowhere we could moderate.
That stack has three problems for a nonprofit. The price grows with the community, which punishes exactly the growth you want. The data is split across vendors, so nobody can see a member's whole journey from first event to mentorship. And none of it can be made safe or smart on our terms: no shared moderation, no risk signals, no AI that knows our programs.
Constraints
- No paid staff. A small volunteer team, so anything that needs babysitting is a liability.
- Fixed credits, not a budget line. Donated cloud credits cover a set amount, and every service has to fit inside them with room to grow.
- Security can't be the thing we skip. Members trust us with their identity, messages, and payments.
Options I considered
| Option | Why not, or why |
|---|---|
| Keep renting tools and connect them with automations | Rejected. Fastest to start, but cost scales with contacts, data stays split, and moderation and risk controls stop at each vendor's edge. |
| Self-host open-source community software | Rejected. Lower license cost, but always-on servers to patch and pay for, with a volunteer team on call for all of it. |
| One platform on donated cloud credits, pay-per-use by default | Chosen. Serverless by default, so idle costs close to nothing and cost tracks real use. Each capability goes to the provider that does it best for the money. The one fixed cost I chose on purpose is a small always-warm baseline for the API (see below). |
What runs where
| Capability | Runs on | Why there |
|---|---|---|
| Website, API, member data | Azure serverless hosting and database | Pay per request, covered by Microsoft's nonprofit sponsorship |
| AI programs and moderation | Azure AI services | Same credits, and data stays inside our own cloud tenant |
| Email and newsletters | AWS | Priced per email. One newsletter send delivered 3,685 emails |
| Direct messages and group chat | AWS | Real-time delivery that scales with use, replacing a premium hub sized for traffic we never had |
| Local Spots map | Google Maps | The maps members already know |
| Search ads | Google Ad Grants | In-kind ads for nonprofits, so finding us costs nothing |
| Paid event tickets | Stripe | We only pay when someone buys a ticket |
On top of that sits everything a member actually sees: sign-in with the account they already have, a community feed, local chapter groups, events with RSVPs, tickets and QR check-in, mentorship, scholarships, digital badges, a one-tap email preference page, and the AI programs.
Cost as a product metric
Credits make cost invisible until they run out, so I made it visible. A cost explainer ties every change in spend to its cause: more traffic, an email wave, image generation, deploys. When daily spend rose 27% over a few days, it showed the cause was healthy growth (a community event week and four chapter emails), not a leak. Each AI program's usage is tracked on its own ledger.
Then I cut what wasn't earning its keep, and kept what was:
| Decision | Reasoning | Effect |
|---|---|---|
| Retired a second edge network | Cloudflare already did the job, with the firewall managed as code | About $31 a month saved |
| Moved real-time chat to AWS | We paid for peak capacity we never used | About $61 a month saved, with more headroom |
| Moved all email to one provider | Two providers meant two sets of failures and limits | One place to fix deliverability, one bill |
| Trimmed CI and batched pushes | A habit of pushing every small change used a month of included build minutes in three days | Each run down to about 7 minutes |
| Kept malware scanning of uploads | It keeps malicious files away from members | Cost kept on purpose |
| Kept always-warm API instances | Without them, members waited 10 to 20 seconds on a cold start | Cost kept on purpose |
The cheapest version isn't the goal. The goal is the most community per credit dollar without making members wait or making them less safe. Two of the six decisions above were to keep spending.
Tradeoffs I accepted
- Three clouds means three attack surfaces. That's why I built attack surface monitoring and an account audit-log monitor, so a change on any of them shows up.
- A small team. Knowledge can't live in one head, so the rules are written down (41 of them, each from an incident), and AI agents help operate the platform under limits they can't change.
- Credits can change. Pay-per-use means nothing large is locked in. If a provider's terms change, a capability can move, as chat and email already did.
- Free tiers have cliffs. A monthly free compute grant runs out in the first days, so the first of the month always looks cheaper than the rest. I read cost by cause, never by one day's total.
What I'd do differently
- Build the cost explainer first, before the first big bill, not after it.
- Pick one email provider from day one. The move between providers was compressed, and the first weeks on the new one surfaced edge cases I'd rather have found slowly.
- Size real-time capacity from measured use, not from what a large community might someday need.
Why it matters beyond SOMOS.tech
Most community nonprofits could run this way, and almost none do, because nobody shows them how. That's part of why I teach: SOMOS.tech AI Labs ends with members deploying their own apps to the cloud, and our Build Your Agents workshops have members build working AI agents themselves. The platform is the proof that a volunteer group can own its community, its data, and its AI, without renting any of them.