Product Decisions This Supports
- Build vs. buy/reuse for a form builder: This package is a reference point for the "we need admins to create forms without a deploy" feature. It packages four capabilities PMs usually spec separately: form configuration (via Sonata Admin), submission storage, notification emails on submit, and results export. That scope is a useful checklist for scoping our own version — it tells you the feature is bigger than "a form builder screen."
- Feature scoping for internal tooling: If our roadmap includes CMS/admin-configurable lead-gen, contact, or survey forms, this describes a plausible MVP boundary: create form → store result → notify → export. Use it to decide which of those four we actually need in v1.
- Buy/adopt decisions: The dependency profile (archived, zero stars, zero dependents, README-only maturity) makes this a clear "do not adopt as a dependency" input. It supports the decision to either build in-house or select a maintained form-builder package — not to take this one.
- Platform fit gating: It presupposes Symfony and Sonata Admin. That's a concrete constraint PMs can use to rule the approach in or out based on our existing stack rather than on feature appeal.
- Not a roadmap input: No signal here for future investment. Do not let the feature list pull this onto a roadmap as a dependency; at most it informs design of something we own.
When to Consider This Package
Consider it only when all of the following hold:
- You are already running Sonata Admin on a legacy Symfony application and want a configurable form feature without new UI work.
- You need the exact bundled scope — admin-defined forms, stored submissions, submit notifications, CSV-style export — and nothing more.
- You are prepared to fork and own it: vendor the code, pin it, and accept responsibility for security patches and Symfony upgrades. Treat it as a code sample or starting point, not a library.
- The feature is internal/low-stakes (back-office data collection), not customer-facing or compliance-relevant.
Look elsewhere — or build — when:
- You are on a modern Symfony version or any non-Symfony/non-PHP stack; there's no compatibility or support commitment here.
- You need maintained dependencies, a security response process, or a support contract. Archived status alone disqualifies it for anything production-critical.
- You need modern form UX (conditional logic, multi-step, file uploads, validation rules, i18n) — this is described as "basic forms."
- You need API-first or headless form submission; this is coupled to server-rendered Symfony + Sonata.
- You would be the first dependent. Zero dependents means zero field-tested edge cases and no community to fall back on.
How to Pitch It (Stakeholders)
For executives: This is a small, archived Symfony bundle that lets admins build basic forms inside Sonata Admin and captures submissions, notifications, and exports. The capability is real and matches a feature we may want; the package is not viable as a dependency — it is archived, has no known users, and receives no maintenance. Recommendation: do not adopt. Use it as a scope reference for a feature we build or source from a maintained vendor, and budget accordingly.
For engineering: It's a Sonata Admin-coupled form builder with four concerns (configuration, storage, notification, export). We would be taking on full ownership including security and Symfony upgrade work, with no upstream and no user base to validate against. If the feature is genuinely needed, either fork it deliberately with an owner assigned, or implement the same four concerns directly against our current stack. If we don't run Sonata Admin, this is a non-starter.