Schema-on-Write: Why Your Forms Should Infer Their Own Structure

You open a form builder, drag in eight fields, pick dropdown options, configure validation rules, and save. Then you realize you want to collect one piece of information the tool does not support as a built-in type. You look for a custom field option. It is behind a paid plan. Forty minutes in, you have not collected a single response.

This is the schema-on-read problem: you define the structure first, then collect data that fits it.

OperatorStack forms flip this. Submit data, and the schema builds itself.

What Schema-on-Write Means

Traditional form tools follow a schema-on-read pattern:

1. Define fields in a builder (names, types, validation)
2. Collect submissions that match that schema
3. Query data that already fits the structure you declared

Schema-on-write reverses steps 1 and 2:

1. Submit data
2. The system infers field names and types from what arrived
3. The schema is stored alongside the data, known and consistent going forward

The first time you submit {"plan": "pro"}, OperatorStack records that plan is a text field. The second time you submit {"plan": "free", "company": "Acme"}, company is added to the schema. Old submissions show it as empty. The schema grows without any dashboard action.

Why This Matters During Pre-Launch

Early-stage data collection has a specific shape: you do not yet know what questions to ask.

You launch a beta signup form with name, email, and "what problem are you trying to solve?" Two weeks in, you want to add "what tool are you using now?" You add the input to your HTML. The next visitor who submits gives you that field automatically. That is the full workflow.

Schema-on-read tools make this a four-step detour: open the builder, add the field, configure validation, deploy. For a founder iterating weekly on their landing page, that friction is not theoretical -- it is twenty minutes of tool maintenance per change.

The speed difference compounds. Over six weeks of validation, schema-on-write lets you run ten field iterations where schema-on-read allows four.

How It Works in OperatorStack

Every OperatorStack project gets one endpoint per form: POST /v1/f/{form_key}. The endpoint accepts JSON, form-urlencoded, and multipart.

A plain HTML form submission:

<form method="POST" action="https://api.operatorstack.dev/v1/f/frm_abc123">
  <input type="text" name="name" placeholder="Name" />
  <input type="email" name="email" placeholder="Email" />
  <textarea name="problem" placeholder="What are you trying to do?"></textarea>
  <input type="hidden" name="_redirect" value="https://yoursite.com/thanks" />
  <button type="submit">Submit</button>
</form>

The same submission via the SDK:

await OperatorStack.ready;

await OperatorStack.submitForm("frm_abc123", {
  name: "Jane",
  email: "jane@example.com",
  problem: "I want to track which referrers actually convert",
});

After the first submission, your dashboard shows three columns: name, email, problem. Add a company field to the HTML and submit again. Four columns. No dashboard visit required.

Reserved Fields

Fields prefixed with an underscore are metadata and are not stored:

• _redirect -- the URL to send the visitor to after submission
• _subject -- a label for categorizing the submission

Everything else is stored as form data and added to the schema if it is new.

Where the Data Goes

When a submission includes an email field, OperatorStack creates or updates a unified Contact record. A person who joins your waitlist, submits a feedback form, and sends a contact message appears as one contact in your Audience tab, not three separate records across three tools.

The form endpoint and the waitlist endpoint share the same Contact model. Both write to the same unified contact list.

Schema-on-Write vs. Traditional Form Builders

Schema-on-write does not handle every case. If you need conditional logic, multi-step flows, or strict validation that blocks bad submissions, a dedicated form builder is more appropriate. For early-stage data collection where iteration speed matters more than strict validation, schema-on-write wins.