Brian LaRose — I design and build the backend logic small businesses run on: CRM automation, AI drafting, booking flows, and the custom checkout and billing systems off-the-shelf tools can't quite handle on their own.
Not simulations — these are live or recently-shipped systems built for real clients. Each one replaced a manual step, or a process that was quietly broken, that was eating someone's week.
The problem: a certification's pricing — four renewal-prepay tiers stacked on four volume-discount tiers, 16 real prices in all — needed one-time checkout pricing that Stripe's own tiered-pricing model doesn't support outside subscriptions.
A Cloudflare Worker computes the exact price at checkout time instead of relying on a static Stripe Price object, then gates actual course access behind a separate signed-agreement step — so a successful charge creates a pending order, not instant access. When told the system was already live, I ran a real purchase through it and found it wasn't: no webhook configured, two missing secrets, and a dead post-payment redirect. All three got fixed before it shipped.
read the full case study →The problem: clients wanted to book a recurring appointment by describing it in plain English — "every other Tuesday at 2pm starting next month" — not by clicking through a calendar picker date by date.
A webhook sends the request to Claude, which extracts a structured recurrence rule. A code step computes the exact calendar dates — handling daylight-saving transitions correctly — and returns a preview before anything is booked. Once confirmed, a second workflow deduplicates the contact by email, batch-books every date straight into GoHighLevel's calendar, and isolates failures so one bad slot never breaks the rest of the batch.
read the full case study →The problem: after every college-admissions call, the owner was writing a personalized follow-up email by hand. As her call volume grew, that was the first thing to fall behind.
One workflow logs every booked appointment into a data table with the contact's name and email. A second picks up the Fathom transcript the moment a call ends, works out which of her several call types it was, and matches it back to that booked appointment to recover the contact details Fathom's own webhook doesn't carry. The transcript, plus a sample of her past emails, goes to OpenAI to draft a follow-up that actually sounds like her. The draft lands in her Gmail; she gets a heads-up it's ready, and reviews and sends it herself.
read the full case study →The problem: a registration funnel needed to split signups evenly 50/50 between two reps, per pricing tier — a plain workflow counter breaks the moment two people register at the same second.
Slot assignment runs through a dedicated Postgres function instead of a counter sitting in the workflow, so two simultaneous registrations can't land on the same slot. Every registration is deduplicated by a contact-plus-event key, a VIP upgrade moves the pipeline stage without reassigning the rep who already has the relationship, and the slot reservation only finalizes once GoHighLevel confirms the opportunity was actually created.
read the full case study →The problem: onboarding a new client meant manually creating their portal access, every time, from scratch.
An inquiry-form webhook checks the contact against Supabase before doing anything else — and that check is written defensively, because Supabase's REST API can hand back the same "does this exist" answer in two different shapes depending on how many rows match, so the parsing step explicitly handles both rather than assuming one. If the client's new, it sends a native Supabase invite email that redirects straight into their actual portal, then inserts their record using the same ID Supabase just minted for their login — so the CRM row and the portal account are the same identity from the first insert, not two records stitched together after the fact. Submit the form twice and the second one is a no-op.
I've run Mountaintop Virtual since 2019 — a systems and automation practice built around one idea: most "we really should automate that" problems are smaller than they look once someone sits down and actually builds the thing.
I've been hands-on in GoHighLevel for 3+ years, led a full client migration off Kajabi onto it, and keep a dozen n8n workflows running in production at any given time — but the real constant across jobs isn't any one platform, it's figuring out exactly where a process breaks and wiring up whatever API or payment stack actually fixes it, GoHighLevel and n8n included when they're the right tool.