DataToForm wasn't born from a single moment. It came from two distinct situations, in very different contexts, that posed exactly the same problem — and for which no direct solution existed.
Case 1 — Finance and its regulatory forms
In financial teams, data lives in Excel. Dense, often complex files: multiple sheets, merged cells, calculated columns, non-normalized structures that have evolved over years. This data — portfolios, positions, contract characteristics, risk reports — regularly needs to be entered into regulatory portals, proprietary back-offices, reporting tools imposed by providers or oversight authorities.
None of these systems expose a usable API. Some have internal, closed APIs documented nowhere. Others are decade-old web applications never designed to be interfaced automatically.
The result: an analyst who needs to process fifty files in a regulatory portal spends half their day copying what's already in their spreadsheet. Copy the ISIN code. Switch window. Paste. Copy the nominal value. Switch. Paste. Repeat for every field, every row, every declaration.
The problem becomes acute when data changes. A reference update, a valuation correction — and it all starts over. No import, no sync, just someone retyping what someone else already entered somewhere else.
Case 2 — Agencies and multilingual re-entry
In startups with international presence, and in communication agencies managing multilingual client sites, a different variant of the same problem appears.
The content team prepares text in Excel or Google Sheets: one column per field, one set of columns per language. title_fr, description_fr, title_en, description_en, title_es, description_es. One row per article, per product page, per landing page.
Then comes the back-office entry — WordPress, Drupal, Strapi, a proprietary CMS, whatever. Open the admin interface, create the French content, fill in field by field. Then switch to the English version, re-create the same content, fill again. Then Spanish. For every article. For every language.
The worst part isn't the initial entry — it's re-contribution. The client asks to rephrase a paragraph, adjust the tone, correct a translation. You have to find every entry in every language, open every form, edit every field. A content update can cost as much time as the original entry. For an agency billing by the hour, that's non-billable work. For a startup without an available developer, it's a burden that accumulates and gets pushed back.
What these two cases share
Regulatory finance and multilingual CMS back-offices: nothing in common on the surface. And yet the structure of the problem is identical.
The data already exists. It's in a structured, clean, validated file. Someone already entered, checked, and approved it.
The destination is known. It's a web form on screen, with specific fields waiting for specific values.
The intermediate work is purely mechanical. Look at the value in Excel, find the right field in the form, copy it, repeat. No added value — just friction and a source of errors.
In both cases, the question is the same: why does someone have to do this by hand?
Why existing tools didn't help
Zapier and Make connect applications via APIs and webhooks. They're excellent when both sides have a connector. A proprietary regulatory portal or a back-office with no API? Out of reach.
RPA tools (UiPath, Power Automate Desktop) can interact with web interfaces, but require a developer to configure each form and continuous maintenance when interfaces change. That's not a tool — it's a project.
Autonomous AI agents (Browser Use, Skyvern, Operator) are a newer category. They open a browser, "understand" the page, and act independently. Promising — except they submit automatically. For a regulatory filing or live content publication, letting an AI decide without human review creates real risk: misinterpreted data, content published without validation, no way to correct after submission.
The question I formalized
Can we automate copy-paste without removing the human from the loop?
Five implicit conditions:
- Source: an existing Excel or CSV file, without reformatting
- Target: any web form, without API, without connector
- Intelligence: AI suggests the column → field mapping
- Control: the human validates the mapping before filling
- Deliberate stop: the form is pre-filled, and we stop there — the human submits
The fifth condition is the most structural. It separates DataToForm from all autonomous agents — not by default, but by design.
First sketch of the solution
Three components on paper:
A smart Excel parser. Real files have merged cells, titles in the middle of data, multiple sheets, calculated columns. SheetJS can read them, but understanding their structure requires help — a first LLM call to identify the actual data columns.
A form inspector running in a real browser. Playwright opens a real Chromium, loads the page with its JavaScript and dynamic components. The inspector reads what the browser actually renders — visible fields, their labels, their types.
An LLM as the semantic bridge. It never sees the file values — only column names and field labels. It understands that title_en maps to the "Title (English)" field in the back-office, that ISIN goes into "Security code". Pure semantics, no access to the data.
The next step was to write the code. That's what Episode 2 is about.