Support Laravel Package

Product Decisions This Supports

• Build vs. buy / depend vs. vendor: maxfactor/support is a small grab-bag of helper code, not a capability you buy. Its existence tips the decision toward build (or copy) rather than depend — the surface area is small enough that internalizing the useful parts is cheaper than carrying a dependency.
• Roadmap: none. This package does not unlock a feature, a market, or a customer segment. It should never appear on a roadmap as an enabler or a milestone. Treat it as infrastructure glue at most.
• Architecture and standards decisions: whether to consolidate project-wide helpers into a shared internal Support namespace, and whether to standardize on Laravel's first-party Str / Arr / Collection utilities instead of third-party helpers. This package is useful mainly as a reference implementation for that conversation.
• Use cases where it earns its place: (a) an existing legacy codebase already requiring it, where removal costs more than keeping it; (b) a throwaway prototype or internal tool where a helper shim saves an afternoon and the code will not be maintained; (c) reading its source to lift one or two specific helpers during a refactor.
• Explicitly not supported: treating it as a foundation layer, a compatibility shim across Laravel versions, or anything a security or reliability review would need to sign off on.

When to Consider This Package

Adopt only when all of the following hold:

• You already have a Maxfactor/Dews sign-era codebase in production that depends on it, and the migration cost of removing it exceeds the cost of leaving it in place.
• You have opened the source and identified the exact helpers you rely on; the package is unmaintained since March 2020, so framework and PHP compatibility for Laravel 9/10/11 is unverified and must be tested before any upgrade.
• You accept that there is no support path: 3 stars, 0 dependents, and a single maintainer mean no community triage, no security patching, and no issue-response expectation.
• The MIT license makes vendoring the useful pieces into your own codebase legally and practically trivial — which is usually the better answer than adding the dependency.

Look elsewhere — or do nothing — when:

• You are starting a new service. Use Illuminate\Support (Str, Arr, Collection, Number, Sleep) or your own app/Support namespace with tests.
• You need maintained support, a security response process, or any form of compatibility guarantee.
• Your team would be the only adopters. Zero dependents means you are the de facto maintainer of anything built on it.

How to Pitch It (Stakeholders)

Executives: This is a tiny, MIT-licensed utility crate from 2020 with a single maintainer and no downstream adopters. It carries no procurement cost and no vendor lock-in, but it also carries no strategic value — it is not a platform bet and does not affect the roadmap. The recommendation is to treat it as reference material rather than a dependency: zero incremental budget, zero ongoing vendor risk.

Engineering: Read it, don't depend on it. If a helper is genuinely useful, copy it into our own Support namespace with a test and an attribution comment — the MIT license permits this and it removes the upgrade risk entirely. Do not add a dormant, single-maintainer, zero-dependent package to composer.json for any new service; if a legacy service already requires it, pin the version, add a test that exercises the helpers we actually use, and log it as technical debt with a removal ticket rather than a migration project.