You have an idea for a tool your business needs. A customer portal. An internal dashboard. A simple app that replaces the spreadsheet everybody hates.
A few years ago you had two choices: learn to code or pay someone to build it. Now there’s a third. Describe it in plain language and let AI build it.
That part is real. I do it. But most people who try to build an app with AI stall in the same three places — and they don’t find out until something breaks.
Here’s how I actually build, where it goes wrong, and when I stop and call a developer.
How I build apps with AI
Two tools carry most of my build work, as of October 2026.
Lovable is an AI app builder. I build the REI Boss front end in it, plus other sites. I describe screens and behavior in plain language, it generates the app, and I review and refine.
Claude Code is Anthropic’s agentic coding tool. My AI chief of staff, an orchestrator agent, runs on it headless on a Mac mini. It works through multi-step tasks on its own and handles a big share of my day-to-day operations.
And this content network you’re reading? It was planned and drafted with AI under my direction.
I’m not telling you to use these specific tools. I’m telling you the workflow, because the workflow works across tools.
The build loop: spec, prompt, review, iterate
Most people open an AI app builder and type “build me a CRM.” That’s how you get a demo, not a tool.
Here’s the order.
1. Write the spec before you touch the tool
A spec is a plain-language description of what the app does. Write it like you’re briefing a contractor.
- Who uses it and what they’re trying to get done.
- The screens, one line each: what’s on it and what the person can do there.
- The data: what gets stored, what each record contains, what connects to what.
- Who can see and change what. Owner, staff, customer, nobody.
- What “done” looks like for version one. Keep it small.
This is the step everyone skips. It’s also the step that decides whether the project works. If you’ve written SOPs for your business, you already have the skill. My guide on writing SOPs for AI uses the same muscle.
2. Prompt one piece at a time
Don’t paste the whole spec and hope. Build in slices: the layout first, then one screen, then the data for that screen, then the next screen.
A prompt I’d use for a single slice:
Build the [SCREEN NAME] screen for [APP PURPOSE]. Users are [WHO]. On this screen they can [ACTIONS]. Each [RECORD TYPE] has these fields: [FIELDS]. Only [ROLE] can edit; everyone else can view. Keep the design consistent with the existing screens. Do not change any other screen.
That last line saves hours. AI builders love to “helpfully” rearrange things you didn’t ask about.
3. Review like a skeptic
Click every button. Enter bad data on purpose. Log in as different kinds of users if the app has logins. Ask the AI to explain in plain English what it just changed and why.
You don’t need to read every line of code. You do need to understand what the app does with data.
4. Iterate in small, specific corrections
“It’s wrong” teaches nothing. “When I save a record with no phone number, the page goes blank — show an error message instead and keep the form filled” fixes it.
Keep a running log of what you asked for and what changed. When something breaks later, that log is how you find out why.
Where non-coders get stuck building apps with AI
This is the honest part. AI app builders make the visible parts easy. The invisible parts are where things go wrong.
Data
The screens look right, but the data underneath is a mess. Records duplicate. Fields mean different things in different places. Nothing connects the way it should. Fix it at the spec stage: decide what each record is and how they relate before you build screens on top of them.
Security
An app that works is not the same as an app that’s safe. AI-generated apps can expose data to people who shouldn’t see it, store sensitive information carelessly, or leave keys and passwords where they don’t belong. If customer, financial or personal data touches the app, a qualified person needs to review it.
Authentication and permissions
Logins and “who can see what” are the hardest part to get right and the easiest part to get wrong without noticing. Everything looks fine when you test as the owner. Then a customer logs in and sees another customer’s records. Test as every role, every time.
Connections to other systems
Connecting your app to your CRM, your email or your payment tools adds failure points. Agents and integrations need only the access they require — least privilege, always. I cover how that works for agents in how to build an AI agent.
When to bring in a developer
AI changed when you need a developer, not whether. I build first and bring one in at these points:
- The app will hold customer, payment or personal data.
- It needs login, roles and permission rules that matter.
- It connects to other systems that run the business.
- It’s starting to carry real weight — people depend on it daily.
- Something keeps breaking and you can’t explain why.
Working this way changes the conversation with a developer. You show up with a working prototype and a written spec, not a napkin sketch. They review, harden and fix. That’s a better use of everyone’s time.
Is building with AI right for you?
It fits if you can describe your process clearly, you’re willing to test carefully, and the first version is internal or low-risk.
Slow down if you need it to handle sensitive data on day one, nobody on your team will own testing it, or you’re hoping AI removes the need to think through how the app should work. It doesn’t. It removes the typing.
If you’d rather someone build the agents and automations around your operations for you, that’s what my AI company, ClientPro, does. For the wider tool landscape, see the best AI tools for business and the AI tools FAQ. And if you want to understand the agent side of my setup, start with AI agents explained.
Your next step
Write a one-page spec for the smallest useful version of the app you want. Who uses it, the screens, the data, who can see what, and what done looks like. Don’t open any tool until that page exists.
I build in public on YouTube — the prompts, the reviews and the things that broke. If you’re a business owner who wants this kind of work running inside your company, see how Chief works.
Questions people ask
Can I really build an app with AI without knowing how to code?
You can build a working front end, an internal tool or a simple app by describing it in plain language. Where non-coders get stuck is data structure, security, logins and permissions. Build the first version yourself, then get a developer to review anything that holds real customer data.
What is vibe coding?
Vibe coding is the casual name for building software by describing what you want to an AI and accepting what it produces, often without reading the code. It’s great for prototypes. For anything real, replace the vibes with a written spec and a review step.
When should I hire a developer instead of building with AI?
Bring one in when the app stores customer or payment data, when you need login and permission rules, when it connects to other systems, or when it’s starting to matter to your revenue. AI gets you to a working version faster. A developer makes sure it’s safe to rely on.