Español · PeopleWorks Services LLC
A company should not have to rewrite its software every time the technology changes. Modelador Studio takes the formal model of a business — its entities, its rules, its processes — and generates the entire application. When the model changes, the application changes.
<!-- el argumento de un servicio de impresión -->
<ArgumentoM Nombre="pt_PlantillaReporte">
<Alias>Formulario</Alias>
<Ref.Rol.Dominio>ReportTemplate
<FormulaString>
SubProcess = "E" AND
(ActivarMICR = "S" AND Process = "TN")
</FormulaString>Enterprise applications, running right now. You can walk into any of them — the one marked “per-agent security” shows the model’s security: each user sees only what their profile declares. The gym one had no database: the application creates its own from the model, with sample data.
How it works
There is no team per application and no codebase per application. There is a formal model of the business, a tool that reads it, and the entire application coming out the other side.
The story
Five steps. Scroll slowly: the drawing on the right builds with you, in the same order the generator works. Nothing is drawn that does not come from the model.
01 · The model
Classes, relationships, services and rules, written in a formal model (Integranova). It is the only asset: the code that comes out of it is disposable.
200 classes · 540 relationships · Payroll02 · The reading
Each class is matched to its table: keys, types, columns and relationships in their real order. When model and database disagree, the generator says so; it does not guess.
the model declares · the table confirms03 · The Presentation Model
Lists, detail views, forms, tabs and actions come from a manifest per class: which columns, in which order, which button each screen offers. The surface obeys the pattern.
the pattern declares · the surface obeys04 · The emission
Domain, database, API, web screens, desktop and reports. Thousands of files nobody types, rewritten in full every time the model changes.
70,077 lines of generator · 964 reports05 · The living application
Every release carries its stamp at the foot of each screen. Before it goes out, a set of gates checks what was published, not what was promised: the applications in production, open at the top of this page. And when the model changes, the application changes.
a stamp at the foot of every screenThe difference
These applications are not mock-ups: they reproduce a real municipal system, in production, with its reports, its business rules and its permissions. And their fidelity is not our opinion — it is measured against the original system, screen by screen.
Why it matters
The real cost of enterprise software is not writing it: it is rewriting it. Every platform change forces you to rediscover business rules nobody documented, rules that live only in the old code.
If those rules live in a formal model, the code becomes just another output — like a report. It is regenerated. It is thrown away. It is rebuilt on another technology without asking the business again how it worked.
“Whatever you fix on one screen has to be on all of them.”
— the rule that governs every correction in this generator
The surfaces
What gets modelled is the business: its classes, its rules and the screens it declares. Which technology paints them is the emitter’s decision, not the model’s.
That is why the same model writes the web application and the desktop one today. Measured field by field on a record with more than a hundred fields: the same ones on the web and on the desktop, because both read the same declaration.
Web · Blazor
What is published above.
Desktop · Windows Forms
Generated with every release. It talks to the same API: what is fixed on the server reaches it without regenerating.
DevExpress and React
Both emitters are written. They do not yet paint from the same declaration as the other two. That work is pending, and we say it as it is.
Changing the surface means writing another emitter. The business is not written again.
Do you have an output to another technology in mind? We can evaluate with you whether to bring it into the Modelador.
We do not tell you we will build it: we look together at whether it is feasible. Write to us →
The 2026 question
It is the first thing we get asked, and the answer is not “AI does not work”. We use it every day, and Modelador Studio itself carries it inside: you talk to it and build the model by conversation. The answer is more uncomfortable than that.
AI writes code. The Modelador emits a system. They are not the same piece. Ask an AI for the 174 lists of a payroll and it will give you 174 plausible screens. Ask again and it will give you 174 different ones. And neither time can it tell you whether they are the right ones, because there is nothing to check them against: the truth was in the head of whoever wrote the prompt.
In the Modelador the truth is in the model. Every screen comes from something declared that can be read — and that is why it can be measured: 173 of 174 lists match the original system, column by column. That figure does not exist in an AI-only workflow. Not because it turns out badly, but because there is nothing to measure it against.
And then there is the following Tuesday, which is where the money actually goes.
So where does AI come in? Where the bottleneck is human judgement: understanding the business and writing the model. That is where Modelador Studio carries it inside and genuinely helps. What we do not delegate to it is the one question that governs everything else:
“Does the model say so, or are we making it up?”
— the question behind every line of this generator
The tool
The ones above were not programmed one by one. They come from a model, and from a tool that reads it and emits the entire system — domain, database, services, screens and reports. That tool is Modelador Studio, and it is delivered too.
It installs on your machine, not on ours. Your company’s model — usually the most valuable thing you own, because that is where the business rules nobody documented live — never leaves it: it does not travel over the internet, it is not stored on a server of ours, and we do not see it.
Delivery is personal: we send you the link, the password and a one-page installation guide. We would rather walk you through the first start-up than leave a download button lying around.
Request Modelador Studio Windows · .NET 10 · SQL Server — runs on your machine
What we learnt
The generator reads the model to build the application, and for that it only needs to keep what the application uses. Writing it is something else: it has to produce everything the Integranova Modeler expects, in its order and in its shape. We asked the Studio, which already read whole models, to write a large one from what it had understood. The first time, the Modeler did not even open it.
We measured it against the real Modeler, not against our own tests. A day and a half later, the Studio writes each model from its own domain and the result is the same file: tag by tag, in the same order, with the diagrams where the modeller left them.
And the foundation came out ahead, which is what matters most to us: writing well meant reading better. Things the reader was quietly dropping came to light, and so did mistakes of ours — such as writing every creation service as internal, when in real models they are not. Those reading improvements stay in the generator, and with them the applications it produces.
What it already does
This is not an AI of ours inside our product. It is your Claude — your terminal, your subscription, your session — talking to the Studio through a bridge of 93 tools: 44 loaded at startup and the rest, by groups, when they are needed. Ask it for a class and the class appears; ask for the diagram and the diagram moves on the screen you are looking at.
An entire model has already been built by talking to it, from nothing. And because the one
doing the work is the claude on your machine, there is no AI bill of ours in the
middle and no model of yours travelling to a service of ours: the bridge lives on your
computer, just like the Studio.
What this page announced was «what is coming»: a named tool for every corner of the Studio — the Design Kit, the reports, the suites, the history —, any panel opened just by asking, and a terminal that checks what it writes before handing it to the Modeler. It is all done: the pocket judge is the modelador_vara_forma tool, and renaming a class is no longer the chat's alone: the terminal does it the same way, modelador_rename_class.
Tool by tool
Each tool is one thing your Claude knows how to do in the Studio: read a class, add an attribute, generate the app, open a panel. They used to load all at once. Now it starts with the core and, when the conversation asks for something else — the history, the reports, the Design Kit —, it switches that group on while running and uses it on the next turn, with no restart. Watch the trace; then touch any dot.
Touch a dot in the drawing — or a tool in the list — and it tells you what it does. Touch a group to switch it on.
Always loaded: reading and editing the model, its versions, the requirements, the app, the screen and the passage.
Renaming a class, and removing what nobody uses — attributes and services — with the safe removal: if something uses it, it refuses and says what.
Manual versions, work sessions, changes, notes, statistics, conversations, exports and versions as files.
Deep validation, the pocket judge, the XML, importing and exporting OOM files, the preview, downloading the app and knowledge packs.
Crystal reports and their files, hand-written code, documents, suites, release catalogue, reverse engineering and search.
The Design Kits: view them, create them, derive them from screenshots, tune their tokens and their images.
Opening panels and selecting pieces inside the Studio desktop. It only exists there.
No match.
The intelligence we recommend
The Studio's terminal is Claude: it reads the model, drives the tools and writes alongside you. A good part of this project is built working with Claude, and it is the artificial intelligence we recommend without hesitation. If you have not tried it or do not have it, these are its official pages to get started.
Modelador Studio and PeopleWorks Services LLC have no relationship or affiliation with Anthropic: we recommend it because, for us, Claude is the best artificial intelligence to work with. Claude and Anthropic are trademarks of Anthropic, PBC.
How we work
The applications above did not come out of a single prompt. Every change arrived the way the person using the system would say it — a sentence, a test report, a question about the model —, was read against the business rules already written down, was worked on by several AI models under written orders, and a person decided what was published.
01 · It arrives in your words
A sentence about something that annoys you every week. Not a specification, not a form.
02 · It is read against your rules
A brain that already knows your system answers it. That brain reads: it writes nothing and runs nothing.
03 · A person decides
Nothing is published without someone saying yes. And what is published carries its stamp at the foot of every screen.
You write the model, with your own terminal, on your own machine. A person decides what is published. The AI works between the two.
Contact
Write to us and we will show you the whole system: the model, the generator and the applications running.