modelARch
Stop fixing code in Lovable. Build scalable apps instead.
44 followers
Stop fixing code in Lovable. Build scalable apps instead.
44 followers
modelARch turns your requirements into an evolving model that becomes the source of truth. Preview and refine your entire application before generating it deterministically. When things change, evolve the model, dispose of the code, and regenerate, at no additional code cost.
Hey Product Hunt 👋
AI app builders made it incredibly fast to start building software.
But as applications grow, so do the roles, permissions, workflows, business rules, and dependencies between them.
With prompt-driven development, every change can mean another generation, another correction, and another attempt to keep everything consistent.
We think the problem is simple: you shouldn't have to keep fixing generated code. You should change the system that defines it.
That's why we built modelARch.
🧠 Model first. Generate later.
With modelARch, AI helps you turn natural-language requirements into an explicit model of your entire application: data, relationships, roles, permissions, workflows, rules, and behavior.
Something changes?
Change the model, dispose of the code, and regenerate it.
The model remains the source of truth.
👀 Build the whole app before buying the code
You can model your application from end to end, preview it across desktop, tablet, and mobile, change it, and validate it before purchasing the generated code.
Your subscription gives you access to the modeling environment.
No credits. No pay-per-prompt.
Keep refining until you're satisfied.
Only then do you pay for the code.
⚙️ Then modelARch generates deterministically
AI helps interpret what you want to build.
But the final application isn't generated probabilistically from another prompt.
Once the model is ready, modelARch generates the full-stack application deterministically from that model.
AI interprets. The model defines. modelARch generates.
🔄 Evolve the model. Regenerate the software.
This is the bigger idea behind modelARch.
We don't think generated code should be something you continuously maintain. The model should be the durable artifact. The code should be disposable.
As your business changes, you evolve the model. The existing code can be discarded, and the entire application regenerated deterministically from its new state.
No patches. No accumulated prompt history. No trying to keep generated code in sync with what the business is supposed to do.
We maintain evolutionary models, not generated code.
The model evolves. The code is disposable. The software is regenerative.
And regeneration isn't another purchase: once you've generated your application, you can keep evolving the model and regenerating the software without paying for the code again.
🎯 Who is it for?
Founders, developers, agencies, and software teams building applications that are becoming too complex for endless prompting — especially systems with interconnected roles, permissions, workflows, and business rules.
If you've been building with Lovable, Base44, Bolt, or similar tools, we're particularly interested in hearing what you think.
Maybe the next step after vibe coding isn't better code generation. Maybe it's making generated code disposable.
@martin_herran Big shoutout for creating a subscription model with no pay-per-prompt friction, giving builders space to iterate until the model is 100% correct builds so much trust. congrats🙌
@priya_kushwaha1 Thanks so much, Priya!
You’ve captured exactly what we’re aiming for here. We really don’t want people thinking about credits or prompt costs while they’re trying to understand and refine their business. The model should be something you can iterate on freely until you’re confident it represents what you actually need.
Thanks again for the support and for highlighting this! 🙌
the model as the source of truth i buy. the part i keep getting stuck on with this shape of tool is the data.
disposing of the code and regenerating is clean because code has no state. the database does. once there are real rows in it, a change that is one line in the model is a migration with customer data in it, and that is the bit that actually costs you the day. does the model own the migration too, or does regenerate assume a schema you are willing to rebuild?
related, and it is the thing i would put on the page: what happens when somebody has to patch something at 2am. if the answer is you never hand edit generated code, you only change the model and regenerate, that is a real and defensible position. it is just worth saying out loud, because it is the constraint people will feel first.
congrats on shipping it.
@jernej_jan_kocica Hi Jernej! First of all, thank you so much for taking the time to really dig into what we’re proposing and bring these questions into the discussion. These are exactly the kind of thoughtful comments that help us challenge the idea, clarify it, and ultimately improve the product. We really appreciate it.
On the data side, I think it’s actually simpler than it may seem. Persistent data isn’t regenerated; it’s migrated, just like in traditional software. A change in the model produces the corresponding schema/data migration, which is applied before the regenerated application takes over. For transformations that require business intent, that intent needs to be captured as part of the model change.
On the 2 AM patch point, though, there’s another important difference. We’re not generating arbitrary code with an LLM every time. The application is generated deterministically through a tested generation mechanism. If a construct is generated correctly once, the same construct is generated correctly every time. So the goal isn’t really to make generated code easy to patch at 2 AM. It’s to remove a large class of code regressions that cause those 2 AM patches in the first place.
And yes: if the business behavior itself needs to change, you change the model, regenerate, test and deploy (not patch the generated code).
I hope this answer is helpful and gives a bit more clarity on how we think about these cases. Again, thank you so much for the support and, especially, for the thoughtful feedback!
@martin_herran that answers it, and the deterministic generator is a better answer than i expected. if a construct is proven once you do get to trust it everywhere, that is real and it is not what most of these tools can say.
the part i would still push on is that most 2am pages are not code regressions. it is a third party api that quietly changed its behaviour, or one customer whose data takes a path nobody modelled, or a query that was fine at 10k rows and is not at 10m. in all three the model is correct and the system is still down. by your own rule you cannot patch the generated code, so what is the escape hatch, and how long does change the model, regenerate, test, deploy take at 3am?
and on migrations, the ones that hurt are not the ones needing business intent, they are the ones that run for two hours against a live table. can the model express the shape of an online migration, backfill in batches, dual write, then cut over, or does it emit one migration and assume you can afford the lock?
@jernej_jan_kocica Thanks again, Jernej. I really appreciate this kind of pushback, these are exactly the kinds of real-world constraints and edge cases that make the discussion valuable and help us explain the modelARch philosophy more precisely.
On the escape hatch: the generated code is yours. modelARch doesn’t lock you out of it, so if you’re facing an exceptional situation and the fastest way to restore production is to patch something manually, you absolutely can. The important distinction is that the code is editable, but the model remains authoritative.
In practice, though, for things like changing a permission rule or a piece of business logic, going through the model should normally be the faster path. You can describe the change to the modeler in a couple of minutes, and modelARch can regenerate the affected code, run the corresponding tests and deploy the new version through the same deterministic process.
There’s also a different case: an actual bug in the generated code. For that, modelARch has a built-in reporting system that immediately starts a fast resolution pipeline on our side. Since the generator is shared, fixing the underlying generation issue means fixing that class of problem at its source, rather than requiring each user to maintain their own patch.
And if an emergency patch is ever necessary, it should remain temporary: the permanent change needs to be reflected in the model, since the next regeneration may overwrite that patch.
Again, thank you for bringing these scenarios into the discussion. This kind of feedback is genuinely valuable to us.
@martin_herran that is the answer i was hoping for, and the honest one. code editable, model authoritative is a workable contract.
the line i would pull out of your own reply though is "the next regeneration may overwrite that patch". that is the quiet failure in this design. somebody patches at 3am, it works, and then nobody puts it back into the model because the fire is out and the person who did it is asleep. six weeks later someone regenerates for an unrelated reason and the fix silently disappears. no error, no test failure, just a bug that was already fixed once coming back.
you can close that cheaply though, because you are the one writing the file. hash it at generation time, and on the next regenerate compare before you write. if the hash moved, somebody edited it, so you either stop and make them confirm or you print the list of files you are about to overwrite. that turns a silent regression into a prompt.
the migration one is still the bit i would want on the page. not the ones needing business intent, the ones that run two hours against a live table. can the model say backfill in batches then cut over, or is that outside what it describes?
Building client apps for a living, the pressure point I'd worry about isn't the model being wrong, it's the client changing a permission rule at 4pm the day before a demo, with no time to properly evolve the model, regenerate, test and deploy. That's exactly when teams reach for a hand patch regardless of the tool's philosophy. Is there any sanctioned scoped exception for that, clearly marked as debt to fold back into the model later, or is the rule zero hand edits from day one, no exceptions?
@abdullah_javaid3 Hi Abdullah! First of all, thank you so much for taking the time to really think through the implications of the approach and bring such a practical scenario into the discussion. These are exactly the kinds of questions that help us clarify the philosophy behind modelARch and make the product stronger.
I think there are two important points here.
First, the generated code is yours. modelARch doesn’t lock you out of it, so if you’re in an exceptional situation and need to patch something manually, you absolutely can.
But the second point is probably more important: for something like changing a permission rule or a piece of business logic, going through the model should actually be the faster path.
You can describe the change to the modeler in a couple of minutes, and modelARch can regenerate the affected code, run the corresponding tests and deploy the new version through the same deterministic process. It’s designed to be very fast.
So yes, you can patch the code if you really need to, but in practice, the model should remain the fastest and safest path for making changes.
And if the problem is actually a bug in the generated code, that’s a different case: modelARch has a built-in reporting system that starts a fast resolution pipeline on our side, so the underlying generation issue can be fixed at its source.
Again, thank you for bringing this into the discussion. This kind of real-world feedback is incredibly valuable to us.
@martin_herran The fold-back-or-get-overwritten rule makes sense for a single patch. What about visibility before that point though: if three people each did a 2am fix on different days, is there any way to see that running list of outstanding hand patches at any time, or is the only signal the diff that shows up whenever someone finally regenerates?
Very interesting idea, reminds me of Rspec back in the rails days. The idea you can define your application as a spec and that is the human readable form. Then can change the code underneath knowing it is fully tested and behaves like you defined.
Would love to hear more
@michael_yagudaev Thanks Michael!
I think there’s definitely some conceptual lineage there. The distinction I’m trying to explore is that the model doesn’t only specify the behavior that the implementation must satisfy. It becomes the authoritative artifact from which the implementation itself can be deterministically regenerated.
So instead of "change the code underneath while keeping the spec green", the idea becomes "evolve the model and regenerate the code underneath".
That connection with RSpec/executable specifications is really interesting though. Thanks for bringing it up!
PicWish
the deterministic generation step to fastapi and react/ts is super interesting. how exactly is the explicit model stored physically to guarantee that 1:1 code mapping every single time?
@mohsinproduct Hi Mohsin! The storage layer itself isn’t what guarantees the mapping. The important property is that generation is reproducible from a stable application definition. We treat that as a core requirement and continuously verify it across runs.
RunEvr
@martin_herran This is a really interesting approach! I like the idea of keeping the model as the source of truth instead of letting the codebase become the thing you constantly have to maintain.
Good luck guys !
@adana Thanks so much, Adana!
That’s exactly the shift we’re trying to make: moving the source of truth away from the codebase and into an explicit model of the business. The code then becomes something we can generate, validate and regenerate whenever the model evolves, rather than something we need to continuously maintain by hand.
I like to call it Regenerative Software. It’s a new and still experimental paradigm that I’m trying to develop and consolidate. Hopefully, we’re onto something :)
I really appreciate you taking the time to understand the idea behind modelARch and for supporting us!