Bolt Laravel Package

Product Decisions This Supports

• Build vs. buy on "user-defined forms." Dynamic forms look like a two-sprint ticket and behave like a multi-quarter obligation: field rendering, validation, dual-surface UI (admin + public), submission persistence, exports, notifications, and — the part every estimate misses — schema evolution when a live form changes underneath existing data. Bolt lets you buy the boring 80% and spend your own engineers only on the last mile that's genuinely yours (branding, downstream integrations, access control), or skip the capability entirely if demand doesn't hold up.

• Whether forms are a differentiator or table stakes. If forms are adjacent to your core — CRM intake, HR/people ops, events, agency client portals, per-tenant SaaS onboarding — Bolt can pull a "custom fields / custom forms" roadmap item forward by months and let you validate usage before committing headcount. If forms are the product, this is a prototype scaffold, not a foundation.

• Self-serve for non-engineering teams — a backlog argument, not a feature argument. The ROI case is not "ops gets a form builder." It's that ops, support, marketing and CS stop filing "can we add one field / reword this question" tickets. Instrument it during a pilot: form-change ticket volume, request-to-live cycle time, engineering hours reclaimed. That's the number you defend in a quarterly review.

• Vendor substitution under cost or data-residency pressure. MIT, self-hosted, no per-submission or per-seat pricing. At high submission volume, or where routing respondent PII through Typeform/Jotform/Tally is a compliance non-starter, owning the schema in your own database can outweigh a hosted product that is genuinely better on features.

• An ecosystem bet, made explicitly rather than by accident. Zeus packages sit on Laravel + Filament. If you're already a Filament shop, integration cost and mental-model cost drop sharply and this is close to a no-brainer for internal tooling. If you're not, adopting Bolt effectively means adopting Filament — a much larger commitment that needs its own sequenced decision, not a side effect of a form-builder ticket. Ask this question in the first meeting, not the third.

• Data-governance decisions surfaced early. Form definitions and respondent submissions live in a schema you don't fully control. That forces retention policy, PII classification, per-respondent deletion (GDPR/CCPA), and export/exit strategy onto the table at design time instead of after the first audit. Painful early, much cheaper than late.

• A concrete roadmap question this surfaces: are form definitions authored in PHP (committed, code-reviewed, deployed) or in the database (edited live by ops without a deploy)? The answer determines who owns form changes, what your release process looks like, and whether "no deploy required" is a promise you can actually keep.

When to Consider This Package

Good fit:

• You're on Laravel, and ideally already running Filament, so the admin surface and component model come nearly free.
• The forms are internal-first or authenticated-first: intake requests, waitlists, surveys, client onboarding — places where a mistake is a Slack message rather than a public PII incident.
• Submission volume is modest (hundreds to low thousands), or you can accept a reporting projection table you maintain yourself.
• You need a small, opinionated field set plus two or three genuinely custom field types — not a 40-widget field catalog.
• You value no per-seat / per-submission fees and self-hosted data enough to accept single-maintainer, best-effort support.
• You're willing to wrap it: your own service class around submissions, your own events, your own export job. That wrapper is what makes "replace it later" a week instead of a quarter.

Look elsewhere when:

• Forms are core to the product. Customer-facing, high-volume, conversion-critical forms want a mature vendor or a purpose-built internal build — not a package with ~243 stars and zero public dependents.
• You need reporting on submissions. If anyone will ever ask "all submissions where budget > 50k, grouped by month," verify the storage shape first. A JSON blob per entry turns that into a PHP loop over every row; tolerable at hundreds, catastrophic at scale.
• You're not on Filament and don't intend to be. The Filament major version becomes the tightest coupling in your dependency graph, and Filament majors move fast. Pin the exact package version and add a Bolt smoke test to every Filament upgrade checklist — a form builder touches routing, auth, storage, mail, and the admin panel, so it lands on the critical path of every framework upgrade.
• You need an SLA or a support contract. Read the release signals skeptically: the listed last-release date is in the future, which means the metadata you're handed is unreliable. Check tags, commit cadence, and open-issue responsiveness on GitHub directly before committing.
• You need conditional-logic-heavy, multi-page, payment-integrated, or accessibility-certified forms out of the box. Budget for building those, or buy them.
• You need multi-tenant isolation and can't enforce it yourself. Tenant leakage in a form builder — one customer's intake appearing in another's admin — is a trust-destroying bug. If you can't add a global scope and a test for it, don't adopt.

How to Pitch It (Stakeholders)

To executives — the one-paragraph version: Bolt is a free, MIT-licensed form builder we can drop into our existing Laravel stack to let non-engineering teams create and change forms without a release. It buys us the commodity 80% of a "custom forms" capability — fields, validation, rendering, submission storage — so our engineers work only on the part that's actually differentiated for us. The business case is backlog reduction and speed-to-change, measured in form-change tickets and cycle time, not in a feature we can point at. The costs are honest: a thin-support dependency we must wrap and monitor, an implicit commitment to the Filament ecosystem, and governance work on respondent data that we'd have to do with any vendor — except here we own the schema instead of renting it.

To engineering — the framing that gets buy-in instead of eye-rolls: We are not adopting this as a foundation; we are adopting it as an adapter. Three rules make it safe: form definitions live in versioned classes, submissions go through our own service that emits our own events, and one scheduled export dumps definitions and entries to object storage from day one — that export is both our backup and our exit ramp. Pin the exact version, write one integration test per form (renders 200, valid payload persists, invalid payload yields the expected error keys, submission event fires), and establish a schema-evolution policy before ops touch a live form: additive changes only, never retype or delete a field that has submissions, snapshot the definition per submission. If the package disappoints, the wrapper turns replacement into a week of work.

To ops / the eventual users — set expectations explicitly: You'll be able to add fields, reword questions, and publish new forms without a deploy. You won't be able to delete a question that already has answers, or change a field's type retroactively — that's a guardrail protecting your historical data, not bureaucracy. Anything requiring new integrations, file handling, or public-facing hardening goes through engineering.

The decision I'd ask for now: a timeboxed pilot (two to four weeks, one internal authenticated form, end to end) with three success signals defined up front — one real form shipped, zero engineering tickets to change it after launch, and a written answer on submission storage shape that supports the reporting we'll actually need. If the storage shape doesn't support the reporting, that's a stop signal worth discovering in week one rather than quarter three.