Launching today
Yedric.ai
Let users control your SaaS with natural language
469 followers
Let users control your SaaS with natural language
469 followers
Your users shouldn't have to learn where every feature lives. Yedric adds an embeddable AI agent to your SaaS that turns natural-language requests into actions your product already knows how to perform. Users simply say what they want done and Yedric handles the interaction. Instead of building and maintaining your own agent experience, developers can make their existing product AI-native in under 30 minutes.
MESA
Hey Product Hunt! 👋
I've spent more than two decades building SaaS products, and the basic interaction model has barely changed: we decide what the software can do, organize those capabilities into an interface, and then expect users to figure out how it works. Every new capability means more for users to learn.
AI gives us an opportunity to flip that model around. Instead of making users learn how our software works, what if they could simply tell it what they want to accomplish?
That's what we built Yedric to do. Yedric is an embeddable AI agent that turns what your app can already do into things users can simply ask for. You give Yedric access to your product knowledge, user context, and APIs, and he can actually get things done inside your app.
We originally built this technology for our own Shopify apps. We wanted users to be able to say things like "turn off email notifications" or "fix my broken integration" and have the app handle it for them instead of sending them through docs, support, or a maze of settings.
Then something unexpected happened.
Those conversations became one of our best sources of product insight. When users asked for something our apps couldn't do, we could see exactly what they were trying to accomplish, in their own words, at the moment they were trying to do it. In one month, a single app surfaced more than 80 distinct feature requests this way.
That's when we realized this shouldn't just be something we built for ourselves.
We've tried to make adding this kind of AI to an existing SaaS product ridiculously easy. Most developers can have Yedric running in under 30 minutes, and it's free (you bring your own LLM key).
We're still early, and that's a big part of why we're launching here. I'm curious whether other SaaS builders are seeing the same shift: five years from now, how much software will still make users navigate an interface vs. letting them simply ask for what they want?
Thanks for checking out Yedric. I'll be here all day answering questions and would love your feedback!
Do you see it as a replacement for traditional navigation or more as another way to access it?
MESA
@jordantaylor58 Great question! For now, it's another way to get around, not a replacement. People are still used to menus, and Yedric actually depends on your app's existing routes to navigate on a user's behalf. So good navigation still matters.
Longer term, I think that could change. As people get more comfortable with AI, they may end up moving through apps mostly by asking an assistant instead of clicking through menus. We're building Yedric with that shift in mind.
Does it ask follow up questions or try to infer the intended action?
MESA
@fletcher_graham Thanks for the question :)
If more clarity is needed from the user, follow up questions are asked in the form of questions or form fields directly in the conversation thread.
A good example of this happens often in our automation platform, MESA. When users describe what they want to automate, Yedric asks follow up questions to fully understand their intent before choosing the right primitive steps for building the actual workflow.
Otherwise, if the user's action is clearly understood, Yedric just handles it right then and there.
MESA
@erik_v Great questions!
> How does the app interface work technically?
You embed Yedric with one script tag and a small widget element in your app, and Secure Mode lets your server sign the logged-in user's ID so the agent knows exactly who it's talking to. Point it at your help center or docs and it builds a knowledge base it searches before answering, and page prompts give it extra context based on which page the user is on.
> How does the agent act is my SaaS?
Server-side actions run through MCP: you connect an MCP server, import an OpenAPI spec, or point us at your API docs, and the agent can call your API to look up an account, change a setting or start a workflow.
What does the integration process look like for an existing SaaS with a large action set?
MESA
@camiladuarte It depends on whether you have an OpenAPI spec or not. If you do, you can import the OpenAPI spec, and it will automatically import your APIs as actions.
If you have a lot of actions and pages, I’d recommend configuring your prompts based on the page the user is currently on. That way, you’re only showing prompts and actions that actually make sense in that context.
We’ve integrated this product with some of our other apps, and in some cases we have 20+ actions available in a single app. However, each page typically shows no more than 3–5 relevant prompts. The page the user is on helps determine which prompts and actions are surfaced. I’d recommend going through each page and asking, “What would a user want to do from here?” Then build or surface the actions around those use cases.
Do you see it as a replacement for traditional navigation or more as another way to access it?
MESA
@taoma17Personally, I don’t see this as a replacement for navigation. I see it more as an assistant for your app.
If a user has a question about how to do something in the app, the agent normally does a really good job of answering it based on your documentation. Then, if you add built-in actions, it becomes even more useful because users can configure things or retrieve data from your app directly through the assistant.
To me, it’s less about replacing the UI and more about giving users another, easier way to interact with and understand your app.
Building my own in-app assistant for a field-sales app taught me the hard part isn't understanding the request, it's deciding what the agent is allowed to do without asking. Reading data is easy, but deleting a customer or changing a contract is not. How do you handle confirmation for destructive actions? Is that set per action by the developer?
MESA
@richysem
You can try to be clever about it and require extra confirmation in the chat before allowing destructive actions.
But if you're really concerned about destructive actions, I think the safest approach is to use the AI to guide the user to the appropriate place in the UI, where they have to perform the destructive action themselves.
For instance, if a user asks the AI to delete something, instead of deleting it directly, the AI can point them to where they can delete it in the UI. That way, the AI is still assisting the customer and helping them accomplish what they want, without actually performing the destructive action on their behalf.