The decision to add an AI feature is easy to make and hard to undo. Once users adopt a feature that calls an LLM, you own the cost, the quality, the edge cases, and the trust that comes with it. The questions in this post are a decision framework for non-technical and technical founders alike - the things to know before you scope the work, not after you have shipped it.
Start With the User Problem, Not the Technology
The most important question is the one that has nothing to do with AI: what specific user problem does this feature solve, and is it a problem your users actually have? AI features that are added because AI is trending rather than because users need them tend to have low adoption and high cost. Before any technical design, write one sentence describing the user problem and one sentence describing how the AI output solves it.
If you cannot write those two sentences clearly, the feature is not ready to be scoped. This is not an AI-specific rule - it applies to every feature - but it is one that gets skipped more often with AI because the demos are impressive and the pressure to ship "an AI feature" is real.
The Data Questions
- What personal data will this feature send to the AI vendor? List the fields explicitly - name, email, message content, transaction data, health data.
- Does your privacy policy disclose AI-assisted processing to users?
- Have you signed a Data Processing Agreement with the AI vendor?
- If your users are in India, have you mapped this against your DPDP obligations? See DPDP and AI tools: mapping where data flows.
- Can the feature operate on anonymised or pseudonymised data, or does it require identifiable information?
Data questions are the hardest to fix after launch. A feature that sends customer support tickets to an AI vendor creates a data processor relationship the moment it ships. If your privacy policy does not disclose it, you have a compliance gap that a legal adviser should assess.
The Cost Questions
- What is the token cost of the average request? Have you measured it on real inputs, not test strings?
- What does a worst-case input look like, and what does that call cost?
- At your current user count, what is the monthly cost? At 10x? At 100x?
- Is there a daily or monthly cap at the provider level and in your server-side code?
- Does the feature have a non-AI fallback if the API is unavailable or the cap is reached?
For a detailed walkthrough of how to estimate these numbers, see how to estimate AI feature running costs. The short version: measure on real data, not test data, and design the fallback before you design the happy path.
The Quality and Evaluation Questions
- How will you know if the feature is working correctly? What is the test?
- What does a bad output look like, and how does your product handle it?
- Is the output shown directly to users, or does it pass through a validation step first?
- Have you defined a minimum quality threshold below which you will not ship or will alert?
- Who reviews output quality after launch, and how often?
AI features that skip evaluation ship working in the demo and fail in production. The failure is usually not dramatic - it is outputs that are subtly wrong, off-tone, or irrelevant to some subset of users. Without a measurement process, you learn about quality problems from user churn, not from your own checks. For a practical framework on this, see evals for small teams without an ML team.
The Security and Abuse Questions
- Can a user craft an input that causes the model to do something unintended - generate harmful content, reveal system prompts, or make statements your company would not endorse?
- Is the AI feature accessible to unauthenticated users, and if so, how are you rate-limiting it?
- Could the output be used to mislead other users if it appears with your brand on it?
- For features that take user-provided content as input - have you considered prompt injection, which OWASP ranks first (LLM01) in its Top 10 for LLM Applications? See prompt injection explained for founders.
- Does the feature give the model access to tools, databases, or actions beyond what the user intent requires?
The Model and Dependency Questions
- Which model version will you use, and is it pinned to a specific version string or using an alias that may change?
- What happens to your feature when the model provider retires the version you depend on?
- Do you have a migration plan if you need to switch providers - for cost, quality, or regulatory reasons?
- Is the feature tightly coupled to one vendor's output format, or can it adapt to an alternative?
Model retirement is not hypothetical. Anthropic, for example, lists retired models and says it gives at least 60 days' notice before retiring a publicly released model: Claude 3.5 Haiku was deprecated on 19 December 2025 and retired on 19 February 2026. Check your own provider's deprecation page. If your feature is pinned to a model that reaches end-of-life, you will have to migrate under time pressure. Build with that eventuality in mind from day one.
The Reversibility Question
Finally: if this feature does not work as expected and you need to remove it or disable it, what is the impact on users? Features that become part of core workflows are much harder to roll back than features that are additive. Scope your first AI feature to be additive and removable. Get signal on cost, quality, and adoption before you make it load-bearing.
How to Use This List
Run through these questions before you write the first line of implementation. Not every question will be relevant to every feature - a simple AI-powered search that runs on anonymised queries has a different risk profile than a customer-facing chatbot that has access to order history. The goal is to identify which risks apply to your specific feature and make deliberate choices, rather than discovering them after launch.
Where the answer to a question is "we don't know yet," that is valuable information. It means either the feature is not ready to be scoped, or there is a specific investigation needed before you commit to building. Treating unknowns as blockers to be resolved - rather than assumptions to be made - is the difference between an AI feature that earns user trust and one that erodes it.
One practical way to use this list is to turn it into a one-page brief that you complete before any AI feature enters the sprint backlog. The brief forces the conversation between product, engineering, and whoever owns compliance and cost in your organisation. Features that cannot be briefed tend to be features that are not yet well enough defined to build. The questions are not bureaucracy - they are the design work.
If you want a structured review of your AI feature plan before you build it - covering data, cost, evaluation, security, and model risk - that is exactly the kind of scoped advisory session we run. Book a session and we will work through the questions with you before the first line of code.
Common questions
What should I ask before adding an AI feature to my SaaS?
Cover the user problem, data sent to the vendor, running cost, quality evaluation, security and abuse, model dependency and reversibility. Unknown answers are useful, because they show where investigation is needed before you commit to building.
What happens when an AI model provider retires the model I use?
You must migrate, possibly under time pressure. Anthropic, for example, says it gives at least 60 days' notice before retiring a publicly released model. Pin a specific model version, check your provider's deprecation page and plan a migration path from day one.
Can someone review my AI feature plan before I build it?
Zovintra runs a scoped advisory session that works through the questions on data, cost, evaluation, security and model risk with you before the first line of code is written.
Sources
- LLM01:2025 Prompt Injection - OWASP GenAI Security Project, 2025
- Model deprecations - Anthropic, accessed 19 Oct 2026
