How I Vibe Coded a Job Dispatch System Using Claude
A step-by-step look at how I built a production automation system for field service businesses by describing what I wanted in plain English.
Six months ago I decided to build SendJob — a backend automation system that handles the complete job lifecycle for HVAC companies, plumbers, and other field service businesses.
I had a clear picture of what it needed to do. I had the tools picked out. What I decided to do differently this time was build as much of it as possible by talking to an AI.
Not generating boilerplate. Not autocompleting functions. Actually describing what I wanted to build in plain English and iterating on the output until it worked.
This is what that process looked like — the method, the wins, the failures, and what I’d do differently.
What Is Vibe Coding?
Vibe coding is a term that’s caught on recently to describe this style of building: you describe what you want to an AI, you review what it produces, you correct or expand, and you repeat. You’re the director. The AI is the builder.
It’s not magic. The output is only as good as your ability to describe what you need and evaluate what comes back. But it dramatically compresses the time between idea and working thing — especially for people who know what they want to build but get slowed down by implementation details.
The System I Was Building
SendJob automates the job lifecycle for field service businesses:
- Job created → customer gets a confirmation text
- Dispatcher assigns a technician → dispatcher gets an alert
- Tech accepts the job → customer gets a notification
- Tech goes enroute → customer gets an ETA text
- Tech arrives → customer gets an onsite notification
- Job complete → customer gets a payment link via text
Seven distinct workflow steps. Multiple integrations. Real-time database updates between each step.
The stack: n8n (workflows), Supabase (database), Twilio (SMS), Resend (email), Stripe (payment links).
How I Started: The Schema First
Before writing a single workflow, I described the data model I needed to Claude.
My prompt was something like:
“I’m building a job management system for field service businesses. Each job has a customer, a technician, a location, a status that changes over time, and a log of all notifications sent. What does the Supabase schema look like?”
Claude came back with a normalized schema: a jobs table, a customers table, a technicians table, a job_status_history table, and a notifications_log table. It explained why each table existed and flagged a question I hadn’t thought about: what happens to jobs if a technician is removed from the system? It suggested a soft-delete pattern.
That one exchange saved me from a design mistake I would have hit three weeks later.
Building the First Workflow: Job Creation → Confirmation Text
Once the schema was in place, I built the first n8n workflow.
My prompt:
“I need an n8n workflow that: 1) triggers via a webhook when a new job is created, 2) looks up the customer’s phone number from the Supabase customers table using the customer_id in the webhook payload, 3) sends a Twilio SMS to that phone number confirming the appointment, 4) updates the job’s notification_sent field to true in Supabase. Walk me through the node setup.”
What came back was a complete workflow structure with every node named and configured — the webhook trigger, the Supabase select query, the Twilio SMS node with the message template, and the Supabase update. I built it node by node following the output.
First test: it worked on the second try. The first attempt had a small issue with how I’d mapped the customer_id from the webhook payload — Claude caught it when I pasted the error back in.
The Pattern That Works
After building a dozen workflows this way, a clear pattern emerged:
1. Be specific about the trigger. Don’t say “when a job is updated.” Say “when a job’s status column changes to ‘enroute’ in Supabase.” The more specific the trigger, the better the output.
2. List every step explicitly. Write out each step as a numbered list in your prompt, even if it seems obvious. “Step 1: Get the job record. Step 2: Get the customer record. Step 3: Format the message. Step 4: Send the SMS.” Claude builds what you describe.
3. Paste errors directly. When something breaks, don’t try to summarize the error. Paste the full error message and the relevant node configuration. The diagnosis is usually right on the first response.
4. Ask for the simple version first. My default now is to add “give me the simplest version that works — we can add error handling later” to any prompt for a new workflow. Otherwise you get enterprise-grade retry logic when you just needed a working proof of concept.
Where It Got Hard
Twilio’s API specifics
Claude’s training data on Twilio’s API was slightly outdated in places. The authentication format, the way status callbacks are configured, the exact endpoint for sending an MMS vs SMS — these needed verification against Twilio’s actual docs.
Rule: for third-party API specifics, always cross-check against the official documentation. Don’t trust AI blindly on version-sensitive details.
Multi-step workflow state
The more complex workflows — where the state from step 1 needs to be available in step 5 — required more careful prompting. I learned to explicitly say “carry the job_id through every step and use it for all Supabase lookups” rather than assuming Claude would maintain that context.
When to stop iterating
Sometimes I’d get a workflow that was 90% right and spend too long trying to get Claude to fix the last 10% in chat. Sometimes it’s faster to just open the node and fix the last piece manually. Knowing when to switch modes is a skill you develop.
What Got Built
After about six weeks of building this way, SendJob had:
- 7 core automation workflows
- A complete Supabase schema with 8 tables
- Webhook endpoints for every status change
- SMS templates for every customer-facing touchpoint
- A payment link generation flow connected to Stripe
- An internal dispatcher alert system via Resend
A significant portion of that was built by describing what I needed in plain English. The parts that weren’t — mostly Twilio edge cases and some custom Supabase functions — were the places where I went heads-down and wrote things manually.
What This Means for You
You don’t have to be a developer to build useful automations. You do have to be able to:
- Clearly describe what you want to happen
- Understand the tools well enough to evaluate the output
- Debug by describing what went wrong
If you can do those three things — and you can learn them — vibe coding is a real and powerful way to build.
The first automation I’d suggest building: an appointment confirmation text. Pick a simple trigger, one message, one destination. Get that working. Everything else follows from there.
Want to follow the full SendJob build? Subscribe below — we document everything.