Grace AI

Australian trade businesses lose customers the same way everywhere does. The phone rings during a job, nobody answers, the customer calls the next name on the list. After-hours and weekends are even worse.

The owners I've watched run their businesses are usually checking missed-call lists at 9pm and trying to call people back the next morning, when half of them have already booked someone else.

Grace AI exists to fix that. A 24/7 voice agent picks up every call, has a real conversation, books jobs straight into the owner's calendar, syncs the customer into their job management software, and sends a confirmation. The owner wakes up to new jobs already on the schedule.

I built the entire web platform. The customer-facing dashboard, the booking flows, the subscription system, the integrations layer, and the API surface the voice agent talks to. The voice agent itself was built by a separate AI developer on the team. My job was to make the rest of the product real.

The dashboard is where business owners actually run their day. Inbound calls, customer profiles, job pipeline, recent bookings, subscription status, integration settings. Everything is one click from the home view. The whole thing is built in Next.js with TypeScript, with a NestJS backend running on PostgreSQL.

The ServiceM8 integration was the hardest part. ServiceM8 is the job management tool most Australian trade businesses run on. I built a full OAuth flow against their API, then a bi-directional sync that pushes new jobs from Grace into ServiceM8 the moment they're booked, and pulls customer updates from ServiceM8 back into Grace via webhooks. So the owner can keep working in ServiceM8 the way they always have, and Grace stays in lockstep automatically.

The subscription flow runs through Stripe with usage-based add-ons for call minutes. The hardest part wasn't the billing itself, it was making the call-minute accounting reconcile against what the voice agent reported back. That involved building an internal reconciliation job that runs nightly and flags anything that drifts.

A few choices were non-obvious. Webhooks over polling for the ServiceM8 sync, because trade businesses care about real-time job creation more than they care about bandwidth. NestJS over Express because the subscription and integration logic was getting complex enough that I wanted the structure. PostgreSQL over MongoDB because the customer-job-call relationships are deeply relational and I didn't want to fight a document store.

The voice agent talks to the platform through a dedicated API layer rather than writing directly to the database. That boundary matters. It means the agent's contract with the platform is explicit, versioned, and testable independently of the web app. It also means a different voice agent could slot in later without touching the platform internals.

AWS Amplify for the frontend hosting because the client was already running infrastructure there. Vercel would have been my first choice, but pragmatism wins over preference when someone else is paying the bills.

A plumber finishes a job, gets back in the van, and his phone has three new customers booked. He didn't make any of those bookings. The voice agent did.

By the time he checks the dashboard at the end of the day, the jobs are in ServiceM8 already, the customers are in his pipeline, and Grace has flagged one of them as a likely upsell because of how the call went.

That's the product.

Two things mostly. First, that the gap between “the software works” and “the business owner actually uses it” is huge, and usually has nothing to do with code. The owners who got the most out of Grace were the ones I spent time on the phone with after launch, walking through how they actually answered calls today. Second, that AI products are 20 percent AI and 80 percent integrations. The voice agent gets the headline. The thing that made Grace actually useful to a plumber in Brisbane was that it talked to ServiceM8.