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

Hi all, Aram and Eduard here - co-founders of Modelence (https://modelence.com). After spending years on scaling our previous startup’s platform, we built an open-source full-stack TypeScript + MongoDB framework to stop solving the same auth / database / API / cron job implementations every time we created an app, and we didn’t like the idea of using multiple managed platforms for each of these to run our apps either.

(Here’s our prior Show HN post for reference: https://news.ycombinator.com/item?id=44902227)

At the same time, we were excited by the whole AI app builder boom and realized that the real challenge there is the platform rather than the tool itself. Now we’re making Modelence the first full-stack framework that’s built for coding agents and humans alike:

- TypeScript is already great for AI coding because it provides guardrails and catches many errors at build time, so agents can auto-correct

- MongoDB eliminates the schema management problem for agents, which is where they fail the most often otherwise (+ works great with TS/Node.js)

- Built-in auth, database, cron jobs and else that just works together out of the box means agents only focus on your product logic and don’t fail at trying to set these things up (+ less tokens spent on boilerplate).

You can now try the Modelence app builder (based on Claude Agent SDK) by just typing a prompt on our landing page ( https://modelence.com ) - watch a demo video here: https://youtu.be/BPsYvj_nGuE

Then you can check it out locally and continue working in your own IDE, while still using Modelence Cloud as your backend, with a dev cloud environment, and later deploy and run on Modelence Cloud with built-in observability around every operation running in your app.

We’re also going to add a built-in DevOps agent that lives in the same cloud, knows the framework end-to-end, and will use all this observability data to act on errors, alerts, and incidents - closing the loop, because running in production is much harder than just building.

We launched the app builder as a quick start for developers, to demonstrate the framework and Modelence Cloud without having to manually read docs and follow the steps to set up a new app. Our main focus is still the platform itself, since we believe the real challenge in AI coding is the framework and the platform rather than the builder tool itself.

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

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.