You use a static typed language for guardrails but then you throw out the guardrails of a database schema? Seems like those two decisions are directly at odds.
Without a db schema, you still have to worry about migrating data at runtime or otherwise. Removing the schema just shifts the pain doesn’t remove it, in my experience.
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.
If you take your idea and add some web ui to manage the creation of apps and connect the pieces, I believe that there's great potential!
A couple years back I had a similar idea, but with a postgres+deno, and using .md files as the spec that generated the code https://github.com/lfarroco/verbo-lang
I think that in the future we might have specialized agents that operate under a specific opinionated tech stack. Like having one that is specialized in creating cli apps, another one for react+django+whatever, etc.
We do have the UI / dashboards, built into the platform - and it's actually one of the most valuable pieces. It's in the second half of the demo video!
And great point - while we're focusing on full-stack web apps, I believe the same problem exists for other domains / stacks and there will most likely be more players focusing on these as well.
You eliminate the schema management problem by not having a schema at all? Also, what do you mean schema management problem? I have never had an issue with that when using LLMs.
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.
I've run into schema issues specifically with things like supabase: the huge benefit to supase is really fast and effortless prototyping. But after that actually maintaining your app becomes really hard and you pay the tax back over time.
In this regard, once past prototyping, i agree i've never had issues with LLMs running into schema problems, given they're doing a full feature, they're in line with how things need to change across the app.
LLMs do great at inspecting tables via Rails models and db adapters that can run sql commands to inspect all schema.
That makes sense, and we've been seeing the same. But in our case, instead of having the LLM inspect an external system, TypeScript is the source of truth for both the schema and everything else, it's all code-defined, so it automatically both catches type mismatch and also makes it instantly readable both to developers and agents.
I think this actually makes a lot of sense. How do you automate transitions? Do you generate code to map old data to the latest format, or do you actually migrate the data?
A lot of this is still work in progress, but the key idea is that the framework and the cloud environment have to work together for this, because what you have in the current version of the code has to be compared with what the environment has before the deployment.
We don't automatically generate migration code - there's a set of structured mapping / guardrails, so for example if you add a new field without marking it as optional, you should get a warning/error when deploying it on an environment with existing data that has old records without that field set.
Modelence also has built-in support for user-defined migration scripts for more complex cases, but in these simpler cases we will be adding easy mappings with existing patterns, for example "set the field to X as the default value for all existing data".
Our focus here is the guardrails rather than the migration itself - LLMs today (especially Opus) are smart enough to figure out how to do the migration, but the guardrails make sure they don't miss it under any circumstances.
Agree, as for the JS/TS lock-in, we could have applied a similar approach with other languages too, but we intentionally chose to focus on one single stack to create a seamless end-to-end experience instead of providing a generic solution for multiple stacks, because a lot of the problems we're solving are different based on what stack you choose.
Yup, the way you interact with MongoDB collections in Modelence is via Store, which has a Zod-compatible schema, enforced at build-time and pre-deployment, instead of runtime (since at that point it's too late).
Maintaining a codebase with mongodb db is already hard enough considering 99% of the time you need a relational db. It always end up as a mess.
But letting an llm doing this as well, ouch. I fear for the maintainability of the codebase in the long term.
Both are hard for complex apps regardless, which is why we’re making sure that the framework has all the necessary guardrails to prevent devs from using it incorrectly.
Relational dbs just have more built-in guardrails, but in our case we prefer to have the same guardrails in the framework.
I like this take on the AI app builder hype. Most tools focus on generating an initial UI but are no help with 'seams' like auth and database migrations. Using MongoDB’s flexible schema as the backbone is a smart move for agents that usually hallucinate SQL relations. Will cool to see how the built-in observability handles production incidents.
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.
When 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 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.
The TypeScript + MongoDB combination for AI coding is a smart architectural choice. I've found that schema-less databases reduce the class of errors agents struggle with most - the migration/schema drift issues that require understanding of state over time.
Question: How are you handling the built-in auth when users want to extend it? For example, adding OAuth providers that aren't pre-configured, or custom claims/roles logic. Is this something the framework supports as extension points, or would users need to fork/modify core auth code?
The Claude Agent SDK integration is interesting - have you found specific prompting patterns that work better for TypeScript generation vs other languages? Curious if the type system actually helps agents self-correct as expected.
- 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.
How does your framework compares to Meteor.js? I see similarities in the problems being solved, and the tech stack being used. Do you have examples of the idiomatic way of client/server communication in Modelence?
I think the line between the framework and the AI code generation tool is blurry.
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.
Have you checked out MainMVP (https://www.mainmvp.com) yet? It is completely stack-agnostic and gives you complete freedom in choosing it. You can also use your own keys (BYOK).
We're maintaining a waiting list while we validate GDPR metrics with pilot companies (we're in Germany).
Why did you choose to be strict with the stack instead of opening it up to meet user needs?
While talking to companies and users we found out that prescribing a stack comes with more speed, but hinders progress afterwards (many Lovable users face this issue).
This is why we opened it up completely. Users must manage the backend themselves, but the project is more sustainable (and without lock-in).
The reason why we didn't build a generic platform instead is because everyone already has access to Cursor and Claude Code for building free form applications, and each stack is uniquely different in its challenges. We're picking a particular stack so that the integration between all pieces can be seamless, reliable and pre-built, rather than AI connecting everything from scratch.
Totally agree on Claude's generic approach, minus the deploy/hosting hassle.
That's why I personally really appreciate any solution offering different paths to the same goal: shortening that idea-to-MVP gap even for non-devs. Excited to hear more from you and your team!
To confirm I have the option to run essentially the whole stack on my own in my own hardware if I so choose? That's the ultimate unlock of Open Source trust and no lock-in. Makes it much easier for me to adopt you if you have that
Yes - since the framework itself is open-source, you are free to take it and run anywhere you'd like. Of course, the experience is much better if you run on Modelence Cloud since it's zero config and also gives you the dashboards / UI to manage everything out of the box. But ultimately there is no lock-in whatsoever, you could even fork the framework repo and modify it as you wish.
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?
You use a static typed language for guardrails but then you throw out the guardrails of a database schema? Seems like those two decisions are directly at odds.
Without a db schema, you still have to worry about migrating data at runtime or otherwise. Removing the schema just shifts the pain doesn’t remove it, in my experience.
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.
If you take your idea and add some web ui to manage the creation of apps and connect the pieces, I believe that there's great potential!
A couple years back I had a similar idea, but with a postgres+deno, and using .md files as the spec that generated the code https://github.com/lfarroco/verbo-lang
I think that in the future we might have specialized agents that operate under a specific opinionated tech stack. Like having one that is specialized in creating cli apps, another one for react+django+whatever, etc.
We do have the UI / dashboards, built into the platform - and it's actually one of the most valuable pieces. It's in the second half of the demo video!
And great point - while we're focusing on full-stack web apps, I believe the same problem exists for other domains / stacks and there will most likely be more players focusing on these as well.
You eliminate the schema management problem by not having a schema at all? Also, what do you mean schema management problem? I have never had an issue with that when using LLMs.
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.
I've run into schema issues specifically with things like supabase: the huge benefit to supase is really fast and effortless prototyping. But after that actually maintaining your app becomes really hard and you pay the tax back over time.
In this regard, once past prototyping, i agree i've never had issues with LLMs running into schema problems, given they're doing a full feature, they're in line with how things need to change across the app.
LLMs do great at inspecting tables via Rails models and db adapters that can run sql commands to inspect all schema.
That makes sense, and we've been seeing the same. But in our case, instead of having the LLM inspect an external system, TypeScript is the source of truth for both the schema and everything else, it's all code-defined, so it automatically both catches type mismatch and also makes it instantly readable both to developers and agents.
I think this actually makes a lot of sense. How do you automate transitions? Do you generate code to map old data to the latest format, or do you actually migrate the data?
A lot of this is still work in progress, but the key idea is that the framework and the cloud environment have to work together for this, because what you have in the current version of the code has to be compared with what the environment has before the deployment.
We don't automatically generate migration code - there's a set of structured mapping / guardrails, so for example if you add a new field without marking it as optional, you should get a warning/error when deploying it on an environment with existing data that has old records without that field set.
Modelence also has built-in support for user-defined migration scripts for more complex cases, but in these simpler cases we will be adding easy mappings with existing patterns, for example "set the field to X as the default value for all existing data".
Our focus here is the guardrails rather than the migration itself - LLMs today (especially Opus) are smart enough to figure out how to do the migration, but the guardrails make sure they don't miss it under any circumstances.
good point, single type source is very appealing and LLMs are so good with TS because of those type interfaces.
only downside is forced js ecosystem x_X
Agree, as for the JS/TS lock-in, we could have applied a similar approach with other languages too, but we intentionally chose to focus on one single stack to create a seamless end-to-end experience instead of providing a generic solution for multiple stacks, because a lot of the problems we're solving are different based on what stack you choose.
They seem to have a schema solution from their docs: https://docs.modelence.com/stores
Yup, the way you interact with MongoDB collections in Modelence is via Store, which has a Zod-compatible schema, enforced at build-time and pre-deployment, instead of runtime (since at that point it's too late).
Maintaining a codebase with mongodb db is already hard enough considering 99% of the time you need a relational db. It always end up as a mess. But letting an llm doing this as well, ouch. I fear for the maintainability of the codebase in the long term.
Both are hard for complex apps regardless, which is why we’re making sure that the framework has all the necessary guardrails to prevent devs from using it incorrectly.
Relational dbs just have more built-in guardrails, but in our case we prefer to have the same guardrails in the framework.
I like this take on the AI app builder hype. Most tools focus on generating an initial UI but are no help with 'seams' like auth and database migrations. Using MongoDB’s flexible schema as the backbone is a smart move for agents that usually hallucinate SQL relations. Will cool to see how the built-in observability handles production incidents.
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.
When 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 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.
The TypeScript + MongoDB combination for AI coding is a smart architectural choice. I've found that schema-less databases reduce the class of errors agents struggle with most - the migration/schema drift issues that require understanding of state over time.
Question: How are you handling the built-in auth when users want to extend it? For example, adding OAuth providers that aren't pre-configured, or custom claims/roles logic. Is this something the framework supports as extension points, or would users need to fork/modify core auth code?
The Claude Agent SDK integration is interesting - have you found specific prompting patterns that work better for TypeScript generation vs other languages? Curious if the type system actually helps agents self-correct as expected.
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.
How does your framework compares to Meteor.js? I see similarities in the problems being solved, and the tech stack being used. Do you have examples of the idiomatic way of client/server communication in Modelence?
I think the line between the framework and the AI code generation tool is blurry.
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.
Have you checked out MainMVP (https://www.mainmvp.com) yet? It is completely stack-agnostic and gives you complete freedom in choosing it. You can also use your own keys (BYOK).
Nope, but it seems like it's still on a waitlist - are you planning on launching soon?
We're maintaining a waiting list while we validate GDPR metrics with pilot companies (we're in Germany).
Why did you choose to be strict with the stack instead of opening it up to meet user needs?
While talking to companies and users we found out that prescribing a stack comes with more speed, but hinders progress afterwards (many Lovable users face this issue).
This is why we opened it up completely. Users must manage the backend themselves, but the project is more sustainable (and without lock-in).
The reason why we didn't build a generic platform instead is because everyone already has access to Cursor and Claude Code for building free form applications, and each stack is uniquely different in its challenges. We're picking a particular stack so that the integration between all pieces can be seamless, reliable and pre-built, rather than AI connecting everything from scratch.
Totally agree on Claude's generic approach, minus the deploy/hosting hassle.
That's why I personally really appreciate any solution offering different paths to the same goal: shortening that idea-to-MVP gap even for non-devs. Excited to hear more from you and your team!
To confirm I have the option to run essentially the whole stack on my own in my own hardware if I so choose? That's the ultimate unlock of Open Source trust and no lock-in. Makes it much easier for me to adopt you if you have that
Yes - since the framework itself is open-source, you are free to take it and run anywhere you'd like. Of course, the experience is much better if you run on Modelence Cloud since it's zero config and also gives you the dashboards / UI to manage everything out of the box. But ultimately there is no lock-in whatsoever, you could even fork the framework repo and modify it as you wish.
sick
Not keen on your data store choice. Mongodb introduces a lot of other problems. The problem with schemas is an easier one to solve imo
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?
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.
What do you mean with "it introduces a lot of other problems"?