Not sure if this is productizable as-is, but I think it's absolutely the right direction. A lot of software has to become WAY more malleable directly in the hands of users.
Software vendors should be providing the platform, including any hard-to-build widgets, and "stock" look-and-feel so that the software is usable out of the box, but then the customers should be able to send their product feature requests directly to a chatbot, whether it is embedded into the platform (i.e. same vendor) or rides on top (i.e. different vendor).
This is the new form of UGC. The vendor can turn it into a marketplace within that platform, promote popular 3rd party features in that marketplace, etc.
I’ll say it: this sounds like it would be absolute hell for customer support. “Special” clients are already tough to manage with weird little workarounds and random business requirements. If you let them start making changes themselves, they will inevitably break it and then come to support freaking out because some “business critical” feature they made isn’t working how they want it to, or isn’t working at all. And how is customer support to know what the AI generated feature is, or how to fix it? Now make that possible for every customer, not just those paying enough money to throw their weight around, and you’ve got a recipe for a pissed off, burnt out help desk. And probably some stressed out account managers who have to smooth things over to try and retain the client. Does not surprise me the founders don’t appear to have much experience in customer-facing roles.
Great points, and this is a problem we have spent a lot of time thinking about as well. Our current hypothesis, is that the models will reach (and have already arguably come very close) a level where problems like these can be resolved without any human intervention needed. That doesn't mean that problems won't arise, they for sure will (nothing will ever get to 100%), but the increasing strength of the agents will allow resolving those issues to become very consumer-friendly.
I would also encourage you to take a look at our benchmarks (linked in the post), that show how the gaurdrails we have in-place allow us to deliver pretty strong results to our users. And as a last point, most of our users are not creating business-critical features with Vendo right now. For a lot of them, it is an additional feature that they wished they had but didn't. And for the companies we work with, the benefit of providing their customers with this level of customization outweigths the possible risk that you mention.
Would love to hear more of your thoughts, thanks for the feedback!
> Our current hypothesis, is that the models will reach (and have already arguably come very close) a level where problems like these can be resolved without any human intervention needed.
Frankly I don’t think this is that relevant. When software breaks, most people don’t want to get support from another piece of software. They want human support. As the models get better, I’d wager the problems that fall through will get increasingly messy by nature of a) being hard enough to stump the model or b) the model running in circles making changes that obscure or worsen the problem. Especially if you have non-technical users who can’t accurately describe what they want or the problem with the current state.
Benchmarks and guardrails are nice and all, but as you said problems will never be 100% self correctable. Models are good enough until they aren’t. I like to take a “what’s the worst that could happen” approach to planning support. Murphy’s law and all that.
> And as a last point, most of our users are not creating business-critical features with Vendo right now.
Just give it some time… you’d be surprised what becomes business critical in the eyes of a customer. Sooner or later a report will become part of an accounting workflow etc, and it’ll break on the wrong day and suddenly payroll is late. You know how many Excel sheets are “business critical”? Same thing.
An alternative model you might consider is selling direct to the end user companies and taking a partnership approach to the apps you work with. End users come straight to you for help, you have a list of integrated apps you already support with the required plan/license from that vendor plus custom MCP support and features that don’t need an API, then sell professional services engagements if an end user client wants you to work with one of their vendors to set up a new integrated app. That way you reduce support friction, and your end users are aligned with your buyers.
What benefit does this provide over an excellent API + MCP access?
I often find my users want to throw their Claude at it and have everything handled. Users have even developed their own local UIs using Claude Design. As long as they are within the bounds of the MCP I already provide access to, no problem. This also has the added benefit of using the AI subscription the org already pays for (or using the customers).
Edit: Congrats on the launch and thanks for open sourcing!
I don't know - I think these Vendo guys are onto something here. Businesses will absolutely need to do this.
As a data point, our users are going a step further. We gave away our desktop software as OSS and our users fork and vibe code on top with the entire stack. They get the benefit of not having JavaScript powering a media heavy app since we wrote it in Rust. Now we have users making their own tutorials about it.
I think non experts will appreciate engineers solving for smoothness, distributed systems, and all the hard parts that can back them into corners. They want to fill in the UX / workflow pieces themselves.
I think these "hard part" pillars will endure for a while longer.
But you're going to have to give away more than you've ever given away before. Treat your users as junior engineers on your team. That's the new normal.
And for full disclosure, none of our users have software backgrounds whatsoever. They're just heavy into Claude Code as complete software newbies. It's really awesome to watch them building really neat workflows.
Great question! Honestly, not a lot. This is moreso for the rest of the population that does not even know Claude Code exists. A lot of our customers are vertical SaaS's that have tons of non-technical users using their product every day, and we want to bring them the power of claude code right inside their product.
I think you bring up a good point though on how consumption of software will evolve (and the possibility of Claude just being the entrance to everything), and I think this is soemthing we have been thinking a lot about as well.
> Deterministic beats model wherever you can get away with it.
Both Apple and Google appeared to be making the contrary bet: define an MCP-like API layer (AppIntents and Appfunctions) that apps can implement so that the platform's agent, or in some cases maybe third-party agents, can manipulate those apps.
That's going to be very attractive by making automations on demand. I like to say agents automate automation. An automatic on demand saw sharpener.
I'm working on a project in which I have created an AppFunctions layer and tested it with the test agent Google provides. It's really pretty magical, weaving together information extracted from the app I'm creating with travel time estimates and information about nearby businesses, for example. Generating that non-trivial example was a piece of cake. The agent got it right on the first try.
The consequence is that there is a whole class of features that would've depended on bespoke integrations, protocols, APIs, inter-app communication, etc. that, not only do I not have to implement, but I should refrain from implementing because the usage patterns are going to rely on agents.
Consider tightening up the pricing page. Paying $49/month for "$49 of usage a month" doesn't tell me what I'm getting. How many is "a few hundred", 200?
Pro $49/month
- Includes $49 of usage a month
- ≈ a few hundred active end-user sessions
An LLM safety judge concerns me.
"You are Vendo Auto, a safety judge for tool calls.",
"Choose run only when the call is appropriate for the user and context.",
"Choose ask when user confirmation is warranted, and block when the call must not proceed.",
"Return a concise rationale grounded in the supplied call, context, directions, and recent activity.",
Thanks for the feedback! The $49 of usage is used across AI inference, sandbox minutes, and so on. We mention it later on in the pricing page, but will make sure it is more clear fromt he onset.
And yes, the LLM safety judge is not in general access right now. Still experimenting, and it is not being used by any customers currently.
How does your VM handle local state and performance, when the user attempts to fetch, join and render data from multiple endpoints?
We use Dart and Go (front/backend) to allow users to render widgets/mini-apps on Maxint (Finsight). And hence, the speed (virtually instant) and overall quality of the output mostly depends on the LLM/inference endpoint that they choose.
In general, most users are happy with the existing features, however more advanced users have a playground to ship enhancements on-the-fly.
Interesting - but how do you ensure the generated UI's are high enough quality that I as a company would be happy showing them to my users. A lot of users are pretty tech-literate and would definitely critique anything that is wrong in the UI
Great question! We have a couple things:
(1) We have strict gaurdrails that makes sure that all data displayed in the generated comoponents is accurate and sourced from a real API call
(2) We learn your design system and brand, so that everything Vendo generates looks and feels native
(3) We have our library of pre-built components purpose-built for Vendo and how it works, which helps us increase the quality even more
The future of this is having a API (with CLI, MCP) and then a SKILL.md file for other system to integrate with it.
Basically like yourapp.com/api/openapi.json and yourapp.com/api/skill.md.
This is the universal integration interface. Any app that wants to expose itself to be used by others to build things on top can do this. AI is the integration layer, avoids the integration hell.
cool idea, at first glance I wonder how much of this could be covered by MCP? Claude connected to all of my other tools and a product's MCP can create custom views/dashboard/automations/etc.
As detailed as the user wants. We don't limit the user with things like pre-built components and so on, so they can let their creativity run wild. What we chose to focus on instead, is making sure that the things they create are sandboxed, accurately representing the data at hand, and feel native in the product.
Not sure if this is productizable as-is, but I think it's absolutely the right direction. A lot of software has to become WAY more malleable directly in the hands of users.
Software vendors should be providing the platform, including any hard-to-build widgets, and "stock" look-and-feel so that the software is usable out of the box, but then the customers should be able to send their product feature requests directly to a chatbot, whether it is embedded into the platform (i.e. same vendor) or rides on top (i.e. different vendor).
This is the new form of UGC. The vendor can turn it into a marketplace within that platform, promote popular 3rd party features in that marketplace, etc.
This is a great idea. Some of it is already happening with skills in chatgpt/claude
Great points!
I’ll say it: this sounds like it would be absolute hell for customer support. “Special” clients are already tough to manage with weird little workarounds and random business requirements. If you let them start making changes themselves, they will inevitably break it and then come to support freaking out because some “business critical” feature they made isn’t working how they want it to, or isn’t working at all. And how is customer support to know what the AI generated feature is, or how to fix it? Now make that possible for every customer, not just those paying enough money to throw their weight around, and you’ve got a recipe for a pissed off, burnt out help desk. And probably some stressed out account managers who have to smooth things over to try and retain the client. Does not surprise me the founders don’t appear to have much experience in customer-facing roles.
Great points, and this is a problem we have spent a lot of time thinking about as well. Our current hypothesis, is that the models will reach (and have already arguably come very close) a level where problems like these can be resolved without any human intervention needed. That doesn't mean that problems won't arise, they for sure will (nothing will ever get to 100%), but the increasing strength of the agents will allow resolving those issues to become very consumer-friendly.
I would also encourage you to take a look at our benchmarks (linked in the post), that show how the gaurdrails we have in-place allow us to deliver pretty strong results to our users. And as a last point, most of our users are not creating business-critical features with Vendo right now. For a lot of them, it is an additional feature that they wished they had but didn't. And for the companies we work with, the benefit of providing their customers with this level of customization outweigths the possible risk that you mention.
Would love to hear more of your thoughts, thanks for the feedback!
> Our current hypothesis, is that the models will reach (and have already arguably come very close) a level where problems like these can be resolved without any human intervention needed.
Frankly I don’t think this is that relevant. When software breaks, most people don’t want to get support from another piece of software. They want human support. As the models get better, I’d wager the problems that fall through will get increasingly messy by nature of a) being hard enough to stump the model or b) the model running in circles making changes that obscure or worsen the problem. Especially if you have non-technical users who can’t accurately describe what they want or the problem with the current state.
Benchmarks and guardrails are nice and all, but as you said problems will never be 100% self correctable. Models are good enough until they aren’t. I like to take a “what’s the worst that could happen” approach to planning support. Murphy’s law and all that.
> And as a last point, most of our users are not creating business-critical features with Vendo right now.
Just give it some time… you’d be surprised what becomes business critical in the eyes of a customer. Sooner or later a report will become part of an accounting workflow etc, and it’ll break on the wrong day and suddenly payroll is late. You know how many Excel sheets are “business critical”? Same thing.
An alternative model you might consider is selling direct to the end user companies and taking a partnership approach to the apps you work with. End users come straight to you for help, you have a list of integrated apps you already support with the required plan/license from that vendor plus custom MCP support and features that don’t need an API, then sell professional services engagements if an end user client wants you to work with one of their vendors to set up a new integrated app. That way you reduce support friction, and your end users are aligned with your buyers.
What benefit does this provide over an excellent API + MCP access?
I often find my users want to throw their Claude at it and have everything handled. Users have even developed their own local UIs using Claude Design. As long as they are within the bounds of the MCP I already provide access to, no problem. This also has the added benefit of using the AI subscription the org already pays for (or using the customers).
Edit: Congrats on the launch and thanks for open sourcing!
I don't know - I think these Vendo guys are onto something here. Businesses will absolutely need to do this.
As a data point, our users are going a step further. We gave away our desktop software as OSS and our users fork and vibe code on top with the entire stack. They get the benefit of not having JavaScript powering a media heavy app since we wrote it in Rust. Now we have users making their own tutorials about it.
I think non experts will appreciate engineers solving for smoothness, distributed systems, and all the hard parts that can back them into corners. They want to fill in the UX / workflow pieces themselves.
I think these "hard part" pillars will endure for a while longer.
But you're going to have to give away more than you've ever given away before. Treat your users as junior engineers on your team. That's the new normal.
And for full disclosure, none of our users have software backgrounds whatsoever. They're just heavy into Claude Code as complete software newbies. It's really awesome to watch them building really neat workflows.
That's really interesting. Would love to learn more about what type of customizations/features you have seen your users create?
Great question! Honestly, not a lot. This is moreso for the rest of the population that does not even know Claude Code exists. A lot of our customers are vertical SaaS's that have tons of non-technical users using their product every day, and we want to bring them the power of claude code right inside their product.
I think you bring up a good point though on how consumption of software will evolve (and the possibility of Claude just being the entrance to everything), and I think this is soemthing we have been thinking a lot about as well.
Users so technically inept they can't use chatbots? Have them vibecode changes to your product today!
> Deterministic beats model wherever you can get away with it.
Both Apple and Google appeared to be making the contrary bet: define an MCP-like API layer (AppIntents and Appfunctions) that apps can implement so that the platform's agent, or in some cases maybe third-party agents, can manipulate those apps.
That's going to be very attractive by making automations on demand. I like to say agents automate automation. An automatic on demand saw sharpener.
I'm working on a project in which I have created an AppFunctions layer and tested it with the test agent Google provides. It's really pretty magical, weaving together information extracted from the app I'm creating with travel time estimates and information about nearby businesses, for example. Generating that non-trivial example was a piece of cake. The agent got it right on the first try.
The consequence is that there is a whole class of features that would've depended on bespoke integrations, protocols, APIs, inter-app communication, etc. that, not only do I not have to implement, but I should refrain from implementing because the usage patterns are going to rely on agents.
Consider tightening up the pricing page. Paying $49/month for "$49 of usage a month" doesn't tell me what I'm getting. How many is "a few hundred", 200?
An LLM safety judge concerns me. https://github.com/runvendo/vendo/blob/9e9782f653366793a769c...Thanks for the feedback! The $49 of usage is used across AI inference, sandbox minutes, and so on. We mention it later on in the pricing page, but will make sure it is more clear fromt he onset.
And yes, the LLM safety judge is not in general access right now. Still experimenting, and it is not being used by any customers currently.
How does your VM handle local state and performance, when the user attempts to fetch, join and render data from multiple endpoints?
We use Dart and Go (front/backend) to allow users to render widgets/mini-apps on Maxint (Finsight). And hence, the speed (virtually instant) and overall quality of the output mostly depends on the LLM/inference endpoint that they choose.
In general, most users are happy with the existing features, however more advanced users have a playground to ship enhancements on-the-fly.
Interesting - but how do you ensure the generated UI's are high enough quality that I as a company would be happy showing them to my users. A lot of users are pretty tech-literate and would definitely critique anything that is wrong in the UI
Great question! We have a couple things: (1) We have strict gaurdrails that makes sure that all data displayed in the generated comoponents is accurate and sourced from a real API call (2) We learn your design system and brand, so that everything Vendo generates looks and feels native (3) We have our library of pre-built components purpose-built for Vendo and how it works, which helps us increase the quality even more
I like the idea. This is where software is going.
The future of this is having a API (with CLI, MCP) and then a SKILL.md file for other system to integrate with it.
Basically like yourapp.com/api/openapi.json and yourapp.com/api/skill.md.
This is the universal integration interface. Any app that wants to expose itself to be used by others to build things on top can do this. AI is the integration layer, avoids the integration hell.
I have tried similar things before. It works.
cool idea, at first glance I wonder how much of this could be covered by MCP? Claude connected to all of my other tools and a product's MCP can create custom views/dashboard/automations/etc.
What is the extent of the customization of each dashboard type? How detailed can I get
As detailed as the user wants. We don't limit the user with things like pre-built components and so on, so they can let their creativity run wild. What we chose to focus on instead, is making sure that the things they create are sandboxed, accurately representing the data at hand, and feel native in the product.
I am applying this to Gov. programs.