Supportamic Laravel Package

Product Decisions This Supports

• In-CP support experience for Statamic 6 sites: if your roadmap includes giving editors and clients a help/support surface inside the control panel (support requests, guidance, documentation links, contact routes), this package is a candidate to evaluate rather than build from scratch.
• Build vs. buy for agency support tooling: Mity Digital is a Statamic-focused agency, so this is effectively a productized version of their own support layer. The decision it informs is whether to adopt a vendor's opinionated support workflow versus wiring your own ticket form, help panel, or third-party helpdesk embed into the CP.
• Client handover and post-launch support: relevant to agencies shipping Statamic sites where reducing "how do I...?" emails and routing issues into a structured channel is a retention and CSAT lever, not just an engineering detail.
• Platform standardization across a portfolio: if multiple sites run Statamic 6, a shared support addon creates a consistent support entry point across clients, which is easier to onboard and train than per-site bespoke implementations.
• Roadmap gating on Statamic 6: the package targets Statamic 6 specifically. That constrains the decision — adopting it is implicitly a commitment to staying on Statamic 6's addon ecosystem, and it should be sequenced with your Statamic upgrade plan, not before it.
• Not a decision driver: this is not a core commerce, content, or performance dependency. It is a support-surface convenience with a single-vendor maintenance path, so it should be treated as a low-blast-radius, reversible decision.

When to Consider This Package

Consider it when:

• You are already on Statamic 6 and adding support features is on the near-term roadmap.
• You want an in-CP support entry point and would otherwise spend engineering time designing forms, permissions, and CP navigation yourself.
• You are comfortable with a single-vendor dependency and are prepared to read the source, since there is essentially no community signal to lean on.
• The scope matches what Mity Digital actually ships — verify the feature list in the repo and in a staging install before committing. "Support features" is broad; the real surface area (ticketing? help docs? contact routing? notifications?) determines whether it fits.
• You can pin the version and absorb maintenance risk — meaning you have a named owner who will track Statamic 6 minor releases and patch or fork if the vendor goes quiet.

Look elsewhere when:

• You need multi-channel support (email piping, SLA tracking, agent assignment, reporting). A dedicated helpdesk (Help Scout, Zendesk, Front) or a thin CP link to one will beat a small addon on capability.
• You need evidence of adoption before standardizing. With 0 stars and 0 dependents, there is no third-party validation, no community troubleshooting, and no signal on long-term maintenance. A recent release date is a positive sign of activity but not of durability.
• Your bus factor tolerance is low. One agency maintaining one addon for one Statamic major version is a concentrated risk; the package's lifecycle is tied to both Mity Digital's priorities and Statamic 6's support window.
• You are not on Statamic 6 or have an upgrade pending — waiting costs nothing here.
• A few hours of in-house work would produce a support form and a CP nav item that meets 80% of the need with none of the dependency risk.

How to Pitch It (Stakeholders)

For executives: This is a small, low-cost option for adding a built-in support channel to Statamic sites, sourced from an agency that specializes in the platform. It is a convenience layer, not infrastructure — treat it as an experiment, not a standard. The main caution is that it has no measurable adoption yet, so we should pilot it on a single site and avoid making it a portfolio-wide dependency until it has proven itself over a couple of Statamic release cycles.

For engineering: Evaluate it as a buy-versus-build shortcut for CP-side support features on Statamic 6. Before adoption we need a source read-through and a staging trial covering: what it actually adds to the CP, permission and role behavior, upgrade safety across Statamic 6 minors, configuration surface, and whether it introduces migrations or data we'd be locked into. Assume we own the fork if the vendor stops maintaining it, so keep our integration thin — a wrapper or feature flag so it can be removed without touching application code.

Recommendation: Time-boxed spike (one to two days) on a non-critical Statamic 6 site. Adopt only if it demonstrably replaces custom work and the code review is clean; otherwise implement a minimal in-house support entry point and revisit if the package gains adoption.