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.
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.
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.
only downside is forced js ecosystem x_X
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.
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.
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).
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!
I think the line between the framework and the AI code generation tool is blurry.
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.
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?