Roadmap & limitations

Declared plainly so they read as roadmap, not surprises. If one of these is a dealbreaker for your use case, better to know now — and several have workarounds documented below.

1. Bot & spam submissions

Public endpoints are rate-limited and origin-checked but have no CAPTCHA or proof-of-work. Self-hosted single-tenant deployments are a modest target, and the caps bound the damage, but a determined bot can submit junk. A pluggable challenge is a fast-follow candidate.

2. Response retention

IN_PROGRESS responses accumulate indefinitely — orphaned files are collected hourly, but abandoned answer documents are not. A retention setting is roadmapped; until then a Mongo one-liner covers it (delete abandoned drafts older than 90 days):

docker compose exec mongo mongosh forms_engine --eval \
  'db.responses.deleteMany({status:"IN_PROGRESS",updatedAt:{$lt:new Date(Date.now()-90*864e5)}})'

3. Editor undo

Destructive editor actions rely on confirmation dialogs (with explicit impact analysis) and version restore — there is no undo stack. The draft/publish split is the real safety net: nothing touches respondents until you publish.

4. Multi-language questionnaires

The labels override localizes the renderer’s chrome per embed; question content is single-language per questionnaire. Today’s workaround for multilingual sites is one questionnaire per language (export/import makes the copies cheap).

5. Analytics

Raw browsing plus CSV export only. A drop-off/analytics view is the planned first post-launch feature; until then, the CSV and your favorite tools are the analytics story.

6. Webhooks

There’s no push notification when a response completes — poll the management API or watch the database. Webhooks are roadmapped.

7. Server-side rule re-validation

The rule engine runs in the renderer; the public API validates answer shape and size but doesn’t re-run questionnaire logic, so a hand-crafted API client can submit answers the UI wouldn’t allow. The rule engine’s semantics are pinned by shared conformance fixtures precisely so a server-side engine can be added and provably match.

8. Honor-system deduplication

One-per-reference submission control deduplicates cooperative users; anyone editing the page can change the reference. Not suitable for contests, votes, or adversarial settings until signed references exist. The full analysis.

9. Completion-status enumeration

The reference-status endpoint necessarily reveals a completed-yes/no boolean per reference (rate-limited, boolean-only, never more). Use opaque random references where that boolean is sensitive.

10. No cross-device resume

Deliberate, not missing: with unsigned references, a guessable reference must never unlock a session, so resume stays same-device (sessionStorage). Cross-device resume arrives with signed references.

Also worth knowing

Smaller sharp edges, documented where they live:

• The editor’s questionnaire list caps at the 100 most recent (FAQ).
• Rate limiting keys on the direct peer IP — configure forwarded headers behind a proxy.
• The responses browser shows uploaded files as metadata without a download link; the management API serves the bytes.
• No health-check endpoint yet (the startup storage canary is the deploy-time check).

Non-goals

Things that aren’t on the roadmap because they’re not what this is: a hosted SaaS offering (one line: it doesn’t exist today), a form page builder (Forms-Engine embeds into your pages; it doesn’t host standalone form URLs), and payment/scheduling/workflow features. The scope is questionnaires — built visually, embedded anywhere, with your data in your database.