RaiseNow Hub — self-service giving platform

Context

RaiseNow Hub is a self-service giving platform: nonprofit organisations create, configure, and publish donation forms without waiting on customer success for every change. The product has scaled to 54,000+ organisations onboarded — materially reducing CS involvement in routine setup and letting RaiseNow grow onboarding throughput.

I've worked on Hub end-to-end — configuration, publishing, payments, and cross-product behaviour — alongside Tamaro, RaiseNow's core donation and payment form product, so forms can be embedded, configured once, and kept consistent across surfaces.

Hub is members-only (no public marketing demo), so this write-up focuses on scope, delivery patterns, and outcomes rather than screenshots of live product UI.

What the platform covers

• Self-service lifecycle — organisations move from signup through form creation, payment method setup, branding, and publish without a bespoke implementation project for each customer
• Cross-product configuration — shared models so Hub settings and Tamaro-hosted forms stay aligned when organisations embed forms on sites or campaigns
• Payment activation — coherent onboarding for TWINT, Stripe, and PayPal inside one product narrative, not three disconnected wizards
• QR-based giving — donation flows designed for mobile and in-person use; QR became a standard part of RaiseNow's offering in the DACH region
• High-trust customers — customised donation experiences for global NGOs including UNICEF, WWF, and the Swiss Red Cross, with the usual bar for accessibility, cross-browser behaviour, and long-lived configuration

Hub ↔ Tamaro integration

Tamaro predates Hub but both products had to converge:

• Embedding — Hub-driven configuration mapped cleanly to Tamaro-rendered forms on customer sites
• Shared configuration — organisations weren't maintaining two sources of truth for the same campaign
• Coordinated delivery — new Hub capabilities often required Tamaro changes too, not isolated Hub-only UI

That pairing is why "platform scale" here means product + integration, not a single SPA in isolation.

Challenge

• Many payment contexts, one product story — regions, providers, and entitlement rules without fragmenting the self-service UX
• Interdependent codebases — Hub, Tamaro, and newer services shipping on different cadences; frontend had to absorb API churn safely
• Operational scale — when tens of thousands of organisations configure forms independently, small validation or state bugs become support load quickly
• Enterprise expectations — global NGO programmes need predictable behaviour more than flashy UI; regressions are reputational, not just technical debt

Approach

• Shaped shared configuration models so Hub admin surfaces and Tamaro runtime behaviour stayed aligned
• Built payment provider onboarding for TWINT, Stripe, and PayPal as first-class activation paths inside one product flow
• Contributed to TrueTurn frontend work with TWINT before it spun out as its own product — same payment UX discipline carried back into Hub/Tamaro
• Drove design system contributions that standardised component APIs across Hub, Tamaro, and partner-facing surfaces
• Mentored two junior frontend engineers through reviews and pairing so patterns stayed consistent as the team grew

Outcome

• Self-service at scale — far less routine CS involvement in form setup and publishing as organisations onboard independently
• Ecosystem coherence — Tamaro embedding and shared configuration made Hub a control plane, not a parallel product line
• Regional and payment breadth — QR giving and multi-provider activation became durable parts of RaiseNow's DACH and international footprint
• Volume context — the wider RaiseNow platform facilitates 300M+ in annual donation volume; Hub is the primary path for organisations entering and operating on that stack