New York City ยท Remote

I put AI into production and keep it honest. Not demos. Things that run.

I'm Stevon Judd, co-founder and former CTO of SquadTrip, a Techstars-backed group travel and payments platform, where I remain a technical advisor. Roughly $12M in annual booking volume, 20,000 customers, live money movement on Stripe Connect. I find where a team is losing time, build the automation that removes it, and measure whether it worked. I also run Judd Advisory Group, advising companies on AI operations and internal tooling.

$12M annual booking volume 20,000 customers 1,087 tests from zero coverage Techstars NYC '22
Scroll

Agent tooling and guardrails

An agent workflow layer that runs real support, payments, and engineering work at SquadTrip, and the rules that keep it from doing damage.

01

A workflow layer that replaces manual investigation.

Questions that used to mean opening five systems and cross-referencing by hand now run as one command. The layer is built on Claude Code: 16 orchestration commands and 10 MCP integrations across Intercom, production SQL, Stripe, Jira, Honeybadger, PostHog, and Azure.

Evidence: This is the daily operating layer at SquadTrip. The same commands run support, payments, engineering, and analytics work against live systems.
02

Nine agents on one support ticket.

A support-investigation command dispatches nine parallel agents against a single ticket: conversation history, account state, payment records, error logs, product analytics. Answers are confidence-gated, and every run leaves an audit log.

Evidence: Support answers with the account in front of them instead of a guess, and there is a record of how every answer was produced.
03

Guardrails that make agents safe on real systems.

Codified safety rules. Pre-tool hooks that block secret-file creation and gate any edit to payment code. Evidence-before-assertion verification. Human approval on every customer-facing send and every production write.

Evidence: AI never sends unsupervised on anything involving money. The failure mode is a customer told something wrong about their own payment, and that costs more than every hour the automation saved.

The infrastructure around the agents

Agents are only as trustworthy as the systems they run on. So I built the testing, release, and reconciliation layers too.

Test infrastructure from nothing

1,087 Playwright and unit tests across 115 classes where zero end-to-end coverage existed. Flaky-test detection over a rolling 200-run history. Regression runtime cut from 110 minutes to 24 through partitioned parallelization designed around a shared-state dependency chain.

110 minutes to 24

Release and observability

CI/CD with environment swapping, health endpoints that expose the deployed commit so slot swaps can be verified, and automatic smoke tests on deploy. Honeybadger and PostHog instrumentation feed a Slack ops center running 15-minute health checks and daily digests across SQL, storage, Stripe, and third-party services.

Checked every 15 minutes

Payments integrity

Daily reconciliation across 2,000+ connected Stripe accounts catches charges the processor had and the database didn't. Structured decline capture made $45K of previously invisible installment failures queryable. Found and fixed a defect that had left 68% of connected accounts unscanned.

$45K made queryable

The rule behind all of it: freeze a baseline before you ship, so "it worked" is a number and not a feeling. And if I do something twice, I build a system the third time.

Work you can check the numbers on

SquadTrip AI Support

Grounding an AI support agent in what is actually true.

SquadTrip's support bot answers customers directly, so before making it smarter I checked whether it was right. I verified 176 help articles against source code, production data, and payment-processor ground truth.

That surfaced 340+ corrections, now staged behind human sign-off. It also caught 10 answers the bot was already serving customers that were materially wrong.

First, though, I froze a 68.1% resolution baseline across 552 conversations. The corrections are staged behind sign-off, and impact will be measured against that baseline rather than asserted.

176 articles verified. 340+ corrections staged. 10 materially wrong answers caught before more customers saw them.

Background 12+ years

How do you move 200 enterprise customers without any of them noticing?

As a Senior Technical Program Manager at MongoDB, I led a migration of 200 enterprise customers across 8 internal organizations with zero disruption. For infrastructure products, reliability is the product. Invisible meant we did our job.

Before that: Technical Architect at Accenture. Started as a COBOL developer at New York Life. 12+ years of building for systems where being wrong costs real money.

200 enterprise customers migrated across 8 organizations. Zero disruption.

Side Projects Off the Clock

The same instinct, off the clock.

A World Cup 2026 bracket pool for eight friends. Next.js on Railway Postgres, shipped against a hard first-match deadline.

A Spades tournament tracker. Self-contained HTML on Vercel, updated by dropping in game screenshots and having them parsed into standings and head-to-head records.

Nobody asked for either. That is the point. When I see friction, I build the thing that removes it, whether or not it is my job that day.

Think you can ship it?

A scenario built from decisions I've faced. Make the calls. See what happens.

The Summer Rush

Summer travel season starts in 3 weeks. You're about to launch Group Payment Splitting, the most requested feature from your biggest customers. Trip organizers can finally split costs automatically instead of chasing Venmo payments.

Engineering says it's ready. Marketing has already teased it. Your largest customer, a travel agency, is planning their entire summer around this feature.

Then three things happen at once.

Monday Morning

The QA Flag

Your lead engineer pulls you aside. The refund flow has edge cases nobody has fully tested. If someone partially pays, then requests a refund, then the trip gets canceled, she isn't sure what happens to the money.

She estimates 4-5 days to properly test and fix. But that pushes you past the marketing launch date, and your big customer's first summer trip is in 18 days.

What's your call?

You chose: Delay the launch

Reasonable, but...

Marketing is frustrated. They've already sent the teaser email. Your big customer calls you directly, concerned. They've already told their travelers it was coming.

You spend the week managing expectations instead of shipping. The feature launches clean, but you've burned some trust and lost momentum.

The lesson: Delays have costs beyond the timeline. Sometimes the right call is scoping down, not pushing back.

You chose: Ship without refunds

Smart scope cut.

You ship on time. The core flow works perfectly. You're transparent with customers: split payment refunds go through support for now, and full automation follows.

A few refund requests come in. Support handles them manually. No drama. The feature lands.

The lesson: Perfect is the enemy of shipped. Scoping down beats delaying when the core value still works.

You chose: Ship and hope

This will cost you.

Then it happens. A trip organizer cancels a trip mid-payment. The system creates a negative balance. Their bank flags it as fraud, and they're locked out of their account during their busiest booking period.

You drop everything for damage control. The customer is furious. You fix the bug under pressure instead of properly.

The lesson: "It probably won't happen" is not a risk mitigation strategy. Edge cases in payments always find you.

Wednesday

The Compliance Surprise

Your payment processor sends an email: new money transmission regulations require additional disclosures for "payment facilitation services," which is exactly what split payments are.

Legal review will take 5-7 business days. Without it, you could be operating in a gray area. Your processor has flagged accounts for less.

What's your call?

You chose: Full pause

Safe, but slow.

Legal takes the full review window. Turns out the regulation applies to a different payment model. You were fine all along. You lost the time to uncertainty a single phone call could have resolved.

The lesson: "Wait for legal" isn't always the responsible choice. Understanding the actual risk often takes less time than waiting for formal review.

You chose: Limited rollout

Creative, but complicated.

You now have two launch tracks: existing customers get the feature, new customers don't. Your support team is confused. Your docs say one thing, your app says another.

Legal clears you partway through the wait. But you've created operational complexity that takes longer to unwind than the head start was worth.

The lesson: Partial solutions often create more work than they save. Sometimes it's better to wait or push forward, but not both.

You chose: Pick up the phone

This is the move.

Your contact at the processor explains it in one short call: the regulation targets platforms holding funds in escrow. You don't do that. Money goes directly to trip organizers. You're fine. They confirm via email.

You share the email with legal, they confirm quickly, and you're unblocked.

The lesson: Process isn't always the answer. Relationships and direct communication often resolve ambiguity faster than formal review.

Thursday

The Customer Call

Your biggest customer calls. They've already told their 200+ summer travelers that split payments are coming. Their first trip departs in 16 days.

They've been a partner for two years, and they need a straight answer: can they count on this, or should they tell their travelers to collect money the old way?

You're 80% confident you'll ship on time. But it's not certain.

What do you tell them?

You chose: Promise delivery

Confidence without certainty is a liability.

You ship late. The customer already told their travelers. Now they look bad, and they blame you.

The relationship survives, but there's a crack in the trust. Next time they'll wait to see it live before they believe you.

The lesson: Promising certainty you don't have erodes trust faster than admitting uncertainty ever would.

You chose: Honest uncertainty

Trust is built in moments like this.

You tell them you can't promise the exact date. What you can promise is that they'll hear the moment you know more, and that if their first trip is at risk, they'll hear it from you first.

They appreciate the honesty. They have a backup plan ready. You ship on time anyway, and now they trust you more because you didn't oversell.

The lesson: Customers don't need certainty. They need honesty and a partner who manages risk with them, not for them.

You chose: Buy time

Reasonable, but you're avoiding the conversation.

You call back with more information, but you've signaled that you didn't know your own status. They're slightly less confident in you.

The delay wasn't necessary. You had enough information to have a real conversation. You just didn't want to have it.

The lesson: "Let me get back to you" is sometimes just avoidance in professional clothing. Know when you're ready to have the conversation.

The Result

You shipped it.

Group Payment Splitting launched ahead of your biggest customer's first summer trip. Travelers used it right away, and the support tickets asking how to collect money from a group started to disappear.

What this scenario is really about:

Running a payments platform isn't about having the right answers. It's about making decisions with incomplete information, communicating honestly under pressure, and knowing when to scope down versus when to hold the line.

The tradeoffs in this scenario are real. The specifics are constructed.

Let's talk

The role I'm looking for

I'm targeting full-time AI Operations and internal platform roles: AI Enablement Engineer, AI Ops, Internal Tools, Developer Productivity, Platform Operations, and technical program management roles. Remote.

The work I want to do is the work on this page. Find where a team is losing time, build the automation that removes it, and prove it worked. If your team is trying to put AI into production without losing control of it, we should talk.

Who I want to hear from:

  • Hiring managers for AI enablement, AI ops, internal tools, developer productivity, platform operations, or technical program management roles
  • Companies that want AI in their operations with guardrails, through Judd Advisory Group
  • Operators working on the same problems, even with no engagement attached

Email me directly. I read everything.