Case Study · One Future Collective
Two websites. One team that keeps both running.
One Future Collective runs two distinct public-facing websites — onefuturecollective.org and SanskaariGirlsBookClub.com — each serving different audiences across advocacy, funder outreach, and community engagement. Both need to be on, clear, and working.
10hrs/mo
Saved across two active public-facing sites
99.97%
Combined uptime over XXXX months
2
Websites maintained under one Professional plan
Before NoDrama
Two sites, multiple audiences, and a team whose job is impact, not IT.
One Future Collective's team works across justice, gender, and leadership initiatives. They don't have — and shouldn't need — a person dedicated to watching two websites for plugin conflicts, backup gaps, or forms that quietly stop working.
Both sites were redesigned and launched by Pangolin. NoDrama took over maintenance from day one. The team briefs their content. NoDrama makes sure both sites stay up, stay secure, and keep performing for every audience that lands on them.
The honest audit
What we found when we looked.
The onboarding audit covered both sites simultaneously. Here's what it found.
No staging environment on either site.
Two live sites taking direct updates. For an organisation running funder outreach and community applications, a broken form goes straight to missed contact with the people they serve.
Default backup configuration on both sites.
Hosting-level monthly snapshots on each, neither tested. A restore drill was run within the first two weeks — one confirmed immediately, one needed a configuration fix before it was reliable.
OFC: Seven plugins due for major version updates.
Two had known vulnerability patches pending that had not been applied at launch. Held for staged testing before going live.
SGBC: Email signup form misconfigured.
A webhook error meant submissions were being recorded in the CMS but not forwarding to the mailing list. Silent failure, potentially weeks of lost community signups. Fixed in week two.
No uptime monitoring on either site.
Any downtime was being discovered manually, after the fact. For sites serving funder and community audiences, that's not a viable detection method.
The work
What we actually did. Specifically.
Dual audit: both sites
Both sites audited together. Seven items across the two sites prioritised and documented as a single brief.
Staging + backup setup on both sites
Configured staging environments for both. Upgraded to 12-hour off-site backups on each. Restore tests completed for both. SGBC restore confirmed working on day 12.
Vulnerability patches + form fix
Updated the two vulnerable plugins on OFC via staging, zero issues. Fixed the webhook misconfiguration on SGBC. Email signups now delivering correctly.
Remaining plugin updates across both sites
Updated the remaining five major-version plugins across both sites via staging. Visual regression confirmed. All pushed live.
Unified weekly cycle
Both sites on the same update schedule. Staging-first, visual regression, one report on the 1st covering both sites.
The results
XXXX months in.
10hrs/mo
Saved per month. Across two active public-facing sites
Hours the OFC team spends on advocacy, programmes, and community work, not on site administration.
99.97%
Combined uptime across both sites
Funder and community pages always available
0
Emergency calls in XXXX months
Across two live sites
2
Websites. One maintenance relationship.
Single report, single point of contact
In their words
We run two websites for two very different audiences, and neither of them is something I can afford to have go quiet at the wrong moment. NoDrama handles both. I get one report, everything is working, and I haven't had to think about either site since launch.
[Name TBC]One Future Collective · XXXX-month client
- 12-hour off-site backups
- 25-page visual regression testing
- 20GB CDN bandwidth
- 60 min/month support
- 12-hour response time
- Priority queue access