AI is making it easier than ever to build software that looks finished. For contractors and home service business owners, that creates a new problem: How do you know whether an AI platform, dashboard, or application is actually built to run a business? In this episode of Catalyst for the Trades, host Jazmin Ramirez sits down with Jennifer Bagley, CEO of CI Web Group, and Chris Heney, CTO of CI Web Group, to break down AI vaporware, AI-generated software, database architecture, WET vs. DRY code, and the risks contractors should understand before trusting an AI tool with real business data. Chris compares today's AI-built software to putting beautiful wallpaper on a house before making sure the foundation and framing are sound. A dashboard can look polished while relying on seed data, duplicated logic, weak architecture, or inaccurate reporting. Jennifer shares one example where a contractor was running the business from a polished dashboard only to discover that roughly 90% of what appeared on the front end was seed data rather than the operational data they thought they were viewing. What AI vaporware means for contractors AI is incredibly useful for prototyping. A business owner can quickly turn an idea into something visual that helps developers and stakeholders understand the concept. The danger starts when a prototype is treated like a production-ready application. A real business application may require database and server architecture, role-based access control (RBAC), state machines, data models, business rules, CI/CD processes, testing, security, and clear separation between business logic and visual components. If those foundations were never planned, a beautiful dashboard may still be just a prototype. WET code vs. DRY code One of the biggest risks Chris sees in AI-generated development is WET code, or "Write Everything Twice." Traditional development generally aims for DRY code: Don't Repeat Yourself. Instead of recreating the same logic each time, developers build reusable components and maintain a single source of truth. AI can move in the opposite direction. As prompts pile up and terminology changes, an AI coding tool may create separate logic, fields, tables, or components for things that should be connected. Chris describes finding multiple versions of components that should have been shared. Jennifer shares another example involving 15 databases tied to inbound leads and roughly 100 variations of lead-source information, leaving the company with numbers that didn't match its other systems. The interface looked convincing. The architecture underneath it was not. Questions to ask about an AI application If you're building an AI-powered dashboard or internal tool, don't judge it only by how polished it looks. Start asking: Are we building WET code or DRY code?Does this application have a state machine?What role-based access controls, or RBAC, are in place?Is the business logic separated from the design components?How many lint errors exist in the code?These questions don't replace an engineering review, but they can help reveal whether you're looking at a prototype or software that is ready to become business-critical. How contractors can evaluate an AI vendor The same scrutiny applies when buying software. Before trusting an AI vendor with customer data, lead information, reporting, or operational systems, look beyond the website and demo. Jennifer recommends checking the company's team. Do they have experienced full-stack developers, engineers, database architects, or other technical professionals actually building the product? Chris also challenges contractors to look at mature software products and the teams behind them. AI can accelerate development, but it doesn't eliminate software engineering. Why AI development still needs guardrails Chris explains how development teams use gates throughout the software process to catch problems before code moves forward. That can include linting, CI/CD workflows, automated scripts, testing, and other quality controls. As AI increases the speed at which code can be produced, those controls matter even more. The same is true of product ownership. A strong product needs people who understand the business problem and people who understand the technical architecture required to solve it reliably. The bigger issue: AI makes prototypes feel finished AI has made it possible for non-developers to create polished software experiences incredibly quickly. That's powerful, but generating an interface is not the same as knowing whether the system behind it is reliable, secure, maintainable, or accurate enough to run a business. For contractors experimenting with AI, the message isn't to stop building. Keep building. Just know what you've built. A prototype can help clarify an idea and define what should come next. The mistake is assuming the prototype is already the product. Questions Answered in This Episode What is AI vaporware?Why can an AI dashboard look finished when the underlying software isn't?What is the difference between WET code and DRY code?Why does AI-generated code create multiple sources of truth?What are RBAC rules and state machines?What should contractors ask before trusting an AI dashboard?How can contractors vet an AI software vendor?Do AI-built applications still need experienced engineers?What are CI/CD and software-development gates?How should business owners use AI prototypes without confusing them with production software?About the Guests Chris Heney, CTO, CI Web Group Chris breaks down database architecture, software design patterns, state machines, role-based access control, WET and DRY code, CI/CD, and the engineering required to move from an AI-generated prototype to reliable software. Jennifer Bagley, CEO, CI Web Group Jennifer brings the product and business perspective, explaining how quickly AI can turn an idea into an impressive prototype, why owners need to understand the difference between prototype and product, and what contractors should investigate before trusting AI-generated systems. Chapters 0:00 — Meet Jennifer Bagley and Chris Heney 1:10 — How much AI software being sold to contractors is oversold? 2:30 — What is AI vaporware? 4:05 — The wallpaper analogy: polished UI vs. real architecture 6:54 — Prototype vs. production-ready software 8:37 — Databases, RBAC, caching and state machines 9:28 — Software design patterns and the saga pattern 11:26 — The dashboard running on roughly 90% seed data 15:10 — WET vs. DRY code explained 17:29 — How duplicated code destroys the single source of truth 19:22 — 15 databases and 100 lead-source variations 22:31 — Where bad AI-generated data structures come from 24:19 — How to vet an AI vendor before you buy 25:18 — The App Store challenge for AI-built software 25:54 — Questions to ask your AI about what you're building 27:47 — Development gates, linting and CI/CD 31:37 — Can someone learn AI and become a software developer? 33:27 — Why AI makes non-developers feel like developers 34:04 — Who owns product viability? 36:18 — Why product vision and technical architecture need each other 38:07 — How to test what you've built 39:27 — Reviewing an application's GitHub repository 40:19 — Wolverine, CI Web Group's code-review agent 40:55 — Why bad architecture can become a ticking time bomb 41:49 — Building an AI software audit checklist 42:36 — When polished AI software hides serious problems 44:16 — Should there be a Part Two? Enjoyed this episode? Subscribe to "The Catalyst for Trades" on Apple Podcasts, Spotify, or your preferred platform. Share this episode with aspiring and established leaders, and stay tuned for more insights on driving business success and personal leadership growth.
