Thanks! That's the best kind of validation. If you ever take Prized for a spin, would genuinely love to hear how it compares to what you built, especially on the data access side.

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.

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.

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?

Thanks! The private endpoint tip is very much on point. We've already hit two prospects where the blocker was that they don't want full self-host but their security groups won't take generic cloud egress. It's on the list.

Yes, we support Snowflake and ClickHouse today. And we're happy to integrate more, just say the word :)

You can reuse the app indefinitely, for cheap, and predictably. I would say these are huge advantages.

Thanks! Agree that for one-off questions, chat is the right interface. We’ve found apps win when the workflow is repeated across a team and they almost become “templates” that seed ideas for other coworkers.

Fair, the generation part is commoditized. What we sell is the trust layer around company data. No credentials in the builder's hands, scoped access per tool, forkability etc. CC + Railway works until someone pastes a prod key into an env var.

Thank you! Yes, you can share it externally if it isn't connected to external data sources.

Thanks for the feedback. From what we've gathered so far, non-eng are using CC or Codex to build one-off internal tools, but they're deploying them on their personal Vercel accounts and sending the url over Slack. That's the workflow we want to replace with a reasonable level of security and auditability. We're still trying to gauge interest in using the CLI to build and having everything deploy on Prized, we're working out whether that's valuable.

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.

Closest comp. I'd argue the "AI builds the app part" is fast becoming table stakes. The unsolved problem is what happens after the app exists and that's what we actually built. Anyone in the org can fork a coworker's tool and rebind it to their own data scope. Enforcement also happens at a different layer. From what we've gathered, Superblocks controls who can run an app and bakes guardrails in when the app is generated, but every app still queries through a shared database credential. On our side, each tool gets its own database role that can only see its own data, and credentials live in a proxy the code never touches. So even when the AI writes bad code, it can't reach anything it shouldn't.

We ended up splitting permissions per-tool for data and per-person for connections, for basically this reason. Every tool gets its own db role that can only see its own schema, and integration credentials live in a broker the tool's code never touches. So one tool can't read another tool's data, and nothing the model writes can leak a credential.

The ordering thing is harder and currently we don't do it. Per-tool permissions at best ban a combination, they can't say "internet then Slack is ok, the reverse isn't." DeepMind's CaMeL paper (arxiv.org/abs/2503.18813) is the best take I know on this, it tracks data flow between tool calls and enforces policy there. Still an open problem as far as I can tell.

Don’t know if anyone else is feeling this, but I’m getting a sense they’re gona have to go in to this layer. Not enough money to warrant the investment in the model only approach…

It's not reliable, and presenting it as-such shows a lack of understanding of basic security posture.

Don't take my word for it, watch the news in <6 months and we'll certainly see it get bypassed.

TBH I was a retool power user for years, but I feel like they completely missed the vibe code train.

It's so much more annoying to go drag boxes around and type out little JS snippits in every chart as opposed to just telling claude to make the chart.

We assume LLMs can always be fooled, so the judge is just one step of the verification process. The deterministic layers, per-tool db roles, read-only-by-default integrations, query timeouts, are the ones an admin can configure. The judge's rules aren't exposed to admins today. I like your idea of letting admins add their own rules or knowledge to the judge, we should add that.

It's funded by YC!

One of the core issue here is LLMs are probabilistic not deterministic, even with set of rules or context , llms are inherently built to make best guess, so my question is how you are ensuring that LLMs are following rules?

Maybe that's a hot take, but it's probably still safer than how things are often done in reality when employees want to "get something done" and sign up for random services, download their own software or other variants of shadow IT.

Have you looked at their latest product? You describe your app in a text box and the AI builds it, with all the enterprise goodies like RBAC baked in.

So is retool. :)

You're right, and we don't. The judge is best-effort screening not enforcement. Enforcement is deterministic with per-tool Postgres roles, proxy-injected creds, host allow-list, human approval on destructive writes. Those hold whether the judge is right or wrong.

Completely agree.

This posture is applicable while we ease out of what I'm calling the "golden era" (loose restrictions on access with limited consequence) but one of the reasons I am pedantic and bearish about solutions like this is that they too have a short lifespan that we can already estimate the expiration date of.

The difference is Retool still basically trusts whoever (or whatever) is building the app, we don't. The agent writing the code never sees a credential and each tool gets its own Postgres role. Even if it generates something dumb it physically can't touch data outside its scope.