Your app should use AI when a task involves understanding unstructured input such as text, images or speech, when the rules are too many or too fuzzy to write down, or when personalisation from behaviour is the value. It should not use AI when the rules are known and finite, when a wrong answer is unacceptable and unreviewable, when you have no data, or when the only reason is that investors expect it. Most first releases need at most one AI feature, placed where it removes real work.
Every founder is now asked whether their product uses AI, and many add a feature to be able to say yes. Some of those features are transformative. Many are demos that cost money to run and add nothing users pay for. This guide gives you the questions that tell the difference before you build.
Five questions
| Question | AI is likely right if | AI is likely wrong if |
|---|---|---|
| 1. Is the input unstructured? | Free text, documents, images, audio, conversation | Forms, numbers, choices from a list |
| 2. Can the rules be written down? | There are hundreds of rules, exceptions, or nobody can articulate them | A person can list them on a page |
| 3. What happens when it is wrong? | A person reviews, or a wrong answer is a minor inconvenience | A wrong answer costs money, safety or trust, and nobody checks |
| 4. Do you have the data? | Examples of inputs and good outputs exist, or a general model already handles the task | Nothing to learn from and the task is specific to you |
| 5. Does it remove real work? | Users or staff spend hours on this task today | It is a novelty nobody asked for |
Where AI earns its place
- Reading things. Extracting fields from invoices, receipts, contracts and forms. Classifying support tickets, reviews and messages. Summarising long documents.
- Understanding people. Search that understands what a user meant rather than what they typed. Support that answers the common questions and hands the rest to a person.
- Seeing things. Identifying products, defects, documents or scenes in photos.
- Predicting from patterns. Demand forecasting, churn risk, maintenance needs, fraud signals, when there is history to learn from.
- Generating first drafts. Product descriptions, replies, reports, code, that a person then edits.
- Personalising. Recommendations and ranking based on what users actually do.
Where a rules engine is the honest answer
Pricing with known tiers. Eligibility with defined criteria. Scheduling with explicit constraints. Approval flows. Validation. Anything a competent person could specify in a document. Rules are cheaper to build, free to run, predictable, explainable to a regulator, and do not need data. A large share of the "AI features" founders describe to us are rules engines with a marketing problem, and we say so. Our post on AI Business Empowerment explains the same principle from the business side.
The three traps
- AI because investors expect it. Investors fund traction. A rules-based product with retention beats an AI product without it. If AI belongs in the road map, say where and why. If not, say that.
- AI as the product. "An AI that does X" is a feature, not a business, unless X is the entire job and you can do it better than a general tool. Ask what the user's whole workflow is and where AI fits inside it.
- AI without a human in the loop. Models are wrong some of the time. Where being wrong costs something, design the review step first and the AI second. Products that skip this discover it in production.
How to decide for a first release
- List the tasks users or staff spend the most time on.
- For each, answer the five questions.
- Pick the one where AI scores well on all five and the value is measurable in hours saved or revenue.
- Prototype it with a hosted model in a week and measure the accuracy on real examples.
- Build it into the product only if the accuracy is good enough with a review step you can afford.
One feature, measured. Not a strategy. Our guide to AI features that actually work lists the ones that reliably pass this test, and what adding AI costs puts numbers on it.
Choose AI if
- The input is unstructured and the rules cannot be written down.
- A wrong answer is reviewable or cheap.
- You have examples, or a general model already handles it.
- It removes hours of real work.
Choose rules if
- The rules fit on a page.
- Wrong answers are expensive and unreviewed.
- You have no data.
- The only reason is the pitch deck.
We build both, and the decision in discovery is made from the five questions, not from the fashion. If you are unsure which side your feature falls on, describe the task and we will tell you.
Frequently asked questions
Will my app look outdated without AI?
Users judge whether the product solves their problem, not what technology does it. Many of the most used products have no visible AI. Add it where it removes real work, and say so where it does not.
Can I add AI later if I start with rules?
Yes, and it is often the right order. Rules handle the known cases and generate the data that a model later learns from. Design the product so the decision point can be swapped.
Is AI expensive to run?
It depends on volume and the model. Hosted models are billed per use, so cost scales with users. For most early products it is a modest line item. For high-volume products it needs to be designed for from the start.
What about using AI to build the app rather than inside it?
A different question. AI coding tools speed up development considerably. Whether the product itself should use AI is the question this guide answers. See our post on whether AI can build your app for you.
Does using AI create legal or privacy issues?
It can. Sending user data to a third-party model is a data processing activity under privacy law, and regulated industries have additional rules. Choose providers with appropriate agreements, minimise what you send, and tell users.