Drafts Laravel Package

Product Decisions This Supports

• Composer experience roadmap: Drafts are a table-stakes contributor feature for modern community platforms. This package helps answer whether “save draft / resume draft” belongs in the next composer iteration, especially for long-form discussion, proposals, support requests, and mobile-first users who compose across sessions.
• Feature vs. parity decision: Competitors such as Discourse already treat drafts as expected forum behavior. Adopting or rejecting this package is a concrete input into competitive parity analysis and whether drafts are a differentiator, a retention lever, or simply expected hygiene.
• Build vs. buy vs. defer: The MIT license and small surface area make this a low-cost trial candidate. The decision is less “can we build drafts?” and more “do we want to own draft storage, autosave UX, permissions, cleanup, and cross-device expectations ourselves?” This package provides a reference implementation and a possible shortcut.
• Activation and abandonment metrics: Drafts support measurable product questions: does reducing lost-work anxiety increase draft-to-published-post conversion, post completion rate, average composed length, and return-to-compose behavior? It also supports analysis of abandonment reasons for high-effort posts.
• User segmentation: Drafts matter disproportionately to power contributors, moderators drafting announcements, support seekers writing detailed issue reports, and mobile users. This package can support a targeted pilot for those segments rather than a platform-wide bet.
• Moderation and privacy review: Drafts introduce product decisions about draft visibility, retention, stale-draft cleanup, storage growth, and whether drafts are private per user. Adopting this package forces those policy decisions earlier, which is useful even if the package is not ultimately selected.
• Roadmap sequencing: With 18 stars and zero dependents, the package is a low-signal, early-adoption dependency. It supports a “pilot now, revisit native support later” roadmap rather than a strategic platform commitment.

When to Consider This Package

Consider it when:

• The product is already on Flarum and needs draft-saving behavior without waiting for a native feature.
• Users are visibly losing work, complaining about abandoned compositions,或 the community relies on long-form posts where composition spans multiple sessions.
• The team can evaluate and pin a community extension, review its code and migrations, test it against the current Flarum version, and accept some maintenance risk.
• A time-boxed pilot is acceptable: enable drafts for a subset of users or categories, measure completion and abandonment, then decide whether to keep, fork, or replace.
• The expected requirement is simple: private per-user drafts for discussions, not enterprise-grade document collaboration.
• The licensing and cost profile matter: MIT removes procurement friction and makes a trial cheaper than custom development.

Look elsewhere or defer when:

• The platform is not Flarum or the team is not prepared to own a PHP extension dependency.
• Drafts are expected to be cross-device, versioned, collaboratively edited, auditable, or compliance-controlled; this package is not positioned as that kind of system.
• The organization requires vendor support, SLAs, or a mature maintenance signal. Eighteen stars and zero dependents are adoption signals, not quality signals; due diligence should include open issues, release cadence, test coverage, and maintainer responsiveness.
• There is no capacity to review upgrades or handle extension conflicts after a Flarum upgrade.
• Draft privacy, retention, and data-residency requirements are undefined. Those are product and legal decisions that should precede adoption, not follow it.

How to Pitch It (Stakeholders)

For executives: This is a low-cost, low-risk experiment to improve contributor conversion. Drafts reduce the “I lost my post” failure mode that disproportionately affects long-form and mobile users. The package is MIT-licensed and narrowly scoped, so we can pilot it without a large build commitment. The main risk is dependency maturity: it is a small community extension with limited adoption, so we should treat it as a validated trial, not a strategic platform bet.

For engineering: It is a PHP/Flarum extension that adds discussion drafts to the composer. The evaluation should cover code quality, database migrations, draft retention and cleanup, permission boundaries, compatibility with our Flarum version, and upgrade path. Because adoption is low, we should pin the version, test in staging, and avoid forking unless the pilot proves value and the upstream project cannot meet our needs.

For product and community stakeholders: Start with a pilot and define success before enabling it: draft-to-post conversion, compose abandonment, post completion time, and qualitative feedback from high-effort contributors. If the pilot shows lift and the extension remains maintainable, keep it or fold the behavior into our own roadmap. If not, the trial still gives us evidence for whether drafts are table stakes or optional.