From AI Hype to Operations: a SMB guide to creating Business AI

The WRP Approach to Practical business AI

As small businesses and startups evaluate the role of artificial intelligence, AI can create apps that allow a small business to function better and faster. For Western Research Parks it became clear to better support our tenants, we needed to be more operationally efficient. I decided that we would develop a unified property intelligence system.

Technology must always serve the business outcome, not the other way around. Integrating AI cannot mean handing over the keys to an autonomous black box; it requires structured, secure, and intentional deployment.

I want to share some crucial lessons that I/we learned as we built and implemented the system:

You need a method that aligns what you want with what you will allow AI to build. I used a five step process (in the title infographic) based on traditional PRD into a to help me ensure that system that I (let's be real Claude) built would meet the outcomes. Your job as the prompt creator and user is to act as a Product Manager directing the AI developer to create the product that meets your requirements.

Here are the strategies you should internalize to act as the Product Manager ensuring that the AI developer meets the business outcomes you want:

Define Progress and What It Means to be "Done": AI development relies heavily on mini-experiments and hypothesis testing with unpredictable run times- this can be a good thing as the speed at which these experiments can be done is minutes and hours not days and weeks. As a PM, you must recognize ensure that "AI" is still progressing towards your business outcomes. Use a SDLC sprint plan to ensure that AI summarizes what worked and didn't work.
Question the value of "Ferrari functions": The ease of creating code, sometimes means that it is possible to create "ready to scale" functions that use latest, most complex techniques AKA "Ferraris"; similar to the car, these are highly complex solutions that are meant to be used at high speed under pristine conditions. If an AI model perfectly optimizes a process but cannot realistically be implemented due to real-world business constraints (like slow processing times or operational rules), the technical achievement holds no value.
Assess Readiness Early: A major cause of AI project failure is poor underlying data quality or a lack of data security. A crucial PM strategy is to conduct a preliminary assessment of data quality, technology infrastructure, and data security. These assessments HAVE to be incorporated into the projects early. AI can work incredibly fast to develop the fixes to the data quality or data security issues but ONLY as a requirement -never as a later project.

This is where prompt engineering and Agentic skills are highly valuable. As part of our maturing our Product and software development, I created a set of skills for our Gen AI coding that required created both a secure build framework that governed every products build and a separate Agent that is called after build to "Act as the App Sec review"; I used OWASP standards that the agent must build to and provide a report on for every product.

How can you use my experience:

For a people stepping into AI software development, the most important takeaway is that managing AI projects requires a completely different mindset than traditional or Agile software development. Although, in my opinion, it is really important that you understand the basics of product lifecycle and software lifecycle to be able to use those standard processes to govern your AI development projects. AI is an imperfect software developer and requires a persons that can ask the questions that matter to your business.

Ultimately, you have to be the one who understands the complete lifecycle of your product so you can make comfortable, secure decisions.

Lead with the Product Lifecycle (PDLC):

Before writing a single line of code, you must define the business problem. The Product Development Life Cycle (PDLC) guides a product from its initial idea by focusing heavily on business goals, market needs, and customer experience.

Define the Outcome: Start by asking what business outcome you need and how technology plays into that reality. Our applications are explicitly designed around core business logic rather than just technical features.

The Build vs. Buy Calculation: Evaluate if you can achieve the outcome cheaper by building it internally, or if buying an off-the-shelf product provides better security and value.

Solve the Actual Problem: We built our own CRM because generic options like Salesforce forced us to pay for heavy, enterprise-scale features we didn't need and would have required my team to change our processes. Building custom allowed us to focus solely on the precise problems we were trying to solve.

At our scale; one location, team under 10 FTEs a custom CRM makes sense- we can build the system that supports the team.

Streamline the Software Lifecycle (SDLC):

Once the what and why are established, the SDLC provides a structured approach specifically for creating and maintaining your software components. I use a standard prompt that includes our requirements for security and I provide exacting "problem to be solved". NOTE: 1 problem per prompt. Require build plan review it and ensure that it includes the "user requirements".

Minimize IT Overhead: Solutions shouldn't require a massive IT group to manage. If a system takes a massive team to maintain, the technical debt makes it far too expensive for a growing business.

This is why for us the customer CRM made sense. The existing CRMs all would have required complicated APIs, module customizations all of which would have required expensive on-going costs.

Prioritize Security: Our implementation demonstrates a mature SDLC focused on resilience, clear boundaries, and operational stability.

Strategic Partitioning: We deliberately separate authentication surfaces and utilize read-only database roles to ensure internal data is structurally isolated from public-facing interfaces.

Adopting the AI "as" Developer Life Cycle (AIDLC):

When you make the decision to integrate AI, you need a structured set of instructions and security norms. For example, we have a defined for Claude our standard requirements for security, cost control and our scale. This becomes an embedded check on any software or update of our systems.

Structured Integration: Managing AI projects introduces unique challenges requiring a process tied to business outcomes that guides AI involvement across inception, construction, and operations.

Match the LLM model for the security and cost: We leverage specific models for specific risk tiers. For example, we use Claude to build our software. However, due to our requirement for cost control and data sovereignty we use open models deployed on local servers to execute within our systems. Due to our scale this works.

Human-in-the-Loop Validation: We strictly enforce review steps for staff to correct and confirm AI outputs, refusing to let algorithms auto-commit unverified data. This is not about removing people from the work, it is about having humans do high value work while still collecting and managing large amounts of data required to effectively execute on strategy.

Modern AI implementation requires a distinct lifecycle that moves away from autonomous vibe coding toward spec-driven development, constrained delegation, and continuous evaluation.