Strava Laravel Package

Product Decisions This Supports

• Integration feasibility and scoping: Lets us evaluate "Sign in with Strava" and activity sync as a real, sized feature rather than a hypothetical. The package absorbs the undifferentiated plumbing (OAuth handshake, token storage/refresh, HTTP client, response mapping), so a spike can validate the user value in days rather than a sprint.
• Build vs. buy on the integration layer: The decision isn't "Strava or no Strava" — it's whether we own the auth/token/rate-limit code. This package makes "buy" (adopt the library) cheap enough that engineering effort is redirected to the differentiated parts: training-load analytics, leaderboards, coaching insights, social sharing.
• Roadmap sequencing for a fitness/activity vertical: Supports a staged plan — (1) connect account + import history, (2) surface activity feed/segments, (3) layer proprietary analysis on top. Each stage has a clear go/no-go gate, and the package makes stages 1–2 low-cost to test.
• Data strategy: Forces an explicit call on whether Strava activity data is a system of record or an enrichment source. Treating it as enrichment (cached locally, refreshed via sync/webhooks) is the safer product posture and shapes the schema and sync design.
• Use-case shortlist to prioritize: activity import and unified feed, segment/leaderboard features, coaching and training-load dashboards, social proof and sharing surfaces, and cohort analytics built on real (not synthetic) activity data.
• Partnership/channel reasoning: Strava's ecosystem is an acquisition channel as much as an API. Adoption cost affects whether we can ship a "works with Strava" listing and use it in positioning.

When to Consider This Package

Consider it when:

• The product is on Laravel/PHP and the team wants Strava read access without hand-rolling an API client.
• You need to de-risk an MVP or internal tool quickly — prototype, demo, or a single-tenant integration.
• The required surface is read-oriented (athlete profile, activities, stats) and fits comfortably inside Strava's published rate limits (roughly 200 requests / 15 min and 2,000 / day per app at the default tier).
• You're comfortable pinning a version and wrapping it behind your own adapter interface so it can be replaced.

Look elsewhere or build in-house when:

• The stack isn't Laravel/PHP — the value is the framework glue, and it evaporates outside it.
• You need write operations, webhook push at scale, or endpoints the wrapper doesn't expose; a thin, well-tested client over the official Strava v3 API may be less friction than working around gaps.
• Strava becomes a core product dependency: 74 stars and a single-maintainer profile means no SLA, no support contract, and real bus-factor risk. At that point, vendor the code or own the integration.
• You have compliance/security review requirements (token handling, data retention, PII in activity data) that a small community package won't satisfy without internal audit.
• You need high-volume sync across many athletes — plan for queueing, backoff, and rate-limit budgeting, which any wrapper only partially solves.

Due-diligence checklist before adoption: PHP/Laravel version constraints, test coverage and CI, token refresh handling, rate-limit/backoff behavior, webhook support, recent commit cadence, open-issue responsiveness, and MIT license compatibility with our distribution model.

How to Pitch It (Stakeholders)

For executives: Strava integration is a credible growth and retention feature for a fitness-facing product, and this package is a free (MIT), low-commitment way to test that thesis. It removes roughly the first several weeks of integration plumbing, letting us validate demand before committing real headcount. The risk is maintenance, not money — it's a small, single-maintainer open-source project, so our recommendation is to use it for discovery and gate production on a short technical spike.

For engineering: It's a thin Laravel wrapper over the Strava v3 API — auth, token refresh, and request handling are the value. Low lock-in by design: we wrap it behind our own repository/adapter interface, pin the version, and vendor or fork if the maintainer goes quiet. The spike should specifically prove OAuth token refresh, rate-limit budgeting, and webhook/sync strategy against our expected athlete volume.

Recommendation: Adopt for the discovery phase and internal build. Approve a time-boxed technical spike (auth refresh, rate limits, sync design), then decide on production adoption with an explicit fork-and-own contingency and a clear trigger for replacing it — either the package stalls or Strava becomes a revenue-critical dependency.