Dotlock Laravel Package

Product Decisions This Supports

• Build vs buy: A 0.1.0 drop is an early signal, not decision-grade evidence. It justifies a time-boxed evaluation spike, not a roadmap commitment or a rip-and-replace of existing glue code.
• Roadmap sequencing: Place in assess/trial, not adopt. Reserve a bounded spike (days, not a sprint) with a named owner and a decision date.
• Architecture direction: Laravel packages are how we avoid bespoke integration code we'd otherwise own forever. Worth tracking whether this fills a gap we currently hand-roll.
• Risk register: Pre-1.0 semver explicitly permits breaking changes. Any dependency here is a standing maintenance tax and an upgrade-path unknown.
• Vendor/exit planning: One release from a package with no track record is concentration risk. Before it touches a committed surface, document the exit path (fork, wrap-and-replace, or remove).

When to Consider This Package

Consider a spike when:

• The capability it targets is on our near-term roadmap, and the alternative is writing and maintaining equivalent Laravel integration ourselves.
• Its surface is narrow enough to wrap behind our own interface, making a later swap cheap.
• The team has spare capacity to read the source and form an independent quality judgement.

Look elsewhere, or wait, when:

• It is pre-1.0 — no backward-compatibility policy, no documented upgrade path, no security disclosure process, no maintenance cadence, and no real-world usage signal beyond the initial publish.
• It sits on a committed path (auth, payments, data integrity, PII) where an unannounced breaking change is expensive to absorb.
• A maintained first-party or widely-adopted alternative already covers the need.

Re-evaluate at 1.0.0, or once there is visible release cadence and substantive changelogs — that is the point the evidence base actually changes.

How to Pitch It (Stakeholders)

Executives: This is a first release of a Laravel/PHP package — one data point, not a track record. It is cheap to evaluate and expensive to depend on prematurely. Recommendation: a bounded spike with a named owner and a decision date, not adoption. No budget or delivery commitment requested.

Engineering: 0.1.0 means semver permits breaking changes at any time; assume the public API will move. If we prototype, isolate it behind an internal adapter and pin the version, so removal is a swap rather than a rewrite. Report back on code quality, test coverage, and maintainer responsiveness — that is the evidence that would justify a real recommendation.

Caveat to record: The release notes contain only "First release" — no features, fixes, or deprecations. This assessment is based on version posture alone and should be revisited once substantive release notes exist.