Insights
Choose a frequent job with output people can check and undo, then fix the data, permissions, states and review it relies on before you build the AI in. To add AI to an existing SaaS product, start with one job your users already do regularly, where a person can check the output and a wrong answer costs an edit rather t
To add AI to an existing SaaS product, start with one job your users already do regularly, where a person can check the output and a wrong answer costs an edit rather than an incident. Before building it, fix what that job depends on: the data it will read and who may see it, the objects and permissions it touches, the states the record must show, the review step, and logging and undo. Then build it into the record where the work happens, keep the manual path, and roll it out to people who already know the old way.
The order matters because a live product is not a blank canvas. An AI feature inherits whatever is unresolved underneath it, and makes those gaps faster and more visible.
Why an existing product is not a blank canvas
A product with paying users already has data, permissions and habits. A new AI feature reads the data that is there, under the permissions that are set, inside workflows people have learned. It does not get a clean copy of any of them.
Microsoft's guide to preparing a company for its Copilot assistant shows the mechanism plainly. Copilot and its agents retrieve data under the permissions, sharing settings and policies that already exist, and the same guide notes that SharePoint's default sharing setting is the most permissive option; several of its preparation steps are about finding and restricting overshared content (Microsoft Learn). At Tcules, we read the mechanism this way: nothing about those permissions changes when the assistant arrives. What changes is how easily one question can gather material that was previously reachable only by someone who knew where to look.
Data problems travel the same way. In interviews with 53 AI practitioners working in high-stakes fields in India, East and West Africa and the USA, Sambasivan and colleagues at Google Research found that 92% had experienced at least one "data cascade": a data issue whose negative effects compound downstream and surface late (CHI 2021). Those practitioners were building models, not adding a feature to a SaaS product, so treat it as neighbouring evidence. The pattern is worth carrying over: a gap in the data can show up late, and far from its cause.
We drew a related conclusion from our ConnectX work: adding a conversational assistant improves access to information, but it does not make a product AI-native. The same holds for repairs. An assistant placed on top does not fix the object model, the permissions or the workflow underneath; it uses them as they are. So the order of work is: choose the job, fix what it depends on, design its place in the workflow, then roll it out.
Step 1: choose the first job, not the first feature
At Tcules, we put a version of this question to Samy Melaine, founder and CPTO of Eden AI, a client of ours, when we asked for his advice to founders building with AI. His first point was to understand what clients want: "Don't do AI for AI's sake, but do it for your user's sake" (our conversation, 49:32).
In a live product, that becomes four tests for the first AI feature. Each one removes a different risk.
| Test | Why it matters in a live product | Warning sign |
|---|---|---|
| Users already do the job | There is a manual baseline to compare against, and real inputs to test on | The feature needs people to form a new habit before it can help |
| They do it regularly | Use builds up quickly enough to learn whether the feature helps | The job happens once a quarter, so evidence takes a year |
| A person can check the output | Confirming the result is quicker than redoing the work | Checking means rereading the same sources the task needed |
| A wrong answer is recoverable | An error costs an edit or an undo | The output sends, pays, deletes or publishes with no stop before it |
A job that passes all four is a good first candidate even if it looks modest. A job that fails the last test can still be a later feature, but it needs a stronger review step and recovery path than a first release should carry.
For the range of AI features a SaaS product can offer, our map of generative AI product patterns for SaaS sorts them by how much authority they take. This page assumes you have a candidate and are deciding how to put it into a product people already rely on.
Step 2: fix what that job depends on
Once the job is chosen, trace everything it touches. At Tcules, our view is that six things decide whether the feature behaves well in a live product, and each is easier to settle before users meet the feature than after.
| What to check | The question to answer | What happens if it is left |
|---|---|---|
| The data the feature reads | Is it complete, current and the version people treat as true? | The AI answers fluently from stale or partial records |
| Who may see that data | Does retrieval apply the asking user's permissions and account boundary at the moment they ask? | One team's or one customer's material appears in another's answer |
| The object and permission model | Can you name the objects the feature reads and changes, and which role may change each one? | The feature acts through a broad service account instead of as the user |
| The states the record shows | Does the record tell suggested, edited, accepted and rejected apart? | AI text becomes committed content without anyone choosing it |
| The review step | Who checks, with what evidence, and what can they do besides approve? | People approve without looking, or stop using the feature |
| Logging and undo | Can you see what the AI proposed, who accepted it and when, and reverse it? | You cannot investigate a complaint or roll back a bad batch |
In our view, the second and third rows are where existing products are most likely to carry gaps that nobody noticed while people could only reach data screen by screen. The OWASP GenAI Security Project lists both routes. Its entry on vector and embedding weaknesses describes context leaking between users in multi-tenant systems that share one vector store, and recommends permission-aware stores with strict partitioning by user group. Its entry on excessive agency warns against extensions that reach other systems with a generic high-privilege identity, and recommends running actions in the user's own context and enforcing authorisation in the downstream system rather than asking the model to decide what is allowed.
We met the review-step version of this in our BuildTwin work. AI quality control was being added to structural drawings inside an existing drawing viewer, and the brief arrived as a compact checklist. We went back to the three roles in the workflow, the detailer, the quality engineer and the approver, and made the quality engineer's review of the AI's work the centre of the design. Each result carried its drawing reference, source document, observation and conclusion; a missing input was shown as something to supply; and an override needed a corrected state and a reason. Our record of that work does not establish what shipped, and we claim no adoption, time saved or accuracy, so read it as a design decision, not a measured result.
The deeper version of the first three rows, what the system treats as current, trusted and authorised, is the subject of our article on context architecture.
Step 3: put the AI inside the record, and keep the manual path
Put the AI where the work already happens: in the record, field or editor the person is already using, with its output landing there only through an action they take. Microsoft's Well-Architected guidance for SaaS makes the same recommendation for products whose value lies in the user's workflow: place AI features inside existing editors, dashboards and core workflow components to reduce context switching, with explicit controls to accept, edit or reject what the AI produces. It also lists over-indexing on chatbots as the primary AI interface as a risk (Microsoft Learn).
A chat window beside the product is an easy first design to reach for. When the answer has to end up in a record, it makes the user the integration layer: they read, copy, paste and reformat, and the product keeps no trace of which words came from the model. At Tcules, we see that as the weakest place for a first feature in an existing product.
We learned the other half of this at Omny AI, whose platform helps brands and agencies selling on Amazon. The initial design pre-populated AI suggestions for product benefits and use cases. Users skimmed past important decisions, and even with a 90% accuracy rate, occasional errors damaged their trust. We redesigned it so the final content area starts empty, suggestions sit in a side panel and each one is added with a click; purple marks AI-generated content and blue marks user input. The panel sits beside the record, but the record is where the output lands, and only by the user's choice. What we took from that work is that an AI interface succeeds on how people interact with the suggestions, not only on their quality.
Keep the manual path working. Some users will not trust the feature yet, some cases will fall outside what it handles, and the model or provider will sometimes be unavailable. Microsoft's guidelines for human-AI interaction, tested by 49 design practitioners against 20 AI products (Amershi and colleagues, CHI 2019), include making unwanted AI easy to dismiss and making it easy to edit, refine or recover when the system is wrong. In practice that means a dismissed suggestion leaves the person exactly where the old workflow would have, and the feature can be switched off for an account without breaking anything else. We set out the patterns for the review step itself in human-in-the-loop UX patterns.
Step 4: roll it out to people who already know the old way
Your users have habits, and a new feature disturbs them even when it helps. Three decisions shape the rollout.
Opt-in or on by default. At Tcules, our rule of thumb is this: a feature that only suggests, is easy to ignore and commits nothing without the user can be on by default, as long as it is clearly marked. A feature that reads more widely than the screen the user is on, sends anything outside the product or changes records should start as opt-in. In a B2B product, give the customer's administrator an account-level switch, because they answer for their organisation's data.
Telling people what changed. One of the eighteen human-AI guidelines cited above is to notify users when the AI adds or updates its capabilities. Sedley and Müller at Google set out ten actions for managing change aversion when the Google Docs List was replaced by Google Drive, among them priming users for the change, explaining its benefits, letting them switch between the new and old interface, letting them send feedback directly and telling them what was improved. Compared with other redesign launches that did not use the framework, user perceptions were significantly more positive (CHI 2013). It is one case study rather than a controlled experiment, and an interface change rather than an AI feature, but its users were in the same position as yours: people with settled habits.
If your product serves people in the EU, Article 50 of the AI Act has applied since 2 August 2026. People must be told when they are interacting with an AI system unless that is obvious, and systems that generate synthetic text, images, audio or video must mark their outputs in a machine-readable form; for systems placed on the market before 2 August 2026, the marking duty applies from 2 December 2026 (European Commission). The marking duty does not apply where a system performs an assistive function for standard editing, and the Commission envisages a narrow exemption, under conditions set in its guidelines, for outputs used in business-to-business or industrial contexts. Which duties fall on you as provider or deployer is a question for your counsel; the product question is where the disclosure appears.
Measuring whether it is used and trusted. Count use against the people who did the job, not against all users: of those who did the task this week, how many used the AI, and how many came back to it. Then read trust from what people do with the output: how often they accept it unchanged, edit it, reject it or undo it, and how those rates move as they gain experience. A rising acceptance rate is not good news by itself, because it is also what approving without looking produces, so pair it with spot checks of accepted outputs. If people try the feature once and return to the manual way, we set out three causes and how to tell them apart in why users stop using an AI feature after trying it once.
When not to add AI yet
Google's People + AI Guidebook points out that a rule or heuristic can work as well as AI, or better, and is easier to build, explain, debug and maintain. Among the cases it lists where AI is probably not better are these: when predictability is the most valuable part of the experience, when the information is static or limited, and when the cost of an error outweighs a small gain in success. At Tcules, we would add five conditions that say "not yet" for an existing product:
- You cannot say who should be able to see the data the feature would read.
- Nobody owns the review: no one has the time, the evidence or the authority to check the output.
- The data the job depends on is wrong in ways people currently correct by hand.
- A rule, better search or a clearer workflow would do the job.
- The platform underneath is due for replacement, in which case the decision about preserving, redesigning or replatforming legacy software comes first.
None of these is a permanent no. Each is something to fix, after which the same job may pass the four tests in step 1. If you want an outside view before committing to an AI roadmap, our AI Product UX Readiness Assessment is built for that point, and it can conclude that AI is not the right product intervention.
Where this work sits
Tcules is a digital product design studio creating ambitious new software products and making established ones better. Adding AI to an established product is that second job, and we do it as AI Product Engineering: product design and software engineering together, with a scope that can include model or provider integration, retrieval, tools, frontend and backend delivery, evaluation and QA. We start with one scenario valuable enough to test the product proposition and bounded enough to evaluate, define its data, model role, tools, interface state, human authority and recovery, and then build the thinnest working slice that can produce credible evidence.