Skip to main content
Back to Learning Hub
Founder Notes

The Expensive Part of Automation Isn't the API Bill

People keep asking me whether AI automation is finally cheap enough to use everywhere.

My answer is yes on the API side and no on the workflow side.

The actual API bill is rarely what hurts. What hurts is building a system that looks automatic in a demo but still needs a human hovering over it every morning because one small step keeps drifting off course.

I've run into this with content systems, client handoffs and internal admin work. The first version usually feels exciting because it cuts an hour of work down to ten minutes. Then week two shows you the real problem. The system didn't remove the task. It changed the task into supervision.

Now instead of doing the work directly, you're checking whether the automation picked the right input, used the right account, wrote to the right file and left the output in a state you can actually ship.

That's the hidden cost most people miss.

Cheap actions are not the same as cheap systems

One model call is cheap. One scheduled job is cheap. One webhook is cheap.

But the second you connect five or six cheap steps together, you now own the behavior between them. That's where the time goes.

If a post gets generated but not committed, it isn't published. If a cron route runs but only marks something as ready, it isn't posted. If a script depends on a local file and your deploy environment doesn't have it, the whole chain breaks even though every individual part looked fine on its own.

That is why I don't get impressed by a workflow diagram anymore. I want to know what happens on the bad day. What happens when the provider is overloaded. What happens when the repo is dirty. What happens when a token expires on the one account that matters.

If the answer is "we'll just check it manually," then the manual check is part of the product. It belongs in the cost.

What I look for now

When I build automation, I care less about how many steps got removed and more about whether the system can finish cleanly without me thinking about it.

That means fewer moving parts, clearer state changes and a boring fallback when something fails. Not a clever fallback. A boring one.

Sometimes the right move is to keep one manual step on purpose. A human final check at the end is cheaper than pretending the whole thing is hands-off when it isn't.

I've started treating automation the same way I treat hiring. If a process still needs daily management, I don't call it solved. I call it staffed.

That's not a reason to avoid automation. It's a reason to price it honestly.

The teams getting real value out of AI right now are not the ones with the flashiest demos. They're the ones reducing supervision, not just reducing clicks.

That's the bar I care about now. Not "can this run?" but "can this keep running without becoming another thing I have to manage?"

Share this post

Need something like this built?

See what Jaiye Labs builds

Get practical insights, no spam

Short reads on product building, engineering decisions and what I'm learning along the way.

See what your project costs

Answer a few questions, get a ballpark estimate in under a minute.