InsightsAI
When not to use AI
AI is useful when it makes a workflow better. It is a distraction when the real problem is coordination, structure, or honesty about limits.
2 min read
AI is another building block for software. It is not a product strategy.
The interesting question is not whether a model can be added. It is whether it makes a specific workflow better — and whether the software is honest about what it cannot do.
I have seen both sides of that in my own work.
Use it where the job is language, not authority
Mediscan AI is a product concept for a real problem: medical reports are often written in language that is hard for a non-specialist to follow. Restating that text in simpler language is a job language models can help with.
It is also a job that is easy to overclaim.
The concept is not a diagnostic tool. It does not provide medical advice. The useful version of the product would help someone understand what they are reading. The harmful version would imply that the software knows more than it does.
That boundary is the product. If AI is in the idea, I still start with the actual problem: where it adds value, what data is involved, where accuracy has limits, and where a person should stay in the loop.
Skip it when the work is already a process problem
A WhatsApp lead-capture workflow I worked on did not need a model. Leads were arriving in chat and getting lost in threads. The job was to capture those conversations and put them into a repeatable workflow.
Putting AI in the middle of that would have made the story sound more current. It would not have fixed the missed lead.
A lot of “we should add AI” requests are actually:
- work trapped in spreadsheets and chat
- tools that do not talk to each other
- a process nobody has written down
- a first version that is still trying to do too many things
Those are software and product problems. Models do not make them smaller.
A practical test
Before I add AI to a product, I ask:
- What does a person do today with this information?
- Would a clearer structure, a better workflow, or a simpler interface already solve most of it?
- If a model is involved, what happens when it is wrong?
- Can the product still be useful if we describe its limits in plain language?
If the honest answer to (2) is yes, I do not start with AI. If the answer to (4) is no, the feature is not ready to ship — no matter how impressive the demo looks.
I wrote more about this stance on the About page. If you are trying to decide whether AI belongs in a product, or whether the real work is elsewhere, tell me what you are building.
Related articles
Lessons Learned
Building software around how work already happens
Custom software is most useful when it follows the real workflow — not when it asks a business to become a generic template.
September 12, 20262 min read
Read articleProduct
How I approach building a SaaS MVP
The first version of a product should answer a real workflow problem — not prove that a stack can be assembled.
September 8, 20263 min read
Read article
Building something similar?
Tell me what you're trying to build, or where the current process is getting in the way.
Start a Project