Laravel Activatable Laravel Package

Product Decisions This Supports

• Activation/deactivation as a first-class product concept: The package provides a reusable Eloquent trait for marking records active/inactive (with query scopes and helpers), so product teams can ship "pause," "suspend," "archive," or "unpublish" behaviors without custom schema/logic per model.
• Soft-disable vs. hard-delete decisions: Supports retaining records for history, audit, and recovery while removing them from active product surfaces (feeds, listings, matching, billing), reducing irreversible-deletion risk.
• Build vs. buy: A small, focused package like this replaces scattered is_active columns and ad-hoc scopes across models with one consistent convention. It is a low-cost dependency versus building and maintaining the same behavior in-house.
• Roadmap enablers: Account/user suspension, content moderation states, feature/tenant gating, and temporary deactivation flows are cheaper to iterate on when activation semantics are standardized.
• Stability signal: The 1.0.0 release is the first stable version. This supports adoption decisions where API stability matters, but the release notes are effectively empty (only a changelog link), so verify the changelog/README directly before committing.

When to Consider This Package

Consider it when:

• Multiple models need a binary active/inactive state and you want consistent scopes, query helpers, and trait behavior.
• You want a lightweight complement to (or substitute for) SoftDeletes where "inactive but present" is the required semantics.
• Your domain states are simple and binary (enabled/disabled, listed/unlisted, active/suspended).
• You are standardizing conventions across a team and want to avoid divergent status column implementations.
• You value a small dependency surface and the stability implied by a 1.0.0 tag.

Look elsewhere when:

• You need multi-state workflows or state machines (draft → review → published → archived); use a dedicated state/transition library.
• You require rich audit trails, scheduling, reasons, or actor attribution for each state change.
• Activation is multi-tenant or scoped in complex ways beyond a boolean.
• You already have a well-governed status enum pattern; adding this package may duplicate logic.
• The empty 1.0.0 release notes give you insufficient confidence — confirm maintenance activity, test coverage, and Laravel version support first.

How to Pitch It (Stakeholders)

Executives: This is a small, low-risk utility that standardizes how we "turn things off without deleting them" — supporting account suspension, content moderation, and safe data retention. A 1.0.0 release signals API stability, and the footprint is minor, so adoption cost is low and it reduces bespoke code we would otherwise maintain.

Engineering: laravel-activatable offers a reusable trait plus query scopes for active/inactive records, letting you replace inconsistent is_active columns and one-off scopes with a single convention. It is easy to adopt incrementally per model and simple to test. Caveat: version 1.0.0's release notes contain only a changelog link, so validate the actual feature set, Laravel compatibility, and test coverage against the README before rollout; this fits binary activation states but not complex state machines.