Quick Start

Quick Start Core Concepts Advanced Concepts

Genatron is made possible by the amazing natural language understanding present in large language models. This means that to build applications you only need to communicate your requirements, primarily the functional requirements, in plain language. Your focus can remain solely on the data that needs to be collected to solve your problem or gain insights.

This quick start guide assumes that you are ready to enter actual requirements after signing in and creating a new application.

For background we'll assume a generic physical asset that's being managed.

The simplest version of the requirements could be a paragraph outlining all of the fields needed.

Build an application for tracking assets. For every asset we would like fields for: the name of the asset (required), a full description, cost, price, status (select from Purchased, Requires Assembly, Active, Inactive), next maintenance date.

This is all it would take to create a simple application with the ability to create, edit, view and delete the asset records. Genatron is able to understand all of the entities, their properties and their relationship to other entities. In the example above there is only one entity (an asset) with various fields.

One thing to note from this example is that we can add additional text hinting at everything from the field type, validation, options and much more.

To build on this example let's add another entity for manufacturers.

Build an application for tracking assets. For every asset we would like fields for: the asset manufacturer (drop-down options from the list of manufacturers), the name of the asset (required), a full description, cost, price, status (select from Purchased, Requires Assembly, Active, Inactive), next maintenance date.

We need to be able to manage a list of manufacturers. Every manufacturer should have a name field that's required and up to 50 characters long.

There are now two entities and the relationship between the two will be inferred from the assignment of a manufacturer, which will come from the list of manufacturers managed in the system.

There is a great deal of flexibility in terms of how requirements can be written, after all it's in plain human language. Our example can be written in a more legible way like the outline below:

Below are the requirements for the asset tracking application needed.

** Assets **
For every asset we need to manage:
- Manufacturer: Drop-down options from the list of manufacturers
- Name (required)
- Description: A full description of the asset with support for formatted text (up to 5000 chars long)
- Cost
- Price
- Status
- Next Maintenance Date
- Manufacture Date:  Cannot be in the future.

** Manufacturers **
Every manufacturer should have a name field that is required and can be up to 50 characters long.

Here it's easier to see the fields associated with the entity. This also demonstrates a mix of styles (bulleted list for Assets and more formally written requirements statement for Manufacturers).

There is also an additional field for the Manufacture Date with a max date of the current date (disallowing future dates)

As can be seen requirements can range from vague and informal to formal and more detailed as requirements specifications. Everything from user stories to ISO/IEC/IEEE 29148:2018 is supported. The possibilities are endless.

Remember that you can always iterate to add more to your application after reviewing or getting feedback so there's no pressure to try to include everything in the first version.

Learn more about the various field types that are supported and other core concepts next. Later you'll see how to apply roles and get information out using reports and dashboard widgets.

Core Concepts

Still need help? Contact Us