(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.
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.
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.
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.
It works just fine as a production database. You can still have relationships and strict schemas… I just don’t understand the hate.
"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? :)
Or it could be just measurement issues
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.
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.
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.
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.
This argument in favor of PaaS makes a lot of sense to me. A PaaS vendor might say, "sure, you could set up your own observability layer, configure storage for it, troubleshoot that one service that can't connect to the API's endpoint, etc. Or you could just check the "observability" box on our dashboard and boom, there it is."
I'm currently at a company that really likes setting everything up from scratch. And the amount of time my team has spent building out a platform, as opposed to providing business value, is really sobering.