Vendo's "user-built features" pitch sounds great until you hit
Here's where I get skeptical.
The architecture they're selling
Init step: npx vendo init ingests your API surface, theme, routes, component library. Claims the generated apps look native and can read/write through your actual API as the signed-in user.
Generation harness: Custom agent writes a React component with Vendo add-ons — API call helpers, their component library, guardrails. Every save gets compiled, type-checked, run against real API responses, rendered before the user sees it.
Runtime: QuickJS VM, Preact, zero DOM/network/clock access. VM returns a UI tree; host renders it with your registered components. User clicks → VM emits tool call → host executes through Vendo's guard → result passes back into VM, preserving local state.
They published a benchmark write-up at vendo.run/blog/generating-product-ui-measured if you want the numbers.
Where the "durable apps" claim gets tested
They contrast against Vercel AI SDK, CopilotKit, Thesys (streaming dev-written components into chat) and OpenAI Apps SDK, MCP Apps (rendering your app inside someone else's assistant). Two differentiators:
- Lives in your product, acts as the signed-in user → apps persist, get pinned, run on triggers while users are away. Not chat-confined.
- Not capped at prebuilt components → agent can build arbitrary apps, from dashboards using your components to custom sandboxed code. Data only ever comes from tool calls to your API.
Current customer use cases: custom dashboards/reports, recurring automations with external connections (Slack alerts triggered from product events), B2B customers letting their clients add business logic (extra form fields, permissions), sharing custom apps across orgs.
The questions I'd ask before integrating
API surface drift: vendo init snapshots your API at a point in time. What happens when you ship a breaking change? Does the generated app silently fail, or does Vendo re-introspect automatically? The blog post doesn't address versioning.
Guard granularity: "Vendo's guard" executes tool calls. How configurable is that guard? Can I say "this user role can read /analytics but not write /billing"? Or is it all-or-nothing per API?
QuickJS limits: No DOM, network, clock. That means no Date.now(), no fetch, no direct DOM manipulation. Fine for pure UI + API calls, but what about a user who wants a chart that updates every 30 seconds? Or a component that needs a third-party library not in your registered set?
State persistence: "Preserving the screen's local state" across tool calls sounds nice. But where does that state live when the user closes the tab and comes back tomorrow? The VM is ephemeral. Is state serialized to your backend? To localStorage? To a Vendo-managed store?
Type-checking against real API responses: They claim compilation runs against real API responses. That implies Vendo needs a staging environment or mock server that mirrors production. Who maintains that parity?
The "arbitrary code" claim: Agent can build "real custom code running in a sandbox." QuickJS supports ES2023, but no Node APIs, no npm. So "arbitrary" means "arbitrary logic using only the APIs you expose." That's not nothing, but it's not arbitrary either.
What would make me take this seriously
A public repo showing a non-trivial generated app — something with 3+ API calls, conditional rendering, user input validation, and a scheduled trigger — plus the exact prompt that produced it. And a failure case: show me what happens when the API changes and the generated app breaks.
The "users build features so engineering doesn't have to" narrative is catnip for product leaders. The implementation details are where this lives or dies.