artahian

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.

My previous startup was running on MongoDB since 2014, and after 10 years, 1m+ users and hundreds of enterprise customers everything was just fine.

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? :)

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.

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.

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.

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.

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.

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

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.

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.

We had this same challenge in our own app builder, we ended up creating an internal LLM proxy with per-sandbox virtual keys (which the proxy maps to the real key + calculates per-sandbox usage), so even if the sandbox leaks its key it doesn't impact anything else.

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.

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).

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.

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?

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.

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.

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.

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.

I agree - Postgres has been on the rise for the past years, but I think the reason for MongoDB going down in popularity is not reflective of its own progress - MongoDB has only been technically getting better and they’ve recently bought Voyage AI which is now bringing built-in embeddings with MongoDB Atlas vector search.

The previous startup I’ve co-founded has been running on MongoDB since 2014 and everything was great for over 10 years of using it as our main db, hosting over million users and large enterprise customers.

A lot of this is obviously subjective, but we’ve always found MongoDB’s flexibility work great for a startup’s constant db changes. And we also believe that the existence of “Supabase for MongoDB” will be a good reason for more people to use it.

Yup - it’s work in progress! We will be adding both shortly.

If you check our landing page, we have a section where we explain that a bit: https://modelence.com

One of the AI-native aspects is if you use the built-in AI SDK (https://github.com/modelence/modelence/tree/main/packages/ai), you get all your AI prompt runs in the built-in dashboard in Modelence Cloud and you can also connect your AI provider (e.g. OpenAI) in the dashboard without having to manually specify the key in the code or pass through environment variables.

But there's more we adding soon - vector search and embeddings that are built into your database / MongoDB documents.

Do you mean real-time data / live sync? It is actually the next thing we're going to release, so yes - it is definitely a core part. We took our inspiration from https://meteor.com and it had a big emphasis on live data which we're going to support in a more scalable way.

Thanks! We do have the auth components here - https://github.com/modelence/modelence/tree/main/packages/au...

Probably need to add screenshots also, but our own platform at https://cloud.modelence.com uses these built-in auth UI from Modelence and a lot of other things it is bootstrapped with.

Rails for Ruby is similar with the simplicity and structure (same idea here for TypeScript), but Modelence is more cloud-first focused and less of a pure framework.

v0 and lovable have way too much hype, I think what you're doing with stagewise (i.e. being dev-first instead of optimizing for non-developer users) is the real long term use of AI.