Back to News
Advertisement
yyousefh409 about 2 hours ago 9 commentsRead Article on github.com

HI version is available. Content is displayed in original English for accuracy.

Hi HN, we’re Yousef & Nour, founders of Vendo (https://vendo.run). Vendo lets users create new features inside the software they already use. A user describes the dashboard, workflow, or small app they need, and Vendo builds it on top of the product’s existing data, API, and interface.

Demo: https://www.youtube.com/watch?v=VdpHehY64ls

We built Vendo because every SaaS eventually faces the same problem: every customer needs something slightly different. One wants a new report and another needs a workflow that only makes sense for their team. These requests either sit on the roadmap, become one-off engineering work, or force the customer into spreadsheets and external tools. We wanted the user to be able to create the missing feature themselves, without leaving the product.

Here is how it works:

- npx vendo init reads the product's API surface, theme, routes, and more. These are used so that the apps Vendo creates (1) look on-brand and native and (2) have the ability to read data and perform actions directly through the company's API

- When a user asks for a feature, we have a custom Vendo harness that writes a React component with a bunch of Vendo add-ons and guardrails (ex. ability to make calls to the host API + our component library). Every save is compiled, type-checked, run against real API responses, and rendered before the user sees it. We just released a benchmark and write-up here with more info for anyone interested: https://vendo.run/blog/generating-product-ui-measured

- We use QuickJS to make sure that anything the agent creates is sandboxed and can't mess with the company's site. Vendo compiles the component and runs it with Preact inside a QuickJS VM with no access to the DOM, network, or clock. The VM returns a UI tree, which the host renders using the product’s registered components. When the user clicks something, QuickJS emits a tool call; the host executes it through Vendo’s guard and passes the result back into the same VM, preserving the screen’s local state.

There's a lot of generative UI right now: streaming developer-written components into a chat (Vercel AI SDK, CopilotKit, Thesys), or rendering your app inside someone else's assistant (OpenAI Apps SDK, MCP Apps). We differ on two things. Vendo lives in your product and acts through your API as the signed-in user, so what it makes is durable: real apps users keep, pin, and run on triggers while they're away, and not components that are merely confined to a chat. Plus, it's not capped at putting together a bunch of prebuilt components: the agent can build arbitrary apps, from a quick dashboard out of your own components to real custom code running in a sandbox, and either way data only ever comes from tool calls to your API.

Here are some things customers are using Vendo for today:

- Letting their users create custom dashboards and reports. These are mainly UI-based and focused on letting the user see the exact graphs and metrics they care about

- Letting their customers create recurring automations. A big thing as well that has been used for these automations is the fact that we connect to external connections, so users have been automating many of their inter-tool workflows (ex. an automation that sends a slack alert based off of something in the product)

- B2B customers letting their customers customize the product with specific business logic. Often this is simple things like an extra field on a form, or an extra permission, but it is hard for a business to keep up with them otherwise.

- Creating and sharing custom dashboards/apps across an organization. Since the apps Vendo creates are durable, they can be shared, reused, and forked (which can’t be done with many of the other in-chat generative UI solutions)

We've spent a lot of time thinking about how AI and agents will change the way people consume software. We think the answer is personal(ized) software: you see the UI you need to see, you tell an agent exactly what you need, and the product molds to how you work.

The key insights that have enabled the product to work are:

- A rule in code always beats a rule in a prompt.

- Invent as little syntax as possible. Generation got faster and more reliable when the output looked like what models already know (JSX-shaped markup) instead of a clever custom format.

- Deterministic beats model wherever you can get away with it. Theme extraction is pure static analysis, and a remix starts as a copy of your component, no model call.

Vendo is completely open-source (Apache-2.0) and can be self-hosted, so feel free to check out all the source code here: https://github.com/runvendo/vendo.

Would love you to try it out and give us your feedback: https://docs.vendo.run/. Or if you’re a company looking to embed Vendo in your product feel free to book a call here: https://cal.com/team/vendo/intro-call

Advertisement

⚡ Community Insights

Discussion Sentiment

80% Positive

Analyzed from 671 words in the discussion.

Trending Topics

#users#claude#lot#benefit#using#already#code#product#software#customer

Discussion (9 Comments)Read Original on HackerNews

blakeashleyjrabout 2 hours ago
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!

yousefh409about 1 hour ago
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.

avree5 minutes ago
Users so technically inept they can't use chatbots? Have them vibecode changes to your product today!
echelonabout 1 hour ago
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.

yousefh409about 1 hour ago
That's really interesting. Would love to learn more about what type of customizations/features you have seen your users create?
mcmcmc35 minutes ago
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.
yousefh40913 minutes ago
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!

michaelmuzzinabout 1 hour ago
What is the extent of the customization of each dashboard type? How detailed can I get
yousefh409about 1 hour ago
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.