This is a very interesting idea, but I think the hardest part is not generating the workflows/apps — it’s making them safe. If the AI can read customer data and generate apps on top of APIs, prompt injection, cross-tenant data leaks, over-permissioned API calls, and generated-code bugs become serious risks.
I agree that is part of the future of AI, you describe what kind of UI you need and the app generates a combination of UI components to match your needs.
I expect this to be a simple NLP mapping via local/cloud AI model to a JSON/DSL that describes the interface. Naturally, this won't work well for complex UI that are context aware but will do well for most simple apps/dashboards.
My question is: How do you plan to make this a business?
We're live with five businesses and 2000 daily users! The technical challenges in setting the mapping, ai model, and dsl that creates reliable outputs is the engineering value we deliver.
Doing this with the AI generating the backend is definitely going to be challenging, it's essentially the user vibecoding operations that mutate data and hoping for the best.
When I envisioned this, I though about this being more frontend focused by having UI components/sections that disclosure which actions (endpoint calls) they can access. This would be virtually risk free.
But I supposed you guys are trying to solve a much bigger problem then.
Yup 80% of the usage is for new frontend features and that's actually quite valuable for our customers who serve traditional enterprises like manufacturers, hotels, labs.
Only some (very well guardrailed) backend functionality is being used.
I guess I don't really understand how this works although I admit to not reading everything. Most SaaS companies are very vigilant about not having per-customer code changes - many people have lived through the hell of ending up with divergent code bases as a result of customer demands.
But I did want to mention something that I think would work well for SaaS companies which is related, and that is empowering customers to make their own changes to the core product.
We tried at one stage having a council of customers, but it's simply wasn't practical to implement all of the ideas that they came up with. That's changed now.
I think an interesting product would bundle the communications, voting (if necessary), updates, screen captures / video demos, feedback loops and so on that are involved in a decent sized group of customers consolidating their requirements/ideas.
A true mark of success might be when the product becomes self-stewarding, with customers driving a lot of the requirements.
Our solution to that age old problem is to scope each new feature into its independent "app", which is sandboxed and walled off from the main source code
This is such an important step forward as we start to understand the 2nd order implications of AI and how it will change UIs in the future.
We used to have to allow + review 3rd party plugins for software so that people could customize it, but when the cost of development is near-0, we can simply hand over the development reigns to customers.
i love this because it seems like you've turned vibecoding up to 11 unleashing the non-technicals in your org to ship vibecode slop straight to prod. it's an idea so obviously terrible to most engineers that maybe it's actually really really smart. much bolder than yet another AI-driven dashboarding tool or smart notebook.
to address the elephant in the room... how do you think about technical debt incurred by users who likely do not understand the underlying data models, consider auth, etc?
This is a very interesting idea, but I think the hardest part is not generating the workflows/apps — it’s making them safe. If the AI can read customer data and generate apps on top of APIs, prompt injection, cross-tenant data leaks, over-permissioned API calls, and generated-code bugs become serious risks.
I agree that is part of the future of AI, you describe what kind of UI you need and the app generates a combination of UI components to match your needs.
I expect this to be a simple NLP mapping via local/cloud AI model to a JSON/DSL that describes the interface. Naturally, this won't work well for complex UI that are context aware but will do well for most simple apps/dashboards.
My question is: How do you plan to make this a business?
We're live with five businesses and 2000 daily users! The technical challenges in setting the mapping, ai model, and dsl that creates reliable outputs is the engineering value we deliver.
Doing this with the AI generating the backend is definitely going to be challenging, it's essentially the user vibecoding operations that mutate data and hoping for the best.
When I envisioned this, I though about this being more frontend focused by having UI components/sections that disclosure which actions (endpoint calls) they can access. This would be virtually risk free.
But I supposed you guys are trying to solve a much bigger problem then.
Yup 80% of the usage is for new frontend features and that's actually quite valuable for our customers who serve traditional enterprises like manufacturers, hotels, labs.
Only some (very well guardrailed) backend functionality is being used.
I guess I don't really understand how this works although I admit to not reading everything. Most SaaS companies are very vigilant about not having per-customer code changes - many people have lived through the hell of ending up with divergent code bases as a result of customer demands.
But I did want to mention something that I think would work well for SaaS companies which is related, and that is empowering customers to make their own changes to the core product.
We tried at one stage having a council of customers, but it's simply wasn't practical to implement all of the ideas that they came up with. That's changed now.
I think an interesting product would bundle the communications, voting (if necessary), updates, screen captures / video demos, feedback loops and so on that are involved in a decent sized group of customers consolidating their requirements/ideas.
A true mark of success might be when the product becomes self-stewarding, with customers driving a lot of the requirements.
Our solution to that age old problem is to scope each new feature into its independent "app", which is sandboxed and walled off from the main source code
Built something like this, but mostly just read-only. Handling writes seemed harder (and a maintenance issue), so we didn't.
Yep, even our use cases are 80% read-only, and the rest where we write is very constrained and guardrailed.
Giving non-technical users the freedom to create new backend objects is definitely scary and not worth it imo!
What did you build, any links?
This is such an important step forward as we start to understand the 2nd order implications of AI and how it will change UIs in the future.
We used to have to allow + review 3rd party plugins for software so that people could customize it, but when the cost of development is near-0, we can simply hand over the development reigns to customers.
Yes -- the future of SaaS looks more like a system of record, on top of which AI serve what's needed on the fly based on what the customer needs.
How do you know that the values of the automatically generated dashboards are correct?
Manual qa, evals, prompting, and inhouse validation steps. AI is not 100% perfect but it's working well for most use cases.
2,000 daily users is 2,000 separate paying businesses that use your app or you count one business with 2,000 employees as 2,000 users?
How many paying clients (companies, not people) do you have?
> We're live with five businesses and 2000 daily users!
https://news.ycombinator.com/item?id=48112256
Palantir Foundry as a plug-in.
Thanks for the new tagline ;)
i love this because it seems like you've turned vibecoding up to 11 unleashing the non-technicals in your org to ship vibecode slop straight to prod. it's an idea so obviously terrible to most engineers that maybe it's actually really really smart. much bolder than yet another AI-driven dashboarding tool or smart notebook.
to address the elephant in the room... how do you think about technical debt incurred by users who likely do not understand the underlying data models, consider auth, etc?
Exactly ;) One of our customers say "we've given their entire team superpowers"
I've been dealing with technical debt for half of my career. Here's what we're doing to prevent it:
- We don't ship to prod or to the main repo -- each feature is a scoped, sandboxed, separately version controlled "app".
- We have a proxy layer to pin API versions, so if the underlying contracts change, we still support all past created apps.
- Authentication follows your SaaS platform's RBAC and authentication tokens, making it easy to share within a team or across multiple tenants.
Not the op but I think of it as “job security” for developers when they’re called to fix.