The best AI tool for your team is probably one you already pay for and have never properly opened.
That’s not the answer most companies want to hear. It’s a lot more satisfying to picture a custom-built system, something engineered specifically for your workflow, with your logo on the login screen. But for almost every team asking “how do we get started with AI,” the honest answer is smaller and already sitting in their software budget.
The custom-build instinct, and why it backfires
When a company decides to take AI seriously, the instinct is usually to go big. Hire a developer, scope a custom system, connect it to a few internal databases, build something that looks like a real investment. It feels like the responsible, strategic move — the kind of decision a board slide can be built around.
The problem is sequencing. A custom build is the right answer to a question you can only ask after you already know exactly what you’re automating, how people actually do the task today, and whether the time it saves is worth the build. Most companies skip straight to the build before they’ve answered any of that.
I sat with a company last quarter that was six weeks into scoping a custom system for their client onboarding process. Real budget. Real developer hours. Nobody had actually tested whether the core idea — using AI to draft the onboarding packet from a client’s intake form — even worked. They were building the expensive version of an idea nobody had tried the cheap version of yet.
Test the idea before you fund the build
We paused the custom scope for a week and tested the same idea using a tool they already had a license for. One person built a simple AI assistant, fed it five real past onboarding packets as examples, and tried it on the next three new clients.
It wasn’t perfect. The first drafts needed real editing. But within a week, they knew three things the six-week custom scope hadn’t told them yet: the idea actually worked, the time saved was real and worth pursuing, and exactly which part of the draft needed a human’s editing every time.
That’s the information a custom build needs before it gets funded, not after. And it cost them a week with a tool they already owned, instead of a developer contract they hadn’t finished scoping.
Off-the-shelf isn’t the compromise. It’s the test.
There’s a quiet assumption that off-the-shelf tools are the beginner’s version, something you graduate out of once you’re serious. In practice, they’re closer to a prototype: fast to try, cheap to abandon if the idea doesn’t hold up, and genuinely useful if it does.
A custom build locks in assumptions early, because someone has to specify exactly what the system should do before a single line of code gets written. An off-the-shelf tool doesn’t ask you to know that yet. You can change your approach mid-week based on what you’re actually seeing, instead of waiting for the next development sprint to catch up with what you just learned.
For most teams, that flexibility is worth more in the first month than any amount of custom engineering.
The same test works everywhere, not just onboarding
A logistics company I worked with wanted a custom system to summarize daily driver reports for dispatch. Before writing a single requirement document, someone tried feeding a week’s worth of real reports into a tool they already had, just to see if the summaries were usable.
They were, with a bit of editing. That one week of testing told them more about what the eventual system needed to do than the original planning meeting had, and it cost nothing beyond an afternoon.
What actually earns a custom build
None of this means custom development is never the right call. It sometimes is — when a task needs to run thousands of times a day, pull live data from several systems automatically, or write results back into another platform without anyone touching it. Those are real reasons to build something custom.
But notice what they have in common: they’re all things you can only know for certain once you’ve already proven the underlying task is worth automating at all. A custom build is what you fund after the off-the-shelf version has already shown its hand — not instead of it.
A simple test before your next AI decision
Before approving any custom AI project, ask one question: has this exact idea been tried with a tool we already have, even in a rough, unpolished way?
If the answer is no, that’s the next step, not the development brief. A week spent testing the rough version will teach you more than a month spent specifying the polished one — and it will tell you, cheaply, whether the polished one is even worth building.
Most of the AI wins available to a team right now are sitting inside tools already paid for and barely used. The custom build isn’t the beginning of the AI journey. It’s what you earn once the cheap version has already proven itself.
Useful advice. Zero behavior change, until someone tests the rough version before funding the polished one.
Which AI idea on your team has been stuck in the “we should build something for this” conversation, without anyone trying it the cheap way first?
If that question sounds familiar, I’d welcome hearing your thoughts on it.
ADDITIONAL READING
• The Real Reason Most AI Projects Stall Before They Start — https://jordanimutan.com/2026/09/11/the-real-reason-most-ai-projects-stall-before-they-start/
• You Trained Your Team on AI. Their Output Didn’t Change. — https://jordanimutan.com/2026/09/15/you-trained-your-team-on-ai-their-output-didnt-change/
• Before You Roll Out That Leadership Program Company-Wide, Run This 90-Day Test First — https://jordanimutan.com/2026/09/10/before-you-roll-out-that-leadership-program-company-wide-run-this-90-day-test-first/
• AI Was Supposed to Save Your Managers Time. It Didn’t. — https://jordanimutan.com/2026/09/03/ai-was-supposed-to-save-your-managers-time-it-didnt/
• Your Company Isn’t Slow — Your Decisions Are Trapped in Manual Processes — https://jordanimutan.com/2025/12/19/your-company-isnt-slow/
