An Honest Utomat Review, Written by Me

I built Utomat, so I'm probably the last person you'd expect to write an honest review of it. But someone has to, and I'd rather it be me than a content farm.

A few months ago someone emailed me to say they'd been Googling "utomat review honest user experience" before reaching out. They wanted to know what working with me was actually like before committing to anything. Which is completely reasonable. I do the same thing before I pay anyone for anything.

The problem is that I'm the one who built Utomat, AI automation, built in public. There's no third-party review site where strangers weigh in. So I'm going to do something a little unusual and write the review myself, as honestly as I can. You'll have to decide if you trust me.

What Utomat Actually Does

I build automation systems for small businesses. Not the "connect these two apps with a Zapier zap" kind, though I've done plenty of that too. The kind where you have a real, annoying, human process eating someone's hours every week, and I figure out how to make it not require a human anymore.

Sometimes that's a voice AI that answers calls and books appointments. I built CallCrewHQ for exactly that use case, it answers every call for a trades business, handles the after-hours enquiries, and stops jobs from falling through because nobody picked up. Sometimes it's a lead flow. Grease Trap Quotes delivers three quotes by SMS in sixty seconds because the old process involved someone manually calling contractors. Neither of those was technically complicated. Both saved real hours.

That's the core of what I do: find the thing you're doing by hand that doesn't need a human, and stop making you do it by hand.

What It's Like to Actually Work With Me

Here's where I'll try not to make this sound like a brochure.

The first conversation is usually a diagnosis

Most people who reach out have a vague sense of "I should probably automate something" but haven't pinned down exactly what. The first conversation is mostly me asking questions. What are you doing manually? How often? How long does it take? What happens when it goes wrong?

About half the time the answer is obvious within fifteen minutes. The other half requires looking at the actual system before I can say anything useful. I'll sometimes ask for a screen recording of someone doing the task, or a walkthrough of the tools they're already using. This isn't billable, it's just how I figure out whether I can actually help before either of us wastes time.

I build things, I don't sell platforms

I'm not a reseller for any particular tool. I'll use whatever's right for the job. Sometimes that's a no-code platform. Sometimes it's a bit of custom code. I've migrated things off platforms when the platform stopped being the right answer, I wrote about one of those experiences in detail in Why I moved my studio site off Firebase, Utomat. The short version is that I'll tell you when a tool has outgrown its usefulness, even if it's inconvenient.

Timelines are honest, not optimistic

I've learned to stop giving people the timeline I wish were true. If something is going to take three weeks, I say three weeks. The research on project delivery is grim: a KPMG global project management survey found that less than a third of projects are completed on time and on budget. I'm not immune to that. Scope changes, integrations behave unexpectedly, things come up. I'd rather set an honest expectation than a cheerful one.

What Utomat Is Not Good For

This is the part of any honest review that the subject usually skips. I'll give it a go.

Very early-stage businesses

If you're still figuring out your core process, automation will just make a broken process run faster. I've had a couple of conversations with founders who wanted to automate before they'd done anything manually enough times to understand what the process actually needed to be. I usually tell them to come back in a few months. Automating chaos doesn't reduce chaos.

One-off tasks

If you need something done once, the math almost never works out. Automation only makes sense when you're doing the same thing over and over. The Pragmatic Engineer newsletter and others have written extensively about this, time invested in automation needs to be amortized over many repetitions. A task that happens twice a year probably isn't worth automating.

If you need deep domain expertise in your industry

I know automation and software. I don't know your industry the way you do. I'll learn enough to build the right thing, but I'm not going to walk in with a pre-built industry solution. What I build is custom to how your business actually works, which takes time and your involvement.

The Actual Experience, Project by Project

I won't give you a fake case study with a made-up company name and suspiciously round numbers. What I can tell you is the shape of how projects tend to go.

Small, contained automations, a form that routes leads, a CRM that logs calls, an email sequence that triggers on a purchase, tend to go quickly. A week or two, a few rounds of testing, done. Ongoing maintenance is minimal.

Larger builds, where there are multiple systems talking to each other and a real workflow being replaced, take longer and need more back-and-forth. The businesses that get the best results are the ones who treat it as a collaboration rather than a handoff. They know their process better than I do. I know what's technically possible. The best work happens in the overlap.

A McKinsey report on automation adoption noted that tasks most amenable to automation are those involving predictable physical activity and data collection or processing. My experience matches that completely. The more rule-based and repetitive the task, the cleaner the outcome.

One Thing I'd Change

If I'm being fully honest: I don't document things as thoroughly as I should during early-stage builds. I've gotten better at this, but it's still the thing I catch myself skimping on when the build itself is going well. Good documentation means handoffs go smoothly and future changes are easier. I know this. I still sometimes rush it. I'm saying it here as a form of accountability.

Where to Learn More Before You Decide Anything

The Blog, Utomat has a bunch of posts where I write about specific automation problems and how I think about solving them. Most of them are useful regardless of whether you ever work with me. The About, Utomat page has more on how I work and the kinds of projects I take on.

If you're still on the fence after all of that, just email me. Ask the awkward questions. I'd rather answer them upfront than have you find out later that I wasn't the right fit.

If something I described sounds like your situation, get in touch and we can figure out together whether it's worth pursuing.

An Honest Look at My Own Work: What Utomat Actually Is and Isn't