The question worth answering
Not "should we use AI?" — everyone's past that. The question I get hired to answer is narrower and harder: what, specifically, is worth automating, and will it save more than it costs to build and run?
I build these systems for a living. I've shipped AI automation into production for small companies across a few stacks — customer support, document extraction, internal reporting, ticket routing — some in Laravel, some in Node, some in Python. Some of it paid for itself in the first month. Some of it I talked the client out of before we wrote a line. The difference was never the model or the framework. It was picking the right work and engineering it so it survives contact with real users.
Here's how I decide what to automate, four systems I've actually built (with the engineering that matters and the numbers that matter), what it really costs, and the failure mode almost nobody budgets for.
The band worth automating
The work worth automating sits in a narrow band: high-volume, repetitive, and judgment-light. Your team does it dozens of times a day, the steps rarely change, and a wrong answer is annoying but recoverable.
Good fit: "Where's my order?" replies. Extracting three fields from every invoice. First-pass ticket triage. Turning a call transcript into CRM fields. The standard follow-up email.
Bad fit: Anything rare — you'll spend more building than you'll ever save. Anything where a wrong answer costs money or trust: pricing, contracts, legal or medical calls, irreversible actions. Anything a person does because they're good at it, not because it's tedious.
Founders get this backwards constantly. They want to automate the impressive, judgment-heavy work — "an AI that handles our hardest customers." That's the expensive, risky end, and it's where AI is weakest. The return is in the boring middle: the hundred small, identical tasks that quietly eat a person's afternoon. As an engineer, I want the boring problems — they're the ones I can make reliable.
Four systems I've actually shipped
1. Support triage that looks things up instead of guessing
Most inbound support to a small e-commerce or SaaS team is the same handful of questions: order status, "how do I reset X," "do you support Y." A person reads each one, looks something up, and types a reply they've typed a hundred times.
The automation is not "a chatbot that talks to customers." It's narrower and far more useful: an assistant that reads the message, looks up the real answer in your own systems, and drafts a reply for a human to approve or send. It handles the repetitive 60-70%; the person spends their time on the 30% that needs a human.
The engineering that makes it safe: the model never invents an order number, because the number comes from a tool call into your database, scoped in code to the authenticated customer — not from the model's imagination. The model decides which tool it needs; your code decides what it's allowed to see. That authorization boundary is the whole game, and it lives in your code, never in the prompt. (I wrote up is: one week, fixed price, I look at your real workflows and tell you which two or three are worth automating, what each will cost to build and run, and which ones to leave alone. Sometimes the most valuable line in that report is "don't automate this one." Founders remember the engineer who told them that.
I'm Aditya Kumar (.
SOCIAL SHARE CARD GENERATOR