Chart Laravel Package

Product Decisions This Supports

• Build vs. buy (the core call): A pre-1.0 Laravel package is a bet that the maintainer's roadmap will track yours for the next 12–24 months. At v0.7.0 the honest framing is rent, not buy — you're buying optionality with a low switching cost, and the decision to keep it should be re-evaluated at every minor bump.
• Roadmap sequencing: If the package owns a capability you'd otherwise staff in Q3, adopting it now can pull a feature forward — but only if the capability is peripheral to your differentiation. Anything a customer would name as why they chose you should stay in-house.
• Use cases where a pre-1.0 package genuinely wins: internal tooling, admin panels, back-office workflows, prototypes validating demand before you commit engineering headcount, and glue code where a rewrite is a day's work rather than a quarter's.
• De-risking a hire or a deadline: a package with one happy-path use case can unblock a launch without creating a permanent maintenance obligation — provided the abstraction boundary is drawn so it can be replaced.
• Composer dependency surface: every Laravel dependency propagates. Adding one pre-1.0 package influences your PHP version floor, your Laravel major-version upgrade timing, and your security-patch cadence — which are product constraints, not just engineering ones.

When to Consider This Package

Adopt it when:

• The capability is commodity — auth scaffolding, PDF generation, CSV import, webhook plumbing, feature-flag wiring — where no customer would ever pay for your version of it.
• You can wrap it behind an interface you own, so the package is swappable in a sprint rather than a quarter.
• The maintainer shows a credible release cadence and the repo has real CI, a changelog, and a security contact. v0.7.0 being the initial release means you are the QA team; that's acceptable for internal tools and unacceptable for a payment path.
• Your team is already fluent in the framework's idioms, so reviewing the package's source is a morning's work, not a research project.
• You're under a deadline where the alternative is shipping nothing.

Look elsewhere — or build — when:

• The package would sit on a revenue-critical or regulated path (billing, PII handling, audit trails). Pre-1.0 means the API can break in a patch release, and "Initial release" at 0.7.0 signals the author is still finding the shape of the problem.
• It duplicates something the framework already ships or that a maintained, versioned alternative covers. Free is not cheaper than supported.
• The capability is your differentiation. Owning it is the whole point.
• There is no deprecation policy, no issue triage, and no clear maintainer — an unmaintained dependency becomes a forced migration timed by someone else's disappearance.
• You need a support contract, SLA, or LTS guarantee. A v0.x package cannot give you one, and no amount of goodwill substitutes for a contract.

How to Pitch It (Stakeholders)

For executives: This is a small, early-stage Laravel dependency that lets us ship a capability without building it. The economics are attractive precisely because it's early — adoption cost is low and the exit cost is low. The risk is that pre-1.0 software has no stability guarantee, so I'm recommending we use it behind our own abstraction layer, confine it to non-customer-facing surfaces for now, and put a formal review on the calendar for each minor release. Ask: approve the dependency for internal tooling; defer any customer-facing or revenue-path use until the package reaches a stable release with a published deprecation policy.

For engineering: Treat v0.7.0 as an evaluation build, not a foundation. Concretely — wrap it behind an interface we own, pin the exact version in composer.json, add a contract test that exercises the behaviours we actually depend on so a future breaking change fails loudly in CI rather than in production, and keep the integration behind a feature flag. Budget roughly a day of engineering review of the package source per adoption, and record a short ADR noting what would trigger removal.

For the wider org: the decision we're really making isn't "is this package good" — it's "how much of our roadmap do we want to outsource, and how cheaply can we undo it." Right now the answer is a little, and very cheaply.