Your AI Dashboard Is Wallpaper: AI Vaporware, WET Code & What Contractors Are Actually Buying
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 contractorsAI 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 codeOne 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 applicationIf 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 vendorThe 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 guardrailsChris 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 finishedAI 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 EpisodeWhat 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 GuestsChris Heney, CTO, CI Web GroupChris 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 GroupJennifer 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.Chapters0:00 — Meet Jennifer Bagley and Chris Heney1: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 architecture6:54 — Prototype vs. production-ready software8:37 — Databases, RBAC, caching and state machines9:28 — Software design patterns and the saga pattern11:26 — The dashboard running on roughly 90% seed data15:10 — WET vs. DRY code explained17:29 — How duplicated code destroys the single source of truth19:22 — 15 databases and 100 lead-source variations22:31 — Where bad AI-generated data structures come from24:19 — How to vet an AI vendor before you buy25:18 — The App Store challenge for AI-built software25:54 — Questions to ask your AI about what you're building27:47 — Development gates, linting and CI/CD31:37 — Can someone learn AI and become a software developer?33:27 — Why AI makes non-developers feel like developers34:04 — Who owns product viability?36:18 — Why product vision and technical architecture need each other38:07 — How to test what you've built39:27 — Reviewing an application's GitHub repository40:19 — Wolverine, CI Web Group's code-review agent40:55 — Why bad architecture can become a ticking time bomb41:49 — Building an AI software audit checklist42:36 — When polished AI software hides serious problems44: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.