Hacker News: marinoseliades

New comment by marinoseliades in "Launch HN: Prized (YC S26) – Let non-engineer staff build secure internal tools"

marinoseliades — Thu, 30 Jul 2026 22:42:24 +0000

Thanks! Custom beats generic if building it takes days instead of months.

New comment by marinoseliades in "Launch HN: Prized (YC S26) – Let non-engineer staff build secure internal tools"

marinoseliades — Thu, 30 Jul 2026 22:38:37 +0000

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.

New comment by marinoseliades in "Launch HN: Prized (YC S26) – Let non-engineer staff build secure internal tools"

marinoseliades — Thu, 30 Jul 2026 22:35:34 +0000

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.

New comment by marinoseliades in "Launch HN: Prized (YC S26) – Let non-engineer staff build secure internal tools"

marinoseliades — Thu, 30 Jul 2026 22:32:15 +0000

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.

New comment by marinoseliades in "Launch HN: Prized (YC S26) – Let non-engineer staff build secure internal tools"

marinoseliades — Thu, 30 Jul 2026 22:29:04 +0000

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.

New comment by marinoseliades in "Launch HN: Prized (YC S26) – Let non-engineer staff build secure internal tools"

marinoseliades — Thu, 30 Jul 2026 22:21:55 +0000

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.

New comment by marinoseliades in "Launch HN: Prized (YC S26) – Let non-engineer staff build secure internal tools"

marinoseliades — Thu, 30 Jul 2026 22:05:06 +0000

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.

New comment by marinoseliades in "Launch HN: Prized (YC S26) – Let non-engineer staff build secure internal tools"

marinoseliades — Thu, 30 Jul 2026 19:44:41 +0000

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.

New comment by marinoseliades in "Launch HN: Prized (YC S26) – Let non-engineer staff build secure internal tools"

marinoseliades — Thu, 30 Jul 2026 15:18:21 +0000

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.

New comment by marinoseliades in "Launch HN: Prized (YC S26) – Let non-engineer staff build secure internal tools"

marinoseliades — Thu, 30 Jul 2026 15:10:19 +0000

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.

Launch HN: Prized (YC S26) – Let non-engineer staff build secure internal tools

marinoseliades — Thu, 30 Jul 2026 13:29:03 +0000

Hi HN, we're Marinos and Hudson, founders of Prized (https://prized.dev)! Prized lets non-engineer employees describe the internal tool they need and get a full-stack app, wired to their company’s data and deployed behind the company’s sign-in, without them ever juggling API keys or connectors.

Here's a demo: https://www.youtube.com/watch?v=730MuYOfZTY

The way Prized provides security is by limiting what the agent can reach at the network layer and by keeping credentials out of the sandbox entirely. The sandbox never holds any keys or connector secrets, it only uses scoped session tokens that are stored as opaque placeholders. The real values are swapped into the request headers on our egress proxy. When production data is connected, the sandbox's network policy is set to deny by default so the only path out is via the proxy. Any call the agent makes to an external connector is reviewed by an LLM judge to prevent dangerous operations.

Prized is meant for the internal workflows that start as notebooks or spreadsheets but never become real tools because engineering has more important things to work on. One customer’s data scientist pasted in his personal fraud-detection notebook with hardcoded thresholds and all. After a few prompts, it became a published risk console connected to the company’s data with those thresholds turned into UI controls. Earlier today, we got off a call with them and most of their company is using it.

To do this, you need to give people the freedom to build without having unaudited access to company systems. We allow admins to scope data to specific users or teams and data access is recorded in an audit log. Each tool is built with its own Postgres schema and role, with queries running via an authenticated SQL gateway as that role.

We think Prized sits between products like Lovable and Retool. Lovable makes it easy to generate and host software, but it isn’t designed around distribution with permissions. Retool generally assumes that a technical builder is creating an app for an end user.

Prized treats internal tools as shared objects. Anyone in the workspace can see what others have built, fork, and connect different data. For example, one customer’s marketing lead built a promotional analytics tool. A data scientist at the same company then forked it and added confidence intervals with the existing tool as a starting base. This way workspaces become libraries of tools that people can reuse.

We’re live and self-serve. Our free tier includes 2 tool builds/month and our Teams tier is $100/month. The Enterprise tier is custom and supports personalized features like on-prem deployment.

We're still working out the right boundary between control and freedom. If you've built internal tools before we'd appreciate your feedback!

Comments URL: https://news.ycombinator.com/item?id=49109721

Points: 63

# Comments: 44