Contact Laravel Package

Product Decisions This Supports

• Build vs. buy on a commodity feature. A contact form is table stakes — one route, one validation request, one contacts table, one queued notification, one honeypot. The package only earns a place in our stack if it removes meaningful integration work inside an existing LiteCMS deployment. In any other context, "buy" here means "borrow code from an unmaintained repo and adopt its maintenance burden," which is a build decision wearing a buy costume.
• Roadmap scoping for lead capture. Capture-and-store is the smallest slice of this feature. The product decisions that actually move a funnel are downstream: where submissions route (shared inbox, CRM, ticketing), who owns response SLA, deduplication, notification reliability, retention windows, and consent capture. The package (as described) covers none of that. Use this evaluation to force those questions onto the roadmap before committing to any implementation.
• Platform standardization. If we standardize on LiteCMS for client sites, the decision is whether we adopt per-feature add-ons or own a thin internal module shared across projects. Zero stars and zero dependents means adoption is a bet on the LiteCMS maintainers' roadmap, not on community validation. That is a portfolio-level decision, not a per-project one.
• Support cost modeling per site. Every adopted package adds a line item to the upgrade budget: Laravel major-version tracking, PHP bumps, security patching, admin-menu drift on core upgrades. With no visible community, 100% of that cost lands on us — and it multiplies across every cloned template.
• Timeboxed spike / feature-flagged pilot. Low blast radius makes this a legitimate half-day experiment on an internal site or demo to test developer experience. It is not a candidate for a committed dependency in a production template.
• Risk triage on a public write surface. A contact form is an unauthenticated endpoint that concentrates spam, header-injection, upload, and admin-render XSS risk. Deciding whether to carry that surface on unmaintained code is a product risk decision, not just an engineering preference.

When to Consider This Package

Consider it only when all of the following hold:

• You are already running LiteCMS, and the package plugs into its admin surface, permissions, and routing. Native integration is its only real differentiator; the capability itself is generic.
• The use case is internal, low-stakes, or non-regulated — an intranet "contact us" box, a prototype, a demo environment, a marketing microsite shipping this sprint where the form is not a differentiator.
• Delivery speed genuinely dominates and the form has no downstream product requirements (no CRM sync, no routing rules, no SLA reporting).
• Someone has read the source (small enough to audit in an hour) and confirmed validation, spam controls, storage/retention behavior, and how the notification mail is dispatched and whether failures are handled or swallowed.
• You accept ownership: pin to a commit or tag, fork into org VCS, name an internal owner, and budget a compatibility check each Laravel upgrade. Treat it as vendored code, not a supported dependency.
• License terms permit an internal fork, and version constraints match our PHP/Laravel/litecms/core matrix.

Look elsewhere, or build it in-house, when:

• The property is customer-facing at any scale. Spam volume, deliverability, and abuse handling become product-visible problems. Prefer maintained building blocks: Laravel validation + queued Mail/notifications, plus edge rate limiting and honeypot or captcha.
• You need CRM or ticketing integration, routing rules, multi-recipient logic, attachments, or analytics on submission-to-response time. None of that is implied by the description, and gluing it onto a tiny package costs more than a clean 1–3 engineer-day in-house module.
• Compliance matters — consent capture, PII handling, retention policy, right-to-erasure, WCAG accessibility on the form. Auditability of an unmaintained package is a hard sell to a security reviewer.
• Projects are long-lived or template-reused. A zero-star, zero-dependent package is a liability that compounds with every clone.
• You are not on LiteCMS. The package then offers nothing a short form implementation doesn't, minus the dependency.

Due diligence checklist before any adoption: license compatibility and fork permission; last commit date and release cadence; PHP/Laravel/litecms/core version constraints; whether migrations are publishable and reversible; whether tests and CI exist; whether submissions are persisted, emailed, or both (affects privacy posture and backup surface); confirmation that admin routes sit behind the core auth middleware and that user input is escaped on render. Decide the downstream routing and retention policy first — the package choice is a footnote to that.

How to Pitch It (Stakeholders)

Executive summary. litecms/contact is a small contact-form add-on for the LiteCMS Laravel CMS: a public form, a submissions table, and an admin screen for reviewing messages. It has no community traction — zero stars, zero dependent packages, no visible CI, tests, or release cadence — which means no independent validation, no ecosystem finding and fixing issues, and no credible support path. Its only defensible value is drop-in integration for teams already standardized on LiteCMS.

Recommendation. Do not adopt this as a strategic dependency. Permit it as a timeboxed convenience for internal or low-risk sites, with an explicit escape hatch and a named internal owner. For customer-facing properties, fund a small in-house contact module — roughly 1–3 engineer-days including tests, spam protection, queued notification handling, and retention policy — that we own and can extend toward CRM routing and response-time analytics later. That investment is smaller than the accumulated cost of forking and maintaining an unmaintained package across multiple sites, and it removes a single point of failure sitting on a public, unauthenticated endpoint.

For engineering. Read the source before merging; pin to a tag and fork into org VCS rather than floating ^ constraints. Verify version compatibility with our PHP/Laravel/litecms/core matrix, confirm admin routes are behind core auth middleware, and — critically — confirm the package does not silently swallow mail failures. Persist every submission to the database; never let email be the sole record of a lead. Add our own spam and rate-limiting layer. Budget a compatibility check each Laravel upgrade cycle.

For product. The package solves the easy half. The value sits in where submissions go next, who owns the response, and how we prove we handled customer data responsibly. Settle those questions — routing, SLA, retention, consent — before any build-or-buy call, because they determine whether a drop-in module is sufficient or actively constrains us.