What Utomat Is (And Why I Named It That)

I was sitting in my car outside a client's office at 6:47pm, answering a lead inquiry that came in at 2pm, because I'd been in calls all day and hadn't checked my inbox. The lead had already gone cold. I could tell from the reply, one line, polite, final. They'd found someone else.

That's the moment I stopped thinking about automation as a productivity trick and started thinking about it as infrastructure.

The Name Comes From a Simple Idea

Utomat is a portmanteau. "Utomat" collapses "automat", the old American cafeteria concept where you put a coin in a slot and a compartment opens, with the idea of a thing that just runs. No waiter, no kitchen visible, no friction. You need it, you get it.

That's the whole idea behind this blog. Not "how do you use Zapier" or "here's a Python script." The question underneath all of it: what would your business look like if the boring, repeatable parts just happened?

The Utomat, AI automation, built in public blog is where I think through that question out loud, building things and reporting back.

What Automation Actually Is (Not the Tool, the Principle)

Most people come to automation because they're tired. They've done the same thing forty times and they want to stop. That's a fine reason. But it leads to a certain kind of automation, reactive, piecemeal, held together with duct tape and good intentions.

The principle underneath good automation is different. It's asking: what is this process actually doing, at its core? Not "I send a follow-up email after a form submission" but "I am moving a signal from one state (interested) to another state (aware they're wanted)."

When you see it that way, the tool choice becomes almost secondary. You're solving a logic problem first.

What breaks when you skip this step

The number of business owners I've talked to who built an automation and then discovered it was automating the wrong thing is embarrassingly high. One person I know set up an automated SMS sequence for new leads. Fast, slick, well-configured. The problem: it was triggering on every contact form submission, including their own staff testing the website. They found out three weeks in when a team member mentioned getting followed up with six times in a day.

They automated the trigger, not the outcome. That's what happens when you skip the logic step.

Why I Build Things in Public

I'm not an influencer. I don't have a framework to sell. I build things, they work or they don't, and I write about what I learned.

Right now that includes:

• CallCrewHQ, an AI front desk that answers every call for trades businesses, so a plumber doesn't miss a job because they were under a sink
• Grease Trap Quotes, a lead aggregator that gets commercial kitchens three grease-trap cleaning quotes via SMS in under 60 seconds

Both of these started as solutions to problems I kept watching people handle manually. Tradespeople losing calls. Restaurant managers spending twenty minutes on the phone to get a single quote. The automation wasn't clever, it was just *doing the obvious thing* consistently.

I write about all of this on the Blog, Utomat so that the reasoning is visible, not just the finished product.

The Part Nobody Talks About: What You're Actually Buying Back

Time is the obvious answer. And yes, there's real data here, Salesforce research from 2024 found that sales teams spend only 28% of their week actually selling, with the rest going to admin and data entry. McKinsey has estimated that roughly 60% of occupations have at least 30% of activities that could be automated with existing technology.

But the thing you're really buying back isn't hours. It's decision capacity.

Every time you manually process a lead, manually send a reminder, manually update a row in a spreadsheet, you're not just spending time. You're spending attention. And attention is what you actually need for the decisions that can't be automated: what to build next, who to hire, whether this client is worth keeping.

The people who get this right don't just save time. They stop arriving at important decisions already depleted.

The compounding effect nobody shows you

An hour saved on Monday doesn't just give you a free hour. It gives you that hour with your brain still intact, rather than after you've processed sixty emails and three invoice disputes. The quality of that reclaimed hour is higher than anything you'd get from just working faster.

This is the compounding effect that automation blogs rarely talk about. The hours add up, yes. But the better thinking adds up too.

Why I Write About Failures Too

I once rewrote the entire backend for a studio site because I thought Firebase's costs were going to scale badly. Technically correct, maybe. Practically: it took two weekends, cost me client work, and the site never got enough traffic to hit the billing threshold I was worried about. I wrote about it, see Why I moved my studio site off Firebase, Utomat, because the decision-making process was instructive even when the outcome was overkill.

I write about the failures and the over-engineering because that's where the actual learning lives. Successes tell you what worked. Failures tell you how you think.

The MIT Media Lab tracks this loosely in how they frame iterative design, and the Harvard Business Review has made the case that the businesses most likely to improve are the ones that treat failures as data rather than embarrassment.

My version: I just try not to make the same mistake twice, and I write it down so I have to think it through properly.

Who This Blog Is For

If you run a business and you're doing things by hand that feel like they should be automatic, you're in the right place. Not because I'm going to hand you a plug-and-play solution (I'm not), but because I'm going to show you how I think about these problems, and hopefully that's useful.

I'm not writing for developers. I'm writing for people who want to understand the logic well enough to make good decisions about it, whether they build it themselves, hire someone, or use a no-code tool.

The About, Utomat page has more on the specifics of what I do. But the short version: I build automation-first products and I write about what I learn, including the parts that didn't go to plan.

Where to Start

If you're new here, the simplest thing is to read a few posts from the blog and see if the way I think about problems matches how you think about yours. If it does, stick around. If you're already in the middle of trying to automate something and you want a second opinion, reach out directly. I don't have a contact form, I have an email address, and I read everything that comes in.