Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

11–20 of 47 posts

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

#11

Post by koakuma-chan »

artahian wrote: post #8
apsurd wrote: post #7

Earlier quoted context omitted.

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…

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.

I think this actually makes a lot of sense. How do you automate transitions? Do you generate code to map old data to the latest format, or do you actually migrate the data?

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

#12

Post by artahian »

gr4vityWall wrote: post #9

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.

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.

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

#13

Post by apsurd »

artahian wrote: post #8
apsurd wrote: post #7

Earlier quoted context omitted.

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…

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.

good point, single type source is very appealing and LLMs are so good with TS because of those type interfaces.

only downside is forced js ecosystem x_X

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

#14

Post by artahian »

chaostheory wrote: post #6

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

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?

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

#15

Post by artahian »

koakuma-chan wrote: post #11
artahian wrote: post #8

Earlier quoted context omitted.

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.

I think this actually makes a lot of sense. How do you automate transitions? Do you generate code to map old data to the latest format, or do you actually migrate the data?

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.

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

#16

Post by artahian »

gr4vityWall wrote: post #10
koakuma-chan wrote: post #4

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.

They seem to have a schema solution from their docs: https://docs.modelence.com/stores

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

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

#17

Post by jpartridge »

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.

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

#18

Post by artahian »

jpartridge wrote: post #17

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.

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.

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

#20

Post by artahian »

GeorgyM wrote: post #19

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?

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.

Post reply on HN