Opening a tool to real users is the part you prepare for poorly. You think you've anticipated the edge cases. You haven't anticipated the right ones.
What worked immediately
Simple forms worked right out of the box. Registration forms, internal admin portals, pages with standard text fields: the first-try mapping accuracy exceeded 90%. HR users in particular were surprised by the speed — what used to take 20 minutes shrank to 30 seconds of initial configuration, then a few seconds per row.
One piece of feedback came up repeatedly in the first few days: "I didn't know this was possible without a developer." That's the most satisfying thing to hear, because it's exactly what we were going for.
What resisted
Some cases proved harder than expected.
CMS with dynamic interfaces. WordPress with Gutenberg generates an editing interface where fields aren't standard HTML form elements — they're dynamically built by React, with rich editing components. The form inspector detects the wrong elements. Drupal with custom fields poses similar challenges.
Multi-step wizard forms. Some HRIS forms are multi-page wizards — personal information on page 1, contract details on page 2, bank details on page 3. Each step requires validating the previous one before loading the next. State management between steps wasn't in the code yet.
Cascading selects in complex HRIS. Even with the episode 2 improvements, some proprietary HRIS platforms have three- or four-level cascades with very specific asynchronous reloads. The select-utils.js logic improves with every new case encountered.
The decision that became the heart of the product
When the beta launched, several users looked for an "auto mode" button — fill AND submit without human intervention. That button doesn't exist. By design.
What started as a technical precaution — not taking responsibility for submitting sensitive data on behalf of a human — became the product's central trust argument. And the sectors where DataToForm is most useful are precisely those where this guarantee matters most: HR, insurance, public services.
Users who arrived with initial reservations — "how can I trust a tool that touches my payroll filings?" — left reassured once they understood the principle. The tool pre-fills. It stops. You review. You submit. The tool never submits for you.
That framing — "the tool that pre-fills but doesn't decide" — wasn't in the original pitch. It emerged from user feedback, and it's now central to how DataToForm is described.
What feedback changed
Two major improvements came directly from beta feedback.
Live browser stream. Early users received a "fill complete" message without seeing what was happening. Several asked to be able to watch the form being filled in real time. This became the CDP screencast — a canvas-based live stream of the Chromium window, rendered on the client side. It wasn't in the original architecture. It's now a core feature.
The multilingual use case. Digital agencies started using DataToForm to fill their multilingual CMS platforms. Their Excel file had per-language columns: title_en, content_en, title_fr, content_fr, title_es, content_es. They wanted to fill their CMS — WordPress, Drupal, TYPO3 — in multiple languages from a single file. This case became its own documented use case.
What's next
DataToForm is in open beta. The first row of each document is processed for free — FREE_ROW_LIMIT = 1 in server.js.
What's being built:
- Robust cascading selects for complex HRIS platforms
- Multi-step wizard forms (state management between pages)
- Mapping persistence between sessions on the same form
- Google Sheets as an alternative data source alongside Excel
What won't change:
- The AI will never see your actual data values
- The form will never be submitted automatically
- Your file will never be stored on the server
Three months of work to get here. And the sense that it's also the beginning of something else — an approach to automation that trusts humans rather than trying to replace them.