How does this differ from retool?
Launch HN: Prized (YC S26) – Let non-engineer staff build secure internal tools
11–20 of 60 posts
Re: Launch HN: Prized (YC S26) – Let non-engineer staff build secure internal tools
#12I’m playing with this exact concept but going down the path of a Claude code plugin that is optimized for configuring lowdefy apps because of that framework’s unique approach where you don’t write code you generate yaml configs that then drive the rendering of an app. So far it’s working pretty well, still pressure testing it. The audit control and permissions management you have is great, especially around the conne…
Thanks! We've actually have been experimenting with the config generation approach as well. One tradeoff we noticed was it turns the system into more of an app builder where the ceiling of what you can do is lower compared to a coding agent. But it's much faster than codegen. How dynamic have you found Lowdefy compared to codegen?
Re: Launch HN: Prized (YC S26) – Let non-engineer staff build secure internal tools
#13Very cool. What model is used for the judge? We use setoku for Claude-built internal tooling but the design doesn’t allow writes so that there’s no inference cost on the server. Having the judge check for danger is a neat design.
Today it's GPT-5.6 Luna sitting inline on the egress broker, with Terra re-judging anything Luna flags as ambiguous. We are still experimenting though.
Re: Launch HN: Prized (YC S26) – Let non-engineer staff build secure internal tools
#14I like the security-first posture. What's your view on how foundation models will or won't evolve into this space? Like will CC steamroll this in 2 years when it can natively build connectors and run them from within the desktop app? Not saying you won't have an ongoing edge, I just want to understand the thesis better so I can learn. Cool product!
Thanks! We believe the building aspect is already commoditized and we're experimenting with leaning into this with BYOA (bring-your-own-agent). Our bet is that the labs will stay focused on the model and won't do the more unglamorous governed deployment layer needs (credential scoping, per-tool db, audit, etc), but time will tell.
Re: Launch HN: Prized (YC S26) – Let non-engineer staff build secure internal tools
#15How does this differ from retool?
It's funded by YC!
Re: Launch HN: Prized (YC S26) – Let non-engineer staff build secure internal tools
#16Re: Launch HN: Prized (YC S26) – Let non-engineer staff build secure internal tools
#17Demo looks cool, congrats on the ship! Probably missed but is it possible to externally share/view the built artifact outside of prized?
Re: Launch HN: Prized (YC S26) – Let non-engineer staff build secure internal tools
#18How does this differ from retool?
It's funded by YC!
Re: Launch HN: Prized (YC S26) – Let non-engineer staff build secure internal tools
#19Awesome launch and good pricing. We built an equivalent version in our org that takes HTML/JSX files and stores/serves them like an S3 bucket would. Works fabulous and we considered turning it into a SaaS product, met a real need in our org. Wishing you guys the very best of luck!!
I am currently building something similar for my company. We are enabling people to host apps with python backends as well, so that people can do more complex tweaking of data for scientific workflows. The out-of-box solutions keep users constrained to an environment that doesn't allow things like importing weird packages on the back and front end for custom apps. The security implications are challenging, but I can mostly just keep the apps hosted in a highly constrained environment.
Separately I haven't yet seen a great security governance model for LLM integrations. At an enterprise level I'd like to govern rules such that, for example, if someone gives an LLM access PII information or proprietary data, then it shouldn't have access to a slack integration or the internet. Controlling this at the employee or team level doesn't make sense, as an employee may have reason to make separate use of both. From a security perspective I want them to be able use LLMs with different types of acccess, but not necessarily the same agent at the same time. Furthermore, they could ideally chain together agents with different permissions in specific orders. For example they could have a workflow where an agent can reach out to the internet, and then have a separate one that can read/write to slack, and then have a third that can interact with PII data. If they tried to wire together agents in the opposite order, it should get denied.
Re: Launch HN: Prized (YC S26) – Let non-engineer staff build secure internal tools
#20I like this a lot. Do you handle scenarios where the data and context live in a data warehouse (Snowflake, etc)?
There are a lot of operational needs that exist downstream from dbt models that combine data from the various source systems.