Describe a dispatch tab in a sentence, get a working tab

The AI Builder in LiteTMS takes a plain sentence, such as "a fuel log with the vehicle, date, litres, price and a photo of the receipt", and generates a working tab: the fields, a list of saved entries, and a searchable table your team can use the same afternoon. You get a preview first, you can edit every field by hand afterwards, and each save is a version you can roll back to.

It is not magic and it does not write code. It builds a layout out of a fixed set of components, which is precisely why it is reliable enough to hand to a dispatcher.

The problem it solves

Every transport company keeps records that no TMS ships with. Fuel logs. Damage reports. Pre-trip inspections. Fines, and who eventually paid them. Petty cash. Training dates for drivers. Which pallets went where and came back.

The old options were both bad. Either you kept it in yet another spreadsheet, back in the world the rest of this blog keeps telling you to leave, or you paid a vendor to add it, waited a quarter, and got a field that was almost right. Meanwhile the thing you actually needed took four fields and an afternoon.

What you get from one sentence

You type what you need in normal language. The builder answers with a layout: a card with the fields it inferred, sensible types for each one, and a suggested title for the module.

The components it can use are a fixed set: text fields, long text, numbers, dates, dropdowns, file dropzones for photos and documents, charts, and cards to group things. Dropdowns can pull from your own list, from your custom dictionaries, or from real records in your workspace, which is how a "vehicle" field on a fuel log becomes an actual picker of your actual trucks rather than free text somebody spells differently every time.

When your description is close to something common, the builder recognises it and uses a curated template built in-house instead of improvising. Fuel logs, pre-trip inspections, vehicle damage, fines, petty cash, training records, delivery logs, incident and accident reports, equipment inventory, employee expenses, and customer feedback all have one. The AI picks the template, and the layout is then assembled from our definition rather than from generated JSON, which is a deliberately boring design and the reason those modules come out right every time.

Once at least one input field exists, the module gets its register automatically: an Add button, a table of saved rows with the columns derived from your fields, search, filters, and edit and delete on each row. You do not describe the list. It follows from the form.

What happens after the first sentence

This is the part that matters more than the generation, because the first draft is never the last one.

Nothing is applied until you look at it. The preview shows what changed, with new and modified fields marked, and you either accept it or throw it away. You can keep refining by conversation, asking for another field or a different arrangement, and each round works from the current preview rather than starting over.

You can also drag things around yourself and stop talking to the AI entirely. The visual editor is the same editor either way, with undo and redo, a wizard for widths, an icon picker, and control over which columns show in the list.

Edits to a live module are treated carefully, for the obvious reason. If a change would remove a field that already has data behind it, you get a warning naming that field before you save, rather than a cheerful confirmation afterwards. Renaming a label does not rename the underlying field on anything already saved. Every save writes a version, and you can look at the history and revert.

The honest limits

Three things worth stating plainly.

Module creation is still gated while we are in early access. It runs, we use it, and it is not open to every workspace yet. Nothing here is a promise that you can log in this afternoon and build one.

AI generation is metered. It uses the AI service, which is one of the paid services in the pay-as-you-go model, so the rate and your usage sit in the panel like everything else. There is also a limit of ten generations per hour per user, which exists to stop a stuck loop from spending your money. Dragging fields around yourself costs nothing.

And it builds forms and registers, not workflows. It will not write you a pricing engine or a custom dispatch algorithm. The honest description is that it removes the "we cannot record that" answer, not that it replaces development.

Why it is worth building this way

The pattern we kept seeing in transport software is that customisation is where the money quietly goes. The base system is fine, then you need one field, and that field turns into a support ticket, a scoping call, and an invoice, three times a year.

A system a company can shape itself, with a preview before anything applies and a version history behind every change, does not need that loop. It is the same reasoning as the pricing: you should not be charged a toll for using the product the way your business actually works. The reasoning behind the money side is in what LiteTMS is and why it bills pay-as-you-go.