Nova Import Laravel Package

Product Decisions This Supports

• Demand validation for admin-side bulk import. Before funding a first-class import capability, use this package as a cheap probe: does ops actually need CSV/Excel imports into Laravel Nova resources, and how often? It answers the "is this a real job to be done?" question in days rather than quarters, and produces usage data to justify or kill the roadmap item.

• Build vs. buy vs. borrow. For teams already running Nova, this is the "borrow" option — a tactical stopgap that front-loads the demand question and defers the ownership question. Frame it that way in the decision memo alongside a commercial baseline (e.g., Techsemicolon, Kirschbaum) and a thin internal build, so the comparison is honest rather than a default to "free."

• Roadmap prioritization for operational efficiency. If internal users are copying rows by hand, migrating spreadsheets, or batch-correcting records, this supports a small "admin productivity" initiative with a measurable ROI story: hours saved per month, reduction in manual entry errors, number of resources onboarded.

• Scope and boundary setting. It cleanly defines what an internal import tool is for — flat, single-table Eloquent models, back-office users, simple attributes, low-to-medium volume. Adopting it is not a commitment to customer-facing imports, relational mapping, dedupe/upsert, scheduled ingestion, or high-volume ETL. Setting that boundary now prevents scope creep later.

• Risk and dependency governance. Five years without a release, ~70 stars, zero dependents, no security-patching channel. This is a concrete case for a "vendored/at-risk" inventory with a named owner — the PM decision is whether to accept permanent maintenance cost for a bounded benefit.

• Specification value even if rejected. The upload → map columns → validate → import flow is a usable product spec for a thin internal build. A "no" here still produces a cheaper path forward, which is often the better outcome on modern Nova.

When to Consider This Package

• You are already on Laravel Nova, ideally Nova 3 with Laravel 6–8 / PHP 7.x, where a constrained install is fast and realistic.
• The use case is back-office, low-to-medium volume, targeting flat single-table models with simple attributes, tolerant of basic validation and error handling.
• You need something demonstrable in days, as a pilot to prove ops demand before committing funded engineering capacity.
• Engineering can inspect, patch, and fork the package, and someone is willing to be named owner of that fork and its upgrade path.
• You want a low-cost way to learn the real import shapes — file sizes, row counts, format quirks, failure modes — before specifying a build.

Look elsewhere when:

• You need customer-facing imports, strict data governance, audit trails, complex or relational mapping, dedupe/upsert semantics, scheduled ingestion, high-volume queued processing, or vendor support.
• You are on Nova 4/5 with a modern Laravel stack — treat this as a reference implementation to reimplement, not a dependency to install.
• The data is financially or compliance-relevant and "who imported what, when" is a requirement. The package does not provide it, and retrofitting it is a migration, not a patch.
• The acceptance criterion is "still working after the next Nova upgrade" rather than "working in six weeks." That flips the recommendation toward building or buying.

How to Pitch It (Stakeholders)

Executive summary. This is a small, Nova-specific CSV/Excel import tool that can cut manual back-office data entry and speed internal data migration with almost no initial build cost. Position it as a low-risk pilot for admin productivity — not a strategic import platform, and nothing customer-facing.

Upside: speed and cheapness. It slots into an existing Nova admin panel, gives users a familiar upload-and-map-columns workflow, and lets us test real demand in a short engineering spike instead of a funded build. If ops is copying and pasting rows today, the time savings are immediate and measurable.

Risk: maturity and ownership. Last release was 2020, the community is small, and nothing depends on it. There is no maintainer backstop and no security-patching channel. The import runs synchronously inside an admin request, so there is a practical row-count ceiling, no audit trail, and a real chance of half-written tables on failure. Adopting it means we become the maintainer — roughly 2–4 engineer-days per Nova major upgrade, plus a runbook.

Risk: data integrity. Header matching is literal (a BOM or trailing space silently maps zero columns), Excel mangles leading-zero identifiers and serial dates, and duplicate files create duplicate records because there is no upsert semantics. These are user-visible failure modes, not internal trivia — budget for guardrails (explicit field lists, per-row validation, a batch ID for rollback) as part of the pilot, not after.

Recommendation for engineering. Approve a 1–3 day spike on a scratch Nova install at our exact version to get a yes/no verdict on compatibility and security. If it passes: fork it privately, pin versions, gate it behind a permission, tag every import with a batch ID for rollback, and run one real resource end-to-end in staging. If it fails — or if we are on Nova 4/5 — reuse the flow as a spec for a thin internal build and carry the demand learnings forward.

What we will report back. A decision-ready summary: does it install at our version, what one real import cost in engineer-days, how many ops hours it would save per month, and a named owner plus upgrade cost estimate for the fork. That gives us a defensible go/no-go on the broader import roadmap without having spent a quarter on it.