Sign in Sign up

How it works

The form is data, not code

That single decision is what makes everything else possible. A form lives in the database as rows, so changing it is an edit — not a release.

A surveyor beside a total station in tall grass, writing a reading down on paper

The same app, three different forms

Nothing below is hard-coded. Switch the definition and the screen changes with it — that is exactly what happens on a phone in the field when someone edits a form in the panel.

definition → screen

        

Someone defines the fields

In the browser, in plain language. Name, type, required or not, options for a list.

The app builds the screen

Android reads the definition and renders the right control for each field type.

Records sync when they can

Saved on the device first. Uploaded later, once, even over a connection that keeps dropping.

Three pieces, two directions

Definitions travel outward, records travel back. The dashed line is what separates this from a web form: the record exists and is valid before the server ever hears about it.

Web panel defines forms manages users exports results REST API token per device deduplicates by UUID versioned definitions behind a CDN edge Android app renders the form writes to local storage works with no network definitions forms records + photos results local queue — waits for a connection, then sends once
Diagram: the web panel defines forms, the API delivers them to the Android app, and records travel back through the API to the panel. A dashed line shows the local queue when there is no network.

Set up your first form today

If you run field teams and the offline problem sounds familiar, create an account and build your first form in minutes.