Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- nice this is awesome, what i've been building internally for a while now. lovable-esque internal platform with an agentic chat building experience, preview window, our internal auth, internal standards, sandboxed agent devcontainers on k8s. Even down to the shared experience -- these are shared tools for everbody, team ownership structure, not individual. easily forkable, auto-genned product docs etc etc. Hope you can monetize it! Look into private endpoint connectivity for big corps that need the internal access but don't want to self host.by blyry
- 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.
- Very 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.by rgbrgb
- 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.
- How does this differ from retool?by jedberg
- It's funded by YC!by big_hacker
- 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.
by themanmaran - On the egress judge: an LLM reviewing connector calls inline is a probabilistic control sitting where a capability grant belongs. The operations that actually cause damage are largely enumerable: writes, deletes, and bulk reads of personal data. Those should be absent from the scoped token rather than present and then argued about by a judge with a nonzero false-negative rate under adversarial input, with the judge kept for the ambiguous long tail where enumeration genuinely fails. This is the WAF story again, request inspection in front of an app was a useful compensating control, and every team that mistook it for the boundary relearned that the boundary was the parameterized query and the database grant.
- I did build a very similar product putting emphasis on integrations and security. It was tough to churn anyone out from Replit, Lovable and then CC and Codex.
When I talked to Lovable team, they told me Lovable is used primarily for prototyping, not internal tools and they are having a rough time trying to change the use case.
Hope my experience helps!
by warthog - 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.
- Me and my co-founder are building something similar but it started out as a tool to help build Lovable style prototypes for your existing product. Think Product Managers building an idea without having to figure out how to install git, VS Code, 17 other tools and then try share a URL.
Initial talks with customers resonated more with the internal tooling idea though. It's flexible enough to support both.
We're earlier along than this product though so there's a fair few wrinkles in our product.
by aliclark - Awesome 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!!by Echo4309
- 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.
by IpV8 - Congratulations on the launch. I’m very bullish on this concept of allowing SMB’s and startups to roll their own software and internal tools. Many many moons ago I built an entire inventory tracking and CRM for a very small company in PHP (circa 2006). It ran the entire company with orders, customers, devices, and revenue. It was a monstrous app, and took forever. Today, could be build in a matter of days and much better.
Along the same lines. I got so fed up with Quickbooks self employed (god awful software and company) for my own business I wrote a replacement using Cursor. It tracks expenses (categorizing each in proper IRS categories) and estimating quarterly taxes. Uses Plaid to pull in business bank accounts and credit cards and has income and expense reports. It’s 100x better than Quickbooks.
by nodesocket - Thanks! Custom beats generic if building it takes days instead of months.
- > Any call the agent makes to an external connector is reviewed by an LLM judge to prevent dangerous operations.
A few basic questions: how reliable is this judge since it’s based on an LLM? What additional measures can an admin or someone with more technical knowledge take to tighten this further if needed? Are the rules in or used by this judge visible to the users or an admin?
by AnonHP - It's not safe or reliable, no matter how hard you try. Fundamentally, agents will try whatever they can to achieve the goal, as we've seen in many recent security incidents.
If determinism is important, as it is in many business use cases, use agents to build the tool, but don't let them run it.
I built a similar product around this exact idea: AI builds the workflow. Fixed rules run it.
by felixding - 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.by hudsongr
- 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.
by tcdent - Congratulations with your launch! I suspect the product market fit for tools like these will be huge. Especially for SMBs with just 10s of employees in the office, lacking the budget for SAP consultants. However I think the agent creating an app is adding unnecessary complexity. Users want answers or insight in data, why build an app for that if the agent can provide it directly?by iamniels
- 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.by hudsongr
- You can reuse the app indefinitely, for cheap, and predictably. I would say these are huge advantages.by joelthelion
- I’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 connectors. Nice job!by dchuk
- 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?by hudsongr
- I 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!by wseadowntown
- 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.by hudsongr