Blog / AI Strategy

The Hammer Doesn't Make You a Carpenter: AI Tools Need a Strategy

Designed graphic with the headline The Tool Isn't the Plan for a post on AI software strategy for small businesses

Hand me the nicest table saw at Home Depot and I'll still build you a wobbly bookshelf. The tool was never the hard part. That's where a lot of St. Louis owners are with AI, and it's why an AI software strategy for small business matters more than which app builder you pick. Lovable, Replit, Bolt, ChatGPT and Claude can turn a paragraph into a working-looking app before lunch. What they can't do is tell you what to build, how it should hold up, or who keeps it running. That's the part nobody demos.

AI handed everyone a power tool

I'm not knocking the tools. I've built with AI every day since ChatGPT launched in November 2022, and I use Lovable myself to rough out ideas. What used to take a developer a week now takes an afternoon. That's real.

But a demo and a business system are different animals. A demo needs to look right once, on your laptop, with ten fake records. A business system needs to be right every day, for every employee, with years of real customer data, while connected to your CRM, your accounting software and your inbox.

The AI is happy to build the demo. It doesn't know it's supposed to build the system.

What the demo hides

Here's what tends to show up a few weeks after the exciting afternoon.

Who can see what

AI builders lean toward "everyone can see everything" because that's the fastest way to make something work on screen. In a real business, your office manager shouldn't see payroll, a sales rep shouldn't edit invoices, and a client portal should never show one client another client's data. Permissions have to be designed on purpose, from how your business actually runs.

Security you didn't ask for

When Veracode tested code from more than 100 AI models across 80 coding tasks, it found that >AI-generated code introduced security vulnerabilities in 45% of cases. That doesn't mean AI code is bad. It means somebody has to read it. If nobody on your side can, that's the gap.

Data that doesn't hold its shape

A quick build often stores everything in one big table. Fine for a demo. Then you add a second location or a second service line, and suddenly the same customer exists three times with three different phone numbers. Structuring data well is boring work that the AI skips unless you know to ask for it.

Connections that break quietly

Your new app has to talk to the tools you already pay for. Those connections fail in ways nobody sees: an expired login, a changed field name, a vendor update. If nothing is watching, leads just stop arriving and nobody notices for a week.

The person who keeps it running

Every tool needs an owner. Who fixes it when it breaks? Who updates it when your process changes? If the answer is "the owner, at 11 p.m.," that's not a system. That's a second job.

The 5-question strategy check

Before you build anything with AI, or before you let your team depend on something you already built, answer these five questions on paper.

  1. What bottleneck does this fix? Name the task, who does it, and roughly how often. If you can't name it, you're building a toy.
  2. Can the tools I already pay for handle it if they're connected? Often the answer is yes, and that's faster and cheaper than a new app.
  3. What data does it touch, and who should see it? List the roles. Write down what each one can view and change.
  4. What happens when it breaks? Who gets alerted, and what's the manual fallback for a day?
  5. Who owns and maintains it? The accounts, the code, the documentation. It should be you, not a vendor or a freelancer's personal login.

If you can answer all five, you have the start of a strategy. If you can't, the tool isn't the problem yet.

How I'd approach this

I start with process, not software. Most small businesses have good people and a product that works. What's broken is the stuff in between: handoffs, follow-up, reporting, the copy and paste. So the first thing I do is find the single biggest bottleneck and see whether the tools you already have can fix it once they're connected.

When something does need building, AI writes plenty of the code, but I decide the structure, review what it writes, and set up permissions and error alerts before anyone relies on it. Lovable is for prototypes. The real version usually runs as n8n workflows with data in Supabase, using Claude, ChatGPT or Gemini where AI actually saves time. It all lives in your accounts. You can see the kind of work this covers on what I automate, and the step-by-step on how I work.

If you've already built something yourself, good. I mean that. I tell every client to try building their own AI tools, because you learn what you actually need. Your prototype just becomes the spec.

Frequently asked questions

What is an AI software strategy for a small business?

It's a short list of decisions made before anyone opens an app builder: which bottleneck you're solving, whether your current tools can handle it once they're connected, where AI genuinely saves time, who maintains what gets built, and who owns it. The tools come after those answers. Without them, you end up with clever apps that don't fit together.

Is it safe to run my business on an app I built with an AI app builder?

It can be, but don't assume it. AI builders optimize for something that works on screen, not for who can see which records or what happens when an integration fails. Before your team depends on it, have someone check permissions, where the data lives, backups, and error handling. Treat the first version as a prototype until that review is done.

What is vibe coding and why is it risky?

Vibe coding means describing what you want to an AI and accepting whatever code comes back without really reading it. It's great for exploring ideas quickly. The risk is that nobody understands what was built, so security gaps, messy data and fragile integrations stay hidden until something breaks. Independent testing has found security flaws in a large share of AI-generated code.

Should I stop experimenting with AI tools myself?

No. Keep experimenting. Building a rough version yourself is the fastest way to learn what you actually need, and it makes any later conversation with a builder much shorter. The line I'd draw is simple: prototypes are for learning, and anything that holds customer data or money gets reviewed and rebuilt properly before it goes live.

More answers live on my FAQ page.

Bring me the prototype, or just the problem

Whether you've got an AI-built app held together with tape or just a bottleneck you're tired of, the conversation starts in the same place. Book a 30-minute call. I'll look with you at the one problem costing your team the most time and whether the fix is a connection, a build, or neither. No pitch.

What's the one task your team groans about?

Thirty minutes, no pitch. We'll find your biggest bottleneck and talk through how to take it off your plate.