Why data portability is a product feature, not a setting
By The Askery Team
- data portability
- schema
- architecture
Export is usually an afterthought
Most form tools treat export as a checkbox feature. There is a CSV button somewhere in a settings menu, it dumps a flat sheet, and the structure that made the data meaningful - question types, option groupings, branching, the link between an answer and the exact question it answered - is gone the moment you click it.
That gap is not an accident. When export is lossy, switching costs are high, and high switching costs are commercially convenient for the vendor. The result is a quiet tax: you can technically get your data out, but you cannot get it out in a shape anyone else can use without a rebuild.
We think that is the wrong default. A form is a small data application, and the responses are an asset you should be able to take with you on the day you decide to. Portability is not a feature you bolt on near launch; it is a property of how the system is shaped.
One canonical schema, everywhere
Internally there is a single source of truth: one canonical schema that defines every field type, every validation rule, and the structure of every response. The builder writes to it, the renderer reads from it, the AI generator must conform to it, and exports serialize it directly. There is no second model that drifts out of sync.
Concretely, this means a JSON export is not a downgraded copy of your form - it is the same structure the product runs on. You can re-import it, diff two versions, or hand it to an engineer who has never seen the tool, and the meaning travels with it. The relationship between a response and the question that produced it survives the round trip.
This is what makes the schema worth treating as an invariant rather than an implementation detail. If you want the longer argument, our glossary entry on data portability covers what 'lossless' actually has to mean in practice.
Answers reference IDs, never labels
There is a subtle decision underneath portability that most tools get wrong: what an answer points at. If a response stores the label of the option a user picked, then renaming 'Very satisfied' to 'Extremely satisfied' silently splits your historical data into two buckets that should be one.
Every answer references a stable ID for the question and, where relevant, the option - not its display text. Labels can change, translations can be added, wording can be tuned for clarity, and the longitudinal data stays intact. The text is presentation; the ID is identity.
This is unglamorous and it is the entire game for anyone running the same survey quarter after quarter. A trend line is only trustworthy if the thing you are trending did not quietly change underneath you.
What portability buys the buyer
For a team evaluating tools, portability is a risk control. It means a pilot does not become a permanent dependency by accident, and a vendor decision is reversible. Reversible decisions are cheaper to make, which is good for the buyer and, counterintuitively, good for an honest vendor too.
It also changes the integration story. Because the exported structure is the real structure, piping responses into a warehouse, a spreadsheet, or another system is a mapping exercise, not a reconstruction project. The same property that lets you leave cleanly is the property that lets you connect things while you stay.
Lock-in is a tax you pay later, usually at the worst time - during a migration, an audit, or a vendor change you did not choose. Designing around one canonical schema is how you decide, up front, not to owe it.