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