Production SaaS for B2B products where auth, billing, and tenant boundaries cannot drift
This is the work I do when the product has to survive contact with real customers. Multiple companies in one system. Different roles. Payment state that has to be defensible. Tenant boundaries that cannot leak because one query forgot where it was.
I build the backend, product architecture, and user-facing flows that make that hold up. Auth, billing, permissions, tenant logic, background jobs, admin tooling. The parts that get expensive when they're bolted on late.
Based in
Los Angeles, CA
Best for
B2B founders, operators, and investor-backed teams that need the technical decisions thought through, not just executed.
Outcome
A system you can actually run in production, not a one-off demo that collapses under real usage.
- The product serves multiple businesses, client accounts, or internal roles, and the tenant boundary matters as much as the UI.
- Money, access, or entitlements are part of the product, so browser state cannot be the source of truth.
- You are replacing a spreadsheet-plus-email process with software that has to stay correct as usage grows.
- You need someone to think through roles, data ownership, billing behavior, and failure modes before they become support tickets.
- Product architecture for auth, roles, permissions, tenant isolation, and the data model behind all of it.
- Billing flows with Stripe, subscriptions, invoices, usage controls, and signed webhooks handled server-side.
- Operator and admin surfaces for support, onboarding, and edge-case handling that real products always need.
- Background jobs, APIs, and internal workflows so the product stays responsive while the heavy work runs elsewhere.
- Tenant isolation is enforced in the data layer, not left to the UI to behave itself.
- Payment and subscription state come from verified backend events, not from whatever the browser says after a redirect.
- Environments, secrets, and migrations count as product work too, because broken configuration is still downtime.
- Who can do what, who can see what, and what happens when a dependency retries twice are all decided on purpose.
I don't separate product thinking from engineering. The risky part of a SaaS product is usually not the React component. It's the mix of roles, data ownership, billing logic, and ugly operational edge cases underneath it. That's where I'd spend the time first, because that's what prevents the rewrite six months later.
Claro
Multi-tenant marketplace with per-vendor storefronts, Stripe Connect payouts, purchase gating, and tenant rules enforced where they belong.
View case study →Dotty
Invoice and payment portal with Row Level Security, Stripe Checkout, and paid state driven by verified webhooks instead of wishful frontend state.
View case study →FunnelScout
B2B SaaS with tenant-scoped analysis, billing limits checked before AI spend, and agency data isolated query by query.
View case study →If this sounds like the shape of the problem, send me what the workflow is doing today, where it breaks, and what has to stay true in production. I care less about the pitch and more about the constraint.