Ecologi Laravel Package

Product Decisions This Supports

Whether climate features are a real product line or a checkbox. The package is a few hundred lines of glue over the Ecologi REST API, so the honest cost of a first experiment is a sprint, not a quarter. That reframes the decision from "can we justify funding a sustainability programme?" to "do we have a hypothesis worth a sprint?" If nobody can articulate that hypothesis, the answer isn't "buy a bigger platform" — it's "don't build it yet."

Who pays: the customer or the P&L. This is the most consequential and most overlooked decision the integration enables. An opt-in offset at checkout is customer-funded and margin-accretive (plus a small payment-processing cost); a tree planted per order with no surcharge is a per-unit COGS line that scales linearly with volume and needs a finance sign-off before it ships, not after. The wrapper makes both a one-line config change; the business model behind them is not a one-line decision. Model it per 1,000 orders before choosing.

Where in the lifecycle impact attaches. Because the client can be called from any domain event you already emit — order placed, subscription renewed, referral converted, review submitted, support ticket resolved — the product question is placement and narrative, not feasibility. Post-purchase receipt, renewal anniversary, and acquisition hook are three different experiments with different copy, different audiences, and different cost profiles. Pick one, instrument it, and don't ship all three at once.

Loyalty and retention mechanics with measurable lift. Impact receipts, a running tree count on a profile, and per-subscription offsets are established retention levers in adjacent categories. Low build cost converts these from "engineering programme with a steering committee" into "CRM experiment with a measurement plan" — which means they can be evaluated on retention and repeat-rate deltas rather than on internal enthusiasm.

What to publish, and with what caveats. If finance, legal, or marketing wants "trees planted / tCO₂e avoided" in a dashboard, annual report, or investor deck, this is the read path that puts impact data into your own admin. The decision it forces is editorial and legal, not technical: vendor-reported figures in a public document carry brand and disclosure risk, and the methodology caveats will outlive the headline number. Decide the disclosure posture before the dashboard exists.

Roadmap sequencing for a sustainability theme. Cheap integration lets you scope one product in one market as a probe, and treat a broader programme, a public pledge, or dedicated headcount as a follow-on investment gated on that probe's results — rather than as a prerequisite for starting.

Build vs. buy, correctly framed. This is not "build a climate platform vs. buy one." It is "adopt a small open-source client vs. write a small HTTP client." Framing it that way correctly lowers the bar for experimentation — but it must not be mistaken for a strategic commitment to Ecologi as a vendor.

Vendor selection, decided consciously and separately. composer require implicitly picks your climate-action partner. Pricing, project portfolio, certification standards, audit posture, and contract terms all follow from that choice. Run it as its own procurement decision with its own owner, exit plan, and review date — it should never arrive as a side effect of a convenient dependency.

Kill criteria you can actually afford to hit. Because the integration is reversible, you can pre-commit to a real stopping rule (e.g., "if opt-in rate is below X% after N weeks, we remove the toggle and keep the internal reporting"). Few product bets come with a genuine, cheap undo — use that.

When to Consider This Package

Consider it when:

• You are on PHP or Laravel with Composer in place. Marginal adoption cost is an API key, a config file, and an afternoon.
• The scope is narrow, flaggable, and reversible — a pilot, one product line, one market, an internal tool — where the wrapper's small surface is an asset rather than a gap.
• You want to learn from real customer behaviour in days before funding a first-class integration or making a public commitment.
• You have already vetted Ecologi commercially — pricing at your expected volume, project mix, certification claims — against your own procurement and disclosure standards.
• You are starting read-only: impact display, badges, receipts, internal reporting. No money moves, so the risk surface is a failed HTTP call.
• Your team is willing to own the dependency, including forking and maintaining it. Assume you are the first serious adopter.

Look elsewhere when:

• You need vendor-backed support, an SLA, or a security disclosure path. Zero dependents and a single maintainer is a lifecycle fact to plan around, not a criticism of the code — but it means the support contract is with nobody.
• You are not on PHP. Don't bridge languages for an HTTP wrapper; call the REST API directly and the package becomes irrelevant to the decision.
• You need guaranteed API coverage. A client this small likely tracks only the common purchase and read paths. If your roadmap depends on carbon-footprint measurement, reporting exports, or webhooks, verify coverage before committing.
• You need resilience engineering as a product requirement — idempotency, retries with backoff, spend caps, queueing off the request path. Wrappers don't own this, and since every write call spends real money, it becomes product-critical rather than plumbing. Budget it as named work, not as "handled by the library."
• Compliance, assurance, or public disclosure is load-bearing. If the numbers feed regulated reporting or an investor commitment, own the integration and the evidence trail rather than delegating them to an unpinned third-party dependency.
• A hard framework upgrade is imminent and an unpinned constraint could block it — or you can't get an owner assigned to the fork.

How to Pitch It (Stakeholders)

For executives — one paragraph: We can put a customer-facing climate feature — a tree planted per order, or an opt-in offset at checkout — in front of real users for roughly the cost of a sprint rather than a quarter. This package is a small open-source connector to Ecologi, an established climate-action platform that handles planting, project funding, and certification on our behalf. The strategic value is optionality: we find out whether customers actually care, and what they'll pay for, before committing headcount, budget, or a public net-zero pledge. Risk is contained — it's a thin, replaceable layer over a documented API, we'll wrap it behind our own interface so it can be swapped, and we'll start read-only so nothing can break checkout. The one decision that is not contained is the choice of Ecologi as a vendor: pricing and commercial terms should get their own review with a named owner and an exit plan, and shouldn't ride in on the back of a convenient dependency. Ask for a scoped pilot with a pre-agreed success metric and a pre-agreed stop rule.

For engineering and delivery: Treat it as reference code you happen to install, not a platform. It's a small object-oriented client for the Ecologi REST API with the usual Laravel service provider and facade; single maintainer, effectively zero downstream adoption. Pin the version, vendor it into the org, add CI, and name an owner on day one — before an incident, not after. Wrap it behind our own ClimateImpactService interface so swapping to a direct HTTP client is a one-file change, and so no call site touches the package directly.

The thing to flag loudly in planning: the write endpoints spend real money. That makes this payments-adjacent despite looking like an ordinary API client. We own, and must schedule, everything the package doesn't provide — idempotency on purchase calls (a retry can double-spend), retry/backoff, queueing off the request path, per-environment spend caps, approval workflow, secret custody and rotation for a token that moves money, reconciliation against Ecologi's own totals, and persistence of the impact records we generate so our reporting survives a vendor exit. Fail-soft is non-negotiable: an offset failure must never fail a purchase.

Ship read-only first, then transactional flows behind flags. Budget half a day to read the source — at this size that's cheaper than any other form of evaluation and more reliable than the README. The genuine ramp isn't code, it's domain literacy: tCO₂e units, the difference between tree planting and carbon offset products, and Ecologi's reporting semantics. That's product work, and it should be scheduled as such rather than absorbed silently by whoever picks up the ticket.