Rendered at 05:17:57 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
beachy 4 hours ago [-]
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.
namanyayg 4 hours ago [-]
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
jeswin 58 minutes ago [-]
Built something like this, but mostly just read-only. Handling writes seemed harder (and a maintenance issue), so we didn't.
namanyayg 39 minutes ago [-]
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?
mariopt 11 hours ago [-]
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?
namanyayg 11 hours ago [-]
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.
mariopt 11 hours ago [-]
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.
namanyayg 10 hours ago [-]
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.
solumos 11 hours ago [-]
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.
namanyayg 11 hours ago [-]
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.
ruben81ad 7 hours ago [-]
How do you know that the values of the automatically generated dashboards are correct?
namanyayg 6 hours ago [-]
Manual qa, evals, prompting, and inhouse validation steps. AI is not 100% perfect but it's working well for most use cases.
fomoz 6 hours ago [-]
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?
phainopepla2 5 hours ago [-]
> We're live with five businesses and 2000 daily users!
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?
namanyayg 12 hours ago [-]
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.
cowlby 5 hours ago [-]
Not the op but I think of it as “job security” for developers when they’re called to fix.
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.
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?
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?
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.
Only some (very well guardrailed) backend functionality is being used.
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.
How many paying clients (companies, not people) do you have?
https://news.ycombinator.com/item?id=48112256
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'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.