Rescuing a broken Stripe layer, then building the marketplace around it.

The Stripe rescue: webhook + checkout diagnostic.

The fastest way to fix a broken Bubble.io to Stripe integration is to stop assuming the integration is the problem and start checking the seams. The seams are: the API Connector call configuration on the outbound side, the Stripe webhook receiver workflow in Bubble’s backend workflows, the parameter shape Stripe sends back, and the Bubble database fields the workflow writes to.

The version I inherited had a mix of issues across all four seams. The API Connector calls had hardcoded test-key endpoints in places that should have been live. The webhook receiver was registered for the wrong event types. The workflow that processed checkout.session.completed was looking for parameter paths that did not match Stripe’s actual payload structure. The Bubble user record was not getting the Stripe customer ID written back, which meant every subsequent action was orphaned.

The rescue was a careful walk through every seam, fixing each one, and verifying with the Stripe Dashboard’s webhook delivery log that events were landing and the right Bubble workflows were firing. Boring detective work. Two weeks of it took the checkout from “broken in production” to “collecting payment cleanly on the first attempt.”

Email: rescue Sendinblue first, then migrate to Postmark.

The transactional email layer (signup confirmations, password resets, order receipts, contract notifications) was failing the same way the Stripe layer was failing. The original integration was Sendinblue: the API Connector calls had been configured against a since-rotated key, and the workflow triggers were pointed at the wrong events. The user-facing symptom was identical to the Stripe one: the happy path looked fine to the founder, but anyone who actually signed up never got the confirmation email and could not complete onboarding. The first fix was the same pattern as the Stripe rescue. Audit every send point. Re-key against a current credential. Re-test every trigger end to end.

Once Sendinblue was reliable inside the app, the deliverability outside the app was the next issue. Sendinblue’s bounce rates on transactional sends were higher than the marketplace needed for password-reset and contract-notification emails (the two paths where a missed email blocks a user from completing an action). We evaluated the alternatives and migrated the platform to Postmark, which is built for transactional and historically posts the lowest bounce rates among the major providers. The migration was straightforward (Postmark’s API surface is small and the Bubble.io API Connector calls were one-for-one swaps), but the deliverability win was real and immediate.

Payment escrow, in the basic shape of how Upwork holds money.

Once the rescue work was done and trust was earned, the founder wanted the harder feature: a payment-holding flow so customers paid up front, funds sat with the platform, and the vendor was paid only after the customer confirmed the work was complete. The marketplace had work-hour contracts and gig-based contracts; both needed the same release mechanism.

The architecture used Stripe Connect’s separate-charges-and-transfers pattern. The customer paid the platform account at checkout (charge created, funds settled into the platform’s Stripe balance). The vendor was set up as a connected account during onboarding through Stripe’s hosted onboarding flow. When the customer marked the work complete inside the Bubble app, a backend workflow fired a Stripe Transfer from the platform balance to the connected account, less the marketplace fee. Disputes paused the release; refunds reversed the charge and the held balance returned to the customer.

This is the same conceptual shape as Upwork’s basic escrow model. The implementation was a few weeks of work: the Stripe Connect onboarding flow, the backend workflows for charge/release/refund, the customer-side confirmation UI, the vendor-side payout visibility, and the dispute hold logic. Boring infrastructure that turned the marketplace from “we move money” to “we hold money trustworthily.”

Multi-vertical expansion, scaled to the founder's industry-specific vision.

The product launched restaurant-focused. Over the back half of the engagement the founder wanted to add five more verticals: back-of-house roles, events and private hire, virtual assistants for food businesses, sales and marketing, and writing and content creation. Each vertical had its own onboarding fields (a line cook’s profile is not a content writer’s profile), its own rate model (hourly versus per-piece versus seasonal), and its own dashboard variant. The founder had specific, industry-informed ideas about what each onboarding should ask. My job was to implement those ideas in a shape that would absorb the next five without a rewrite each time.

The naive approach is to duplicate the onboarding flow, the profile data type, and the dashboard for each vertical. That is a per-vertical rewrite, and the product would have been five times the maintenance surface in three months. We did not go that way.

The architecture used a Bubble Option Set for the vertical types, with each vertical option carrying its own configuration (allowed rate models, required onboarding fields, dashboard variant key). The onboarding flow read the selected vertical from the Option Set at runtime and rendered the right field set. The dashboard used Conditional Visibility on the vertical-specific sections. Adding a new vertical was a row edit in the Option Set plus a few new field definitions, not a copy-pasted flow.

The same pattern showed up across the platform: experience-level tiering (Semi-Pro to Super User), business-type registration (Restaurant, Caterer, Event Organizer, Other), and job-type filtering (On-Demand, Ongoing, Seasonal, Event) all ran off Option Sets read at runtime rather than per-variant hardcoded UI. The freelancer-facing job filters that let a back-of-house worker filter out front-of-house roles ran off the same Option Set machinery, so the search UX matched the founder’s intent without per-vertical query branches.