Upcurve

Nonprofits need a branded donation flow on every surface.

Cause-driven organizations want to spin up a campaign, take Stripe donations, manage donors and team members, and embed a donation widget on third-party sites — WordPress, Shopify, Drupal, plain HTML — without rebuilding their stack each time.

Hybrid auth, embeddable JS, multi-tenant from day one.

Upcurve uses Clerk for user/session identity and Supabase Row-Level Security for data ownership. Middleware bridges Clerk JWTs into Supabase SSR clients on every request — the auth and data layers stay decoupled but enforce together.

The embed surface is a public JS bundle (app/embed.js) that nonprofits drop onto any site with a single script tag to render a Stripe-backed donation widget. Production images are environment-pinned at build time — Stripe/Clerk/Supabase keys pass as Docker build args rather than runtime config.

Honest framing — feature contributor, not lead.

I'm a contributor on this codebase, not the lead engineer. Primary feature ownership belongs to Ashley Brooks, Andrew Thomas, and the broader Banyan team. My role across two identities (~61 of 1,370 commits) was focused features and bug fixes — donor-side flows, dashboard fixes, Stripe integration polish.

• Donor-flow improvements on a platform that processes real charitable donations.
• Bug fixes and feature work inside the standard Banyan develop → staging → main PR flow.
• Production exposure to multi-tenant SaaS architecture, Clerk + Supabase + Stripe + Railway, and the embed-widget pattern.

What it's built on.

Real donations, real customers, real codebase.

Upcurve is live and processes real charitable donations on a stack of Next.js 15, Clerk, Supabase RLS, Stripe, and Railway, with documented integrations for Shopify, WordPress, Drupal, and a Chrome extension. My contribution sits inside a five-plus-engineer team — that's the honest framing, and it's the version that holds up under reference checks.