Shipping Laravel Package

Product Decisions This Supports

• Checkout shipping quotes for the Iranian market — surface Sefarshi (registered/ordinary) and Pishtaz (express) postage in the cart before payment, which is one of the highest-leverage fixes for abandonment at the shipping step.
• Free-shipping thresholds and promotions — once rates are computable per weight band and destination province, we can model margin impact of "free shipping over X" instead of guessing.
• Fulfillment method selection — standard vs. express becomes a real product choice at checkout, which in turn drives delivery-promise copy, ETA messaging, and carrier prioritization.
• Build vs. buy for the shipping domain — adopt as a thin rate-calculation dependency rather than re-implementing Iran Post tariff tables and weight-band rules in-house.
• Roadmap sequencing — accurate postage is a prerequisite for launching paid checkout, COD, and multi-shipment orders; this shortens the critical path.
• Architecture decision — the package's driver pattern is evidence that a carrier-abstraction seam is worth standardizing on, even if we later replace the package itself.
• Explicitly out of scope — tracking, label printing, pickup scheduling, and returns. This is rate calculation only; don't let it inflate the scope of the shipping epic.

When to Consider This Package

Consider it when:

• The target market is Iran and the carriers you need are Iran Post's Sefarshi and Pishtaz.
• The stack is Laravel/PHP and you want a service class rather than bespoke tariff logic.
• You need weight/destination-based quotes for an MVP and want to defer building a carrier-integration layer.
• You're comfortable with a small, single-maintainer dependency behind your own interface.

Due diligence before committing:

• Verify the Laravel/PHP version matrix — the last release is 2022, so confirm compatibility before estimating work.
• Determine whether it calls live Iran Post APIs or ships static tariff tables; static tables go stale and need a named owner for updates.
• Check test coverage, behavior on unknown weights/destinations, and failure modes when a rate can't be resolved.

Look elsewhere when:

• You operate outside Iran, or need couriers beyond Iran Post (Tipax, Mahex, international).
• You need tracking, labels, pickups, or returns — none of that is in scope here.
• You require vendor SLAs, security review, or long-term support — 24 stars and a 2022 release are maintenance-risk signals, not disqualifiers but not endorsements either.
• Rates must reflect negotiated per-shipment contracts rather than public tariffs.

How to Pitch It (Stakeholders)

Executives: This is a small, low-cost component that lets us quote real postage at checkout in the Iranian market in days rather than weeks, unblocking paid checkout with accurate totals and an express-vs-standard option. The risk is contained because we intend to isolate it behind our own interface: the project is small and hasn't shipped since 2022, so we treat it as a starting point, not a strategic dependency. No license cost; budget a short evaluation spike plus a fork-and-pin contingency and minimal engineering spend.

Engineering: Adopt it as an implementation detail behind our own ShippingRateProvider contract — the driver-based design is the part worth keeping, but our domain shouldn't couple to a third-party namespace. Vendor or fork it, pin the version, and add integration tests around weight bands, unknown destinations, and provider failure. Define a fallback (flat rate or manual quote) for when rates can't be resolved, and instrument quote latency and failure rate from day one. If the tariff logic turns out to be static, we own the update path — plan for that rather than assuming the package will.