Routific Bundle Laravel Package

Product Decisions This Supports

• Last-mile delivery routing and dispatch: if you're scoping features like multi-stop route optimization, driver assignment, delivery windows, or ETA promises, this package is a reference implementation of the Routific API surface — a fast way to see which capabilities (vehicle constraints, time windows, capacity, priority) are addressable via a third-party optimizer rather than in-house.
• Build vs. buy for optimization: the existence of a thin SDK like this reinforces that route optimization is a vendor decision, not a code decision. The package itself contains almost no product logic — it wraps HTTP calls to Routific. That's a useful data point when arguing to buy the optimization engine and build only the integration, dispatch UX, and customer-facing ETA layer.
• Integration effort estimation: reading the wrapper shows the real work isn't the API call — it's modeling your own data (orders, depots, drivers, shift constraints) into the vendor's visit/vehicle schema, handling async job polling, and reconciling results back into your dispatch system. Budget roadmap accordingly.
• Use cases it validates: meal-kit and prepared-food delivery (Foodcheri's own domain — multi-drop, tight time windows, perishability), pharmacy/grocery same-day, field service scheduling, and any route with 10–200 stops per vehicle per day.
• Roadmap signal on vendor lock-in: a 2017 wrapper with zero dependents is a cautionary input for the "do we abstract the routing vendor behind our own interface?" decision. The answer is almost certainly yes.

When to Consider This Package

Consider it only as a reading reference, not a dependency:

• You're evaluating Routific specifically and want a 30-minute orientation to its request/response shape before reading the official docs.
• You need to justify a spike on routing without spending engineering days — this is a cheap artifact to skim.
• You're on legacy PHP 7 / Symfony-style bundle conventions and already have a vendored fork (i.e., you are Foodcheri maintaining your own code).

Look elsewhere — decisively — if any of the following is true:

• You need production support. Last release 2017-04-14; zero stars, zero dependents, no evidence of maintenance. That is an abandoned package by any reasonable definition, and it puts an unmaintained HTTP client between you and a paid vendor API you're accountable for.
• You're on modern Laravel. A 2017-era bundle predates Laravel's current service-provider and package-discovery conventions, PHP 8.x, and modern Guzzle. Expect incompatibility rather than a clean composer require.
• You're on a current PHP version. Unmaintained packages are a standing security and upgrade-tax liability, and this one sits in your delivery critical path.
• Routific has an official SDK or a plain REST API. It does — call it directly with Laravel's HTTP client. Twenty lines of your own code beats an orphaned dependency, and you own the timeout/retry/observability behavior.
• You haven't yet chosen a routing vendor. Don't let a wrapper pick your vendor. Evaluate Routific, Onfleet, Circuit, Samsara, or a Google OR-Tools in-house build on pricing, SLA, constraint coverage, and geo coverage — then integrate.

PM recommendation: do not adopt. Treat as documentation only. If Routific is the chosen vendor, build a thin, tested, internally-owned adapter (~1–2 engineer-days) behind a RouteOptimizer interface so the vendor is swappable.

How to Pitch It (Stakeholders)

For executives: This is a 2017 wrapper around a commercial routing API, with no stars, no dependents, and no releases in roughly eight years. It is not a foundation to build on. The strategic takeaway is the opposite of "adopt this library" — it's that delivery optimization is a buy decision. We should select a routing vendor on SLA, constraint coverage, and price, and own a small internal adapter so we can switch vendors without touching product code.

For engineering: Skim it, don't install it. It shows you the Routific visit/vehicle payload shape, which shortens your vendor evaluation. Then implement a thin adapter against the vendor's REST API using Laravel's HTTP client, with explicit timeouts, retry/backoff on the async job poll, structured logging, and contract tests against recorded fixtures. Keep the interface vendor-neutral (optimize(route request): route plan) — that interface is the durable asset; the SDK is not.

Ask: approve a one-week spike to (a) evaluate Routific against one alternative, (b) prototype the adapter, and (c) size the data-modeling work for orders, depots, drivers, and time windows. Do not allocate any roadmap time to integrating this package.