logoalt Hacker News

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

62 pointsby eduardpiyesterday at 4:03 PM34 commentsview on HN

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.


Comments

frozenlettucetoday at 12:22 AM

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.

koakuma-chanyesterday at 5:34 PM

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.

show 2 replies
joshribakoffyesterday at 10:08 PM

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.

show 1 reply
fd-codieryesterday at 11:39 PM

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.

show 1 reply
jpartridgeyesterday at 7:21 PM

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.

show 1 reply
GeorgyMyesterday at 7:59 PM

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?

show 1 reply
Soerensenyesterday at 4:39 PM

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.

show 1 reply
gr4vityWallyesterday at 6:32 PM

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.

show 1 reply
stoicsessionyesterday at 8:22 PM

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

show 1 reply
redwoodyesterday at 10:31 PM

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

jellyotsiroyesterday at 11:42 PM

sick

chaostheoryyesterday at 6:23 PM

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

show 3 replies