Here's something most consultants won't tell you: before you pay anyone, try to build your own AI tools. Pick the task that annoys you most, open an AI app builder on a Saturday, and see how far you get. I say some version of this to almost every owner I talk to, and people are usually surprised. They expected a pitch. What they get is homework.
I'm not being cute about it. I've been building with AI every day since ChatGPT came out in November 2022, and I can tell you the fastest way for a business owner to understand what AI can and can't do is to get their hands dirty for a few hours.
What happens the first time you build an AI tool
The first hour feels like magic. You type "make me a simple app that tracks quote requests and reminds me to follow up," and a clean screen appears. Buttons, a table, a little form. You show your spouse. You show your office manager.
Hour two, you start using it like a real person would. You type a phone number with dashes and it chokes. You realize it doesn't know about the 40 open quotes already sitting in your CRM. You wonder where the data actually lives and whether anyone else can see it.
Hour three is the useful part. You've stopped asking "can AI do this?" and started asking "how would this work on a busy Tuesday?" That's the question that matters, and you got there on your own.
Why I'd rather you try it than take my word for it
I'm a process guy. Most small businesses I meet have good people and a product that works. What breaks is the process in between: the follow-ups, the handoffs, the copying from one screen to another. Owners who have tried building something see that faster than any slide could show them.
It also changes the conversation. An owner who has spent a weekend with these tools doesn't need a demo to be impressed. They come in with sharper questions, a clearer idea of what they want, and a healthy skepticism about anything that looks too easy. That makes my job easier and the work cheaper, because nobody spends hours on features you'd have cut after five minutes of real use.
And honestly, I don't sell mystery. If a tool is easy enough for you to use, you should know that. You're paying me for judgment and for building things that hold up, not for hiding the hammer.
A weekend plan to build your own AI tool
If you want to try this, here's the plan I'd give you. Budget a few hours.
- Pick one annoying task. Not "run my business." Something small and repetitive: turning voicemails into follow-up notes, drafting quote emails, logging new leads.
- Write the steps on paper first. Who starts it, what information comes in, what should come out, who needs to see it. If you can't write the steps, AI can't follow them either.
- Start in a chat tool. Paste your steps into Claude or ChatGPT and ask it to do the task once with a sample. You'll learn a lot about what the AI gets right before you build anything.
- Then try an app builder. Lovable is a good one for a quick prototype. Describe the app in plain English and let it generate a first version.
- Use fake data only. Made-up customers, sample invoices. Don't load real client records into a prototype.
- Keep a "where it broke" list. Every time it fails, confuses you, or needs something it doesn't have, write it down. That list is gold.
Where a prototype stops and a real tool starts
A prototype proves an idea looks right. A tool your team relies on has to survive real life. Before you roll anything out, run it through this checklist:
- Data: Where is it stored, who can see it, and what happens if the service goes away?
- Connections: Does it talk to your CRM, accounting, email and calendar, or does someone have to copy data in by hand?
- Bad input: What happens when someone types a name wrong, skips a field, or submits twice?
- Ownership: Who fixes it when it breaks on a Friday afternoon? Who owns the code and the accounts?
- Adoption: Will your team actually use it, or is it one more screen to ignore?
If you can answer all five, you might not need me for this one. That's a fine outcome. If you can't, you've found exactly where outside help earns its keep. I wrote more about that line in the hammer doesn't make you a carpenter.
How I'd approach this
When an owner brings me a prototype, I don't start by rebuilding it. I start by looking at the bottleneck it was trying to solve. Half the time the weekend project reveals that the real fix isn't a new app at all. It's getting the tools you already pay for to share data and hand off work automatically.
So I work with what you have first. I connect your existing software, usually with n8n workflows, and add AI (Claude, ChatGPT or Gemini, depending on the job) where it actually saves time. If something truly doesn't fit, I build it properly, with Supabase handling the data, and you own everything. Lovable stays where it belongs, in the prototype stage. You can see the full process on my how I work page, and the kinds of work I automate for St. Louis small businesses.
If you want the other side of this argument, read why adding AI buttons to old software isn't a strategy.
Frequently asked questions
Can a small business owner really build their own AI tools?
For a first version, yes. Chat tools like Claude or ChatGPT and app builders like Lovable can turn a plain-English description into a working screen fast. That's perfect for testing an idea. What takes more work is making it secure, connecting it to your other software, and keeping it running when your team depends on it every day.
Is it safe to put my business data into an AI app builder?
Not while you're experimenting. Use made-up customers, fake invoices and sample jobs until you know where the data is stored and who can see it. A prototype doesn't need real records to prove the idea. Once something is worth keeping, that's the moment to sort out storage, access and permissions properly.
Why would an AI consultant tell clients to build it themselves?
Because owners who have tried it make better decisions. They know what's easy, what's hard, and what they actually need. First conversations get sharper, and nobody pays for features that would have been cut anyway. I'd rather earn work by being open about the tools than by keeping them mysterious.
What should I do with a prototype once I've built it?
Write down what it does, where it broke, and who would use it. Then decide whether the problem is really a new app or just a gap between tools you already own. Often it's the second, and connecting existing software is cheaper and sturdier. Bring the prototype to a conversation either way.
Bring your prototype (or don't)
Go build something this weekend. Break it. Keep your list. Then, when you'd rather run your business than debug an app, let's talk for 30 minutes about the one bottleneck slowing your team down most. Bring the prototype, the "where it broke" list, or nothing at all. No pitch, and meetings are always free under my pricing. Book a time here.
