Launch HN: Modelence (YC S25) – App Builder with TypeScript / MongoDB Framework

MongoDB actually has built-in schema validation which can be enabled, we're just not using it at the moment because we haven't yet found a good use case where the TypeScript schema itself is not enough.

The schema in Modelence is defined in your code, and at the moment the only use case where it's not enough is if someone directly modifies the database data externally. We're not against having the native MongoDB schema as an extra enforcement, the only reason we haven't added it yet is because it requires extra work to carefully sync both. I believe at some point we'll add it as an extra layer to prevent corrupting the data by direct modifications.

We still have a schema definition in TypeScript, without it things would have been pretty wild actually. But we're doing it in the app layer - in the framework. The schema management idea is that we're adding guardrails around all schema changes, so if you change the type of an existing field, rename fields, etc, we're automating the transition so the new code doesn't just run on the same old data without any knowledge of past structure.

Most of the users we talked to had issues when they made changes like this in the schema with app builders, in any database regardless, where the management layer doesn't exist.

They seem to have a schema solution from their docs: https://docs.modelence.com/stores

Exactly, and most app builders have realized this and started adding things like built-in auth, cloud, etc, but I still think the right direction is starting with the platform itself and adding the app builder as just one facade for it, rather than it being the central piece.

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 is easy, but making them work seamlessly together is much harder. In this case the "failure" is that they realize they are spending way too much time to set things up to even see what's happening in their application in prod.

Great questions:

- For extending auth, currently the framework contribution is the main option, but we've intentionally made everything modular so we will be making it extensible with custom external packages as well (or even directly in your app without a package).

- Our system prompt actually doesn't have anything TypeScript specific (only Modelence specific instructions). But the typing system is literally a miracle - the success percentage from a single prompt went from about 30% to 90%+ just by adding the type checks for the agent. It is surprisingly good at self-correcting, to the point that even when it lacks context it ends up going into the framework code itself from node_modules to find the right usage.

We've been one of the very early Meteor users, since 2013 (our previous startup is featured on their landing page). After about 10 years of scaling on Meteor & Galaxy, we ended up moving Meteor into our own custom AWS cloud because of lack of observability.

As for the framework, we always wanted to have things like built-in config management, cron jobs, and better live data support (pub/sub was too rigid) - Meteor was actually a huge inspiration in creating Modelence.

The client/server communication in Modelence is somewhat similar to Meteor, for example: https://github.com/modelence/examples/blob/main/ai-chat/src/...

And then the client calls these via react-query useQuery/useMutation for which Modelence has an adapter.

Nope, but it seems like it's still on a waitlist - are you planning on launching soon?

Totally agree, schema issues are easily solved with solutions like drizzle or prisma.

I would never go full mongo considering how easy is now a days to have TypeScript first postgres.

Fair point, although we didn't choose MongoDB just because of schema handling. We've been using MongoDB in production since 2013, so it was a natural choice since we already know a lot more about it than any other database.

For the problems you're mentioning, what we've seen is that many people use it incorrectly, and we're building the framework in a way that prevents that in the app layer. But still curious about your experience - what are the biggest problems you've had in production MongoDB?

What do you mean with "it introduces a lot of other problems"?