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.
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 think the main difference, and the angle that makes your approach much more feasible, is that what users of your solution build fully lives „outside“ the core application that they build against, right?
While my approach is that users would modify the core application itself (even if initially in a sandboxed copy), which would be a lot more powerful, but also a lot more complex, with many more hard questions that would need to be answered, like how to deal with data and security and so on.
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
Hmm great, All these on the fly generated apps also needs some adult supervision to ensure secuirty and compliance. So you need to consider including some builtin security guardrails. But overall this is a nice idea.
Yup! That's one of the biggest things we build while shipping this for a Series B SaaS. It's invisible but one of the hardest technical challenges.
We've got guardrails before any code is generated and we put three layers of validation after the feature is ready to make sure it's using the correct data and it's functioning for the use case that the customer asks for.
Good, i have built sekorti dot com after my experiences as a founder of reetro, so we can partnerup where all those apps generated by your tool can get a free security and vlunerabilities scan and the possibilty to have a full functional trust center and other portals. try our sekorti dot com and let me know, if you are open for collaboration. Lovable is already doing this type of stuff with aikido.
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 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?
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.
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.
What if software shipped with a software engineer?
https://manuel.kiessling.net/2025/11/04/what-if-software-shi...
Nice article. That's basically what we do. We also make the created code saveable and shareable so they can reuse what they've already built
I think the main difference, and the angle that makes your approach much more feasible, is that what users of your solution build fully lives „outside“ the core application that they build against, right?
While my approach is that users would modify the core application itself (even if initially in a sandboxed copy), which would be a lot more powerful, but also a lot more complex, with many more hard questions that would need to be answered, like how to deal with data and security and so on.
very true! we sandbox and keep it independent of the main codebase, which makes it easier to build and share new features.
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?
Hmm great, All these on the fly generated apps also needs some adult supervision to ensure secuirty and compliance. So you need to consider including some builtin security guardrails. But overall this is a nice idea.
Yup! That's one of the biggest things we build while shipping this for a Series B SaaS. It's invisible but one of the hardest technical challenges.
We've got guardrails before any code is generated and we put three layers of validation after the feature is ready to make sure it's using the correct data and it's functioning for the use case that the customer asks for.
Good, i have built sekorti dot com after my experiences as a founder of reetro, so we can partnerup where all those apps generated by your tool can get a free security and vlunerabilities scan and the possibilty to have a full functional trust center and other portals. try our sekorti dot com and let me know, if you are open for collaboration. Lovable is already doing this type of stuff with aikido.
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.
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 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.
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 ;)
[flagged]
[flagged]
[flagged]
[flagged]