What I Actually Used AI to Build (And What Surprised Me)

I’ve been building software for a while. I know my way around a codebase. But when I decided to build SendJob — a full backend automation system for trades businesses — I made a decision that changed how I work: I would build as much of it as possible by talking to an AI.

Not copying code from Stack Overflow. Not following a tutorial. Talking to Claude like a senior developer who happened to know everything and never got frustrated.

Here’s what that actually looked like.

What I Was Building

SendJob automates the job lifecycle for service businesses — HVAC, plumbing, electrical. The basic flow:

1. A job gets created in the system
2. A confirmation text goes to the customer automatically
3. The dispatcher gets an alert and assigns a technician
4. The tech accepts the job and the customer gets a notification
5. When the tech is enroute, another text goes out
6. On arrival, another text
7. When the job is complete, a payment link gets sent via text

Simple to describe. A lot of moving pieces to actually build.

The Stack

• n8n for workflow automation (the backbone)
• Supabase for the database and real-time updates
• Twilio for all the SMS messaging
• Resend for email notifications
• Stripe for payment links
• Claude for building most of it

What AI Got Right

Complex workflow logic

This was the big one. n8n workflows can get deeply nested — conditional branches, error handling, retries, webhook configurations. Describing what I wanted in plain English and getting back a working workflow structure saved me hours. Maybe days.

I’d say something like: “I need a workflow that triggers when a new row is inserted into the jobs table in Supabase, then sends a Twilio SMS to the customer phone number in that row, then updates a notifications_sent column to true.”

And I’d get back exactly that — with the correct Supabase trigger configuration, the right Twilio node setup, and the column update at the end.

Supabase schema design

I described the data model I needed. Claude suggested a normalized schema, explained the trade-offs, and even flagged a problem I hadn’t thought of: what happens if a technician is assigned to a job but then the job is cancelled? I didn’t have a status history table. It suggested one.

Debugging

When something broke, I’d paste the error and the relevant workflow nodes into the chat and describe what was supposed to happen. The diagnosis was usually right on the first try.

What AI Got Wrong

Twilio-specific configuration

Twilio’s API is finicky. The authentication method, the exact endpoint format, the way you have to handle message status callbacks — Claude got these wrong a few times. The information in its training data was slightly outdated.

Lesson: for platform-specific API details, always verify against the official docs. Don’t trust AI blindly on third-party API specifics.

Over-engineering

Ask Claude to build something and it will sometimes give you the enterprise version when you needed the garage version. I’d ask for a simple notification system and get back something with retry queues, dead letter handling, and detailed logging from the start.

Sometimes that’s right. More often, early in a project, you want the simple thing that works. I learned to say: “Give me the simplest version that works. We can add complexity later.”

What Actually Surprised Me

The thing that surprised me most wasn’t a capability — it was a shift in how I think about building.

Before, I’d get stuck on implementation details and lose the thread of what I was actually trying to build. Now, when I hit a wall, I explain the problem to Claude and usually get unstuck in minutes. That keeps me in forward momentum.

The other surprise: I’m a better engineer because of it. Seeing how Claude approaches problems — breaking them into pieces, naming things clearly, thinking about edge cases — has made me more methodical in my own thinking.

The Honest Take

Building with AI is real. It’s not magic, and it doesn’t replace understanding what you’re building. But it dramatically compresses the time between idea and working thing.

SendJob is real. It runs on real infrastructure. It handles real jobs for real businesses. And a significant portion of it was built by describing what I needed in plain English.

That’s worth something.

---

Want to follow along as we build? Subscribe to the weekly brief below.