Case · my own product

You define a field and the form is already there

Every company that hires me asks for the same system with a different form: different fields, different rules, a different screen. KUIDY-CORE is what I wrote to stop coding that form over and over: you define the modules and their fields from the interface, and a generic engine draws the screen, validates what you type and saves it.

What it looks like

A module is its fields and its records. At the top, the definition: name, key, type and whether it is required. Below, the data already loaded, with one column per field.

The Activos (assets) module with the list of its seven fields and, below it, the table of records
The demo's “Activos” (assets) module: seven fields of four different types, with its records below.

Adding a field means filling in three boxes. No migration, no deploy, not a line of code: the field is saved as a definition, and everything else comes from there.

The “Agregar campo” (add field) dialog, with a name, a JSON key, the date type and the required checkbox
The field is declared: its name, the key it travels under in the data, and its type.
New record form that already includes the field just created, as a date picker
And there it is in the form, with the right control and its validation. Records that already existed show a dash in the new column.

How it works inside

The idea is old and good: keep the definition apart from the data. Projects, modules and fields live in ordinary PostgreSQL tables, and the records live in a single table with a jsonb column and its GIN index. That way a field can be added without touching the database schema, and the metadata is still queryable like any other table.

What keeps this from turning into a mess is the validator that is built on the fly: a module's field definitions are turned into a validation schema at runtime, and the same rules run in the browser, to warn you while you type, and in the API, which is the one that decides. A number does not get in as text, a date has to look like a date and a dropdown only accepts its own options, without anyone having written that code for that particular field.

Passwords are stored with argon2id, the session is a seven-day JWT, and access is decided by membership in each project with four roles: owner, admin, member and viewer. A viewer who tries to write gets a no from the server, not from the interface.

Try it yourself

The demo is open and its data is made up. Sign in, open a module, create a field and look at the form: that is the whole product in half a minute.

The demo interface is in Spanish. Open the “Activos” (assets) module and click “Agregar campo” (add field).

What it is and what it is not

It is the engine I use to build custom internal systems without redoing the same work, and that is where its scope comes from: there are still no relations between modules, no reports and no import, and a field's type cannot be changed once it has been created. It is written that way on purpose: I would rather what is there be solid and what is missing be obvious than promise a whole platform and have it fall over in the first demo.

Does your team run its work out of spreadsheets?

That is where this pays off: turning that sheet into a system with permissions, validation and a record of who did what, without waiting three months or paying per seat.

Let's talk →