Documents Laravel Package

Product Decisions This Supports

• Feature scoping for document attachment: Informs whether "attach/download/remove files on a record" is a launch-blocking feature or a fast-follow. This package covers the baseline CRUD loop (upload, list, download, delete) plus per-user file tracking, so it answers the question "how much of our document feature is already commodity?"
• Build vs. buy for file management: A concrete reference implementation for the build side of the estimate. Comparing a 1–2 sprint in-house build (upload endpoints, storage layout, DB metadata, permissions, cleanup jobs, UI) against adopting an MIT-licensed package that already encodes those conventions.
• Admin/back-office roadmap sequencing: Because it ships inside the Enso ecosystem, it makes document management cheap if the roadmap already includes an Enso-based admin panel — and expensive if it doesn't (you'd be importing a stack, not a library).
• Use-case coverage decisions: Best fit is per-record, per-user attachments (customer contracts, KYC/ID docs, HR files, invoice PDFs, support ticket attachments). Poor fit for anything needing versioning, retention policy, e-signature, or OCR — those stay on the roadmap as separate bets.
• Compliance/audit posture: "Keep track of the user's files" implies ownership tracking but not retention schedules, immutable audit logs, or legal hold. Useful to decide explicitly whether v1 ships with soft-delete only and defers compliance-grade audit to a later phase.
• Platform standardization: Sets the precedent for whether the product accepts vendor-coupled packages (Enso conventions, Enso UI components, Enso storage paths) or mandates framework-only dependencies.

When to Consider This Package

Consider it when:

• You are already running Laravel Enso (or have committed to it for the admin/back-office layer). The package's value is largely that it plugs into Enso's existing models, routes, permissions, and Vue components — outside that context much of the benefit evaporates.
• You need attach/list/download/delete files against arbitrary Eloquent models (polymorphic attachments) and per-user file listing, and you want it in days rather than sprints.
• Your storage needs are local-disk and modest-volume. No hard requirement for S3 multipart, CDN delivery, or cross-region replication.
• You want MIT-licensed, no-vendor-lock-in-on-paper code you can fork and modify, with a small enough surface area to read end-to-end.
• Your team is comfortable owning a fork — you accept that maintenance is effectively yours.

Look elsewhere when:

• You are not on Enso. Pulling this in means pulling in Enso's conventions, frontend stack, and upgrade cadence; a standalone package (or ~200 lines of custom code) will be cheaper and less coupled.
• You need enterprise document capabilities: versioning, retention/legal hold, virus scanning, OCR/text extraction, e-signature, watermarking, DLP, or fine-grained per-document ACLs beyond owner-based access.
• You need cloud-native storage (S3/GCS/Azure) with signed URLs, or large-file/chunked uploads.
• You need a headless API for mobile/third-party clients rather than Enso's UI-driven flows.
• Project health matters to your risk model: 20 stars and a single-vendor maintainer is a genuine signal. If the document feature is on a critical path with a multi-year horizon, the bus factor and community size are disqualifying on their own — pick a package with a broader contributor base or own the code deliberately.
• You require multi-tenant isolation with per-tenant storage segregation and quota enforcement; that's almost certainly custom work regardless of package.

How to Pitch It (Stakeholders)

For executives (30 seconds): This is a small, free (MIT) building block from the Laravel Enso ecosystem that handles the unglamorous 80% of file attachments — upload, download, delete, and tracking whose file belongs to whom. It lets us ship a "documents on a record" capability in days instead of weeks, with no licensing cost. The trade-off is strategic, not financial: it's a low-popularity package from a single vendor, so we should only adopt it where we're already standardizing on Enso. Otherwise we pay a hidden tax in coupling to a stack we didn't choose. If we do adopt it, budget a small amount of engineering time to fork and own it — treat it as code we acquire, not a dependency we lean on.

For engineering (the honest version): It gives you polymorphic document attachments on Eloquent models, a DB-backed document record, storage conventions, and Enso's Vue upload/list UI wired to Enso's routes and permission system. You get a working feature fast and a codebase small enough to audit in an afternoon. What you don't get: versioning, retention, scanning, S3-first storage, or a documented public API. The real cost is the dependency graph — adopting this means adopting Enso's assumptions about models, storage paths, and frontend components, and inheriting an upgrade cadence we don't control. Recommendation: adopt only if Enso is already in the stack; in that case fork it into our namespace on day one, write a thin internal adapter around the storage and retrieval calls, and keep the file records in our own schema so a future swap is a migration, not a rewrite. If Enso isn't in the stack, we should estimate the in-house build honestly — it's likely smaller than the integration cost.