Why AI Adoption Fails for SMB

Prompt-to-product application development has exploded into the mainstream. What was once a largely inscrutable and disciplined engineering practice has been so automated that anyone with an internet connection, fingers, and a decent laptop can build enterprise-grade applications with a few words describing their intent. Or so it seems.

What used to take weeks — months even — of scoping, requirements gathering, interviews, and technical planning can be executed by the likes of Base44 and Loveable in five minutes. But that's not really true. In fact, it's not at all true. And SMBs should be aware of the risks — not just in security, which I've talked about at length, but also in terms of business impact and overall functionality.

AI has indeed proven to be a formidable accelerator for application development. But who the operator of that AI system is makes a big — read: monumental — difference in its output.

The Wrapper Disguised as a Solution

Some months back, I was contacted by a good family friend. Someone who isn't particularly technical had hired a firm to build an "advanced AI system" to help his customers find certain products from his business in a chat session. He asked me to review what the firm had produced and give my thoughts. Upon navigating to the URL, I was presented with a chat interface I know all too well. It was built using a library of React components available as templates to anyone.

When I asked the AI to give me recommendations about a particular product, it immediately started to show me what at first appeared to be very credible recommendations, based on consumer reviews, with rich descriptions of the product. But when I clicked the link to take me to the product page, it was something completely different from how the AI was framing the recommendation. The AI was hallucinating everything it recommended. My family friend had been burned. Badly.

I told him what was happening. How the AI was merely operating off system prompts, not ingesting data as he desired. He was floored. He then sent me a document purporting itself to be a technical overview of how the solution was built by this unnamed firm. What I read is still to this day one of the most absurdly written technical descriptions I have ever seen.

The specification called for subsystems that would each require teams of skilled ML engineers to build: custom embeddings, LoRA adapters, and other technical elements worthy of a doctoral dissertation at MIT. The infrastructure costs to run such a system would be prohibitive for even the most well-capitalized of small businesses. And after examining the document carefully, it was clear it had been written entirely by an AI tool.

What was really delivered is something we see all too often: an LLM wrapper disguised as something else. By LLM wrapper, I mean a solution that appears customized and purpose-built, that seems to think and act like an AI — but in reality serves little more than a dressed-up portal to ChatGPT or Claude. This architecture, simply sending raw data to commercial endpoints, has become a staple of the AI hype train.

It can feel like an impressive interface at first. The patina fades quickly. What you're left with provides no more value than copying and pasting queries into ChatGPT yourself.

Why It Keeps Happening

Two things cause this. Businesses without clearly defined outcome targets — ideally measured as key performance indicators — and AI firms that do not prioritize, or in some cases do not understand, outcome-based solutioning.

Really? That's akin to suggesting electricity will be transformative. How, exactly?

What to Demand Before You Sign Anything

Before any implementation, you should see a clear and demonstrable mapping of how the proposed solution will achieve the business outcomes you have already defined. Ask to see it demonstrated, not described.

• 1
  Be quantitative."We really need to automate things that take time" is not a measurable outcome. "We want to see a 30% reduction in labor hours to onboard new clients" is. If your AI partner cannot help you get to that level of specificity, look elsewhere.
• 2
  Be wary of technical jargon intended to impress you.You should receive a clear Statement of Work describing the proposed solution in plain terms. Put it through Claude or GPT and ask whether what has been described is realistic, proportionate, and coherent. You may be surprised by what comes back.
• 3
  Understand what is actually being built.Where will it live, and how will it be supported? Are existing tools being reconfigured? Is new code being deployed that requires a runtime environment? Who maintains it when something breaks?
• 4
  Ask specifically what data is being sent to the AI provider.Whether any additional data processing is occurring — if the answer is no, that is a significant red flag — and whether new databases or models are being built on your behalf.
• 5
  Critically, understand the security implications.Has the solution been vetted by a security engineer, and what are their credentials? Is personally identifiable information being sent to the LLM without proper masking? What tests will be performed to ensure the solution meets security best practices, and will you be shown the results?

The Bar Is Not Advanced. The Bar Is Correct.

The firms getting real value from AI are not necessarily running the most sophisticated systems. They are running systems built by people who understood the business problem before they wrote a line of code. There is a meaningful difference between a team that knows how to demo an LLM and a team that knows how to build something that works in production, against real data, under real constraints, for a real business outcome.

That difference does not show up in a proposal. It shows up six months after you sign one.