Product Decisions This Supports
- Build vs. buy vs. skip for image focal control. The core decision this package informs is whether to ship "smart" responsive image cropping now or defer it. The package supplies the admin-side picking UI (an interactive image field where an editor clicks the subject), which is the expensive, fiddly part to build in-house. If the rest of your stack can already consume a focal point (CSS
object-position, or a crop call via Intervention Image/Glide/imgix), the incremental cost to ship the feature drops from days to hours.
- Roadmap sequencing for editorial autonomy. "Images get their heads cut off on mobile" is a recurring support ticket that quietly eats content-team time and designer time. A focal point field converts that from an engineering request per incident into a one-time editor action. That's a roadmap argument for investing in content-authoring tooling rather than one-off image fixes.
- Whether to escalate to a real DAM / smart-crop service. Use this package as a cheap probe: if a single manual focal point per image satisfies 80%+ of your art-direction needs, you've deferred a Cloudinary/imgix/Cloudflare Images decision for another cycle. If editors immediately ask for per-breakpoint focal points, art-directed variants, or automatic subject detection, that's your evidence to budget for a DAM instead.
- Scope boundaries for the media library. It clarifies a product question worth answering explicitly: does the CMS own derivatives (multiple generated crop files) or just metadata (a focal point plus original)? This package is firmly the metadata path, which is cheaper operationally but shifts responsibility for actually applying the crop to your front end and/or image pipeline.
- Feature-level use cases it unlocks: CMS-managed hero banners that survive 16:9 → 4:5 → 1:1 crops; product/catalog cards where the packshot must stay centered; team/author headshots in grids; editorial thumbnails where the interesting region isn't the center. Low-value for logos on white, patterns, textures, or illustrations with no clear subject.
- Risk/effort sizing for a "nice to have." With ~44 stars and zero dependents, this reads as a single-maintainer utility rather than an ecosystem standard. The PM decision isn't "is it good" but "is this small enough to own if it's abandoned" — and it likely is, since the field surface is narrow and the data it stores is trivially portable.
When to Consider This Package
Adopt when most of these hold:
- Your admin is Filament (Laravel/TALL stack) and you're on a version the package supports — verify this first, because Filament's major-version churn is the most common breakage vector for third-party fields.
- You have an image-heavy editorial surface (CMS pages, banners, catalogs) where non-square crops are routine and editors can't be trusted to pre-crop correctly.
- You already have, or can cheaply add, a downstream consumer for the focal point: CSS
object-position for the simple case, or a server-side crop (Intervention Image, Glide, imgix fp-x/fp-y) for generated derivatives. Without that, the field collects data nobody reads.
- Your team is small and the need is real but non-critical — you want a focused, single-purpose field rather than pulling in a full media/DAM package.
- You can pin a version and accept maintenance ownership (or vendor/fork it) — realistic for a 44-star package with one maintainer. Budget a small spike to read the source; it's a picker field, so the audit is short.
Look elsewhere when:
- You need true art direction: distinct focal points or separate crops per breakpoint, responsive
srcset variants, or multiple aspect-ratio renditions per asset. That's a DAM or an image-CDN conversation, not a field.
- You need automated subject detection (face/object-aware cropping) rather than a human click.
- You need governance: audit history of who changed a focal point, approval workflows, alt-text enforcement, accessibility sign-off, or compliance retention. Out of scope here.
- You're not on Filament, or you're on a Filament version the package hasn't caught up to. The admin-side UI is the whole product; without the matching Filament major, it's a non-starter.
- You need a vendor with an SLA or support contract. MIT, one maintainer, no dependents — this is a "we own the risk" dependency.
- Cropping is a revenue-critical path (e.g., ad creative rendering, marketplace listing images with contractual dimension requirements) where silent visual regressions cost money.
How to Pitch It (Stakeholders)
To executives (one line): A small, free, MIT-licensed add-on for our admin panel that lets editors mark the important part of each image, so photos stop getting cropped badly on mobile — days of work avoided, no new vendor contract.
To engineering (the shape of it): It's a Filament form field that renders the image and captures a focal point (normalized coordinates) as form state. We persist those coordinates on the media record and apply them downstream — cheapest path is object-position in CSS; if we need real derivative files, we feed the same coordinates into Intervention Image or our image CDN. The integration surface is a field, a column, and one consumer; no schema gymnastics.
The honest risk framing to include: ~44 stars, zero dependents, single maintainer, MIT. That's a buy-and-own dependency, not a bet-the-roadmap one. Mitigations are cheap: pin the version, read the ~small source before adopting, keep the stored data format simple (two floats) so migration off it is a field swap, and be prepared to fork if the maintainer goes quiet or Filament ships a breaking major.
The framing to avoid: don't sell this as "smart image cropping." It is a manual focal point picker. The moment stakeholders expect per-breakpoint art direction or automatic subject detection, the scope — and the vendor conversation — changes entirely. Set that expectation before the demo, not after.