Agents need guardrails, the real question is whether those live in the database or the framework. The 30% to 90% success rate jump from TypeScript types alone suggests the framework layer matters more than the schema layer for AI coding. Smart bet from a team that learned this the hard way scaling on Meteor for a decade.
Launch HN: Modelence (YC S25) – App Builder with TypeScript / MongoDB Framework
41–47 of 47 posts
Re: Launch HN: Modelence (YC S25) – App Builder with TypeScript / MongoDB Framework
#42By mentioning MongoDB you’re going to trigger so many people who haven’t informed themselves on MongoDB since 2014.
It works just fine as a production database. You can still have relationships and strict schemas… I just don’t understand the hate.
Re: Launch HN: Modelence (YC S25) – App Builder with TypeScript / MongoDB Framework
#43By mentioning MongoDB you’re going to trigger so many people who haven’t informed themselves on MongoDB since 2014. It works just fine as a production database. You can still have relationships and strict schemas… I just don’t understand the hate.
True, usually when I meet people who think so I always ask them what exactly went wrong. One time someone told me:
"we just let our frontend engineer build the whole backend and schema and it turned into a disaster and wasn't maintainable"
and I was like - so it's the database's fault? :)
Re: Launch HN: Modelence (YC S25) – App Builder with TypeScript / MongoDB Framework
#44By mentioning MongoDB you’re going to trigger so many people who haven’t informed themselves on MongoDB since 2014. It works just fine as a production database. You can still have relationships and strict schemas… I just don’t understand the hate.
My previous startup was running on MongoDB since 2014, and after 10 years, 1m+ users and hundreds of enterprise customers everything was just fine.
Re: Launch HN: Modelence (YC S25) – App Builder with TypeScript / MongoDB Framework
#45Agents need guardrails, the real question is whether those live in the database or the framework. The 30% to 90% success rate jump from TypeScript types alone suggests the framework layer matters more than the schema layer for AI coding. Smart bet from a team that learned this the hard way scaling on Meteor for a decade.
> The 30% to 90% success rate jump
Or it could be just measurement issues
Re: Launch HN: Modelence (YC S25) – App Builder with TypeScript / MongoDB Framework
#46When an experienced team with production users first feels ‘we can’t keep duct-taping this,’ what exact failure makes them reach for Modelence instead of just adding another managed service or framework?
There are often two peak points, one at the beginning when a team has built a frontend, then is looking to add things like authentication and realizes they have to bring in a separate backend (setting things up and connecting is the main friction). Later, the second realization is when you start needing deeper observability, and realize you have to bring in one more platform and set it up. Just adding another service…
> Just adding another service is easy, but making them work seamlessly together is much harder.
This argument in favor of PaaS makes a lot of sense to me. A PaaS vendor might say, "sure, you could set up your own observability layer, configure storage for it, troubleshoot that one service that can't connect to the API's endpoint, etc. Or you could just check the "observability" box on our dashboard and boom, there it is."
I'm currently at a company that really likes setting everything up from scratch. And the amount of time my team has spent building out a platform, as opposed to providing business value, is really sobering.
Re: Launch HN: Modelence (YC S25) – App Builder with TypeScript / MongoDB Framework
#47Earlier quoted context omitted.
There are often two peak points, one at the beginning when a team has built a frontend, then is looking to add things like authentication and realizes they have to bring in a separate backend (setting things up and connecting is the main friction). Later, the second realization is when you start needing deeper observability, and realize you have to bring in one more platform and set it up. Just adding another service…
> Just adding another service is easy, but making them work seamlessly together is much harder. This argument in favor of PaaS makes a lot of sense to me. A PaaS vendor might say, "sure, you could set up your own observability layer, configure storage for it, troubleshoot that one service that can't connect to the API's endpoint, etc. Or you could just check the "observability" box on our dashboard and boom, there it…
Yeah that same experience at our previous startup was one of the main reasons why we started Modelence. We got to a point where we had a dedicated 3-4 cloud platform engineers (out of the 20 engineers total) working full time only on things like observability, alerts, performance, cloud deployments, etc, none of which was specific to our product.
And when you take a step back and think for a moment, it just doesn't make sense that you have to run a whole separate team for something that's pretty much reusable across products.