37Signals Laravel Package

Product Decisions This Supports

• Whether "Sign in with Basecamp / 37signals" becomes a supported auth option. The package answers a narrow, concrete question: can we offer 37signals identity to our users at low cost? If a meaningful slice of your target users live in the Basecamp ecosystem (agencies, 37signals-shop consultancies, Basecamp Marketplace partners), this is a cheap way to test demand for that login path before committing roadmap time to a first-class integration.
• Build vs. buy for the OAuth driver itself. The realistic alternative is writing a Socialite driver in-house (~100–200 lines plus tests). This package is a thin, forkable wrapper around Socialite's standard contract, so the decision is not "adopt a platform" — it is "spend half a day vendoring a community driver or a day and a half writing our own." That reframes the build/buy call around maintenance ownership rather than capability.
• Marketplace / partner-integration onboarding. If the roadmap includes listing in the Basecamp Marketplace or building a companion app for Basecamp customers, this provider shortens the "let a Basecamp user connect their account" milestone to configuration work. It de-risks the onboarding step so discovery effort can go to the actual product value behind the login.
• Internal tools and one-off client work. For an internal dashboard or a client-specific integration, this is a defensible "just use it" call: small blast radius, familiar Socialite API, no new operational surface.
• Explicitly not an API integration decision. The package handles identity only. Nothing here gets you Basecamp project, todo, or message data — a Basecamp API client is a separate scoping exercise that this package should not be credited with. Keep those roadmap items separate so estimates stay honest.
• Vendor-risk budgeting. With 7 stars, a single 2020-era release, and a changelog that only says "Support PHP 8," the PM decision this most informs is containment: adopt as a vendored/forked internal dependency, or defer until someone owns it. That is a resourcing decision, not a feature decision.

When to Consider This Package

Consider it when all of the following hold:

• You are on Laravel with Socialite already in production, and PHP 8+. The provider plugs into Socialite::driver('37signals') and the standard SocialiteWasCalled listener — no new concepts for the team to learn.
• 37signals/Launchpad identity is the specific thing you need — your users are Basecamp customers and expect to sign in with that account, not Google or email magic links.
• Login is the whole scope. You need a user identity and profile; you do not need to call Basecamp APIs on the user's behalf (and if you do, you are signing up for token refresh, scope management, and rate-limit handling that this package does not provide).
• You can accept a low-maintenance, community-owned dependency. That means either (a) the surface is small enough that breakage is a config-level fix, or (b) someone on the team is willing to fork and patch it.
• Time-to-signal beats time-to-perfection. A spike or beta where a working OAuth flow this sprint is worth more than a fully owned driver next quarter.

Look elsewhere — or build in-house — when:

• You are not on Laravel/Socialite, or on PHP 7 with no near-term upgrade. The single release note is a compatibility fix; there is no evidence of a maintained support matrix.
• Authentication is a strategic, revenue-bearing surface with SLAs, security review requirements, or compliance obligations. A near-dormant package with one published release and a subtree-split repo structure should not sit in that path unpinned and unforked.
• You need Basecamp API access, webhooks, refresh tokens, or granular scopes — that is a different package and a different estimate.
• Your dependency policy requires active maintenance, security advisories, or a named maintainer. There is no signal of that here; treat it as unmaintained-but-stable until proven otherwise.
• You would have to pin an old Laravel or PHP version to make the constraints resolve. Do not let an auth convenience dictate your framework upgrade calendar.

How to Pitch It (Stakeholders)

For executives — the one-paragraph version: This is a small, low-cost, reversible bet that lets users sign in with their Basecamp/37signals account using the same login plumbing we already run. It is not a platform commitment and it is not a vendor lock-in: the code is a thin adapter over a standard interface, so if it stops working we can replace it in roughly a day. The trade-off is that it is community-maintained with a single release in 2020, so we should adopt it pinned and, if the feature proves out, budget a small amount of engineering to own our own copy. Recommend: approve as a time-boxed spike or behind a feature flag; do not treat it as a supported enterprise auth path.

For engineering — the ask: Spike the provider on a branch against PHP 8 and your target Laravel version. Confirm the dependency constraints resolve, that the Launchpad OAuth flow completes end-to-end in staging, and that the returned user object carries the fields we need. Wrap the driver in a thin internal adapter so a future fork or replacement does not touch domain code, pin the version, and record the fork-and-patch path in the runbook. Budget half a day for validation, not for feature work — the release note describes a compatibility bump, not new behavior.

Success signals to watch: the flow completes without deprecation noise on PHP 8.1+; login conversion for the 37signals cohort; how many users actually choose this option over existing providers. Kill criteria: unresolvable dependency conflicts, no completable auth flow on current runtime, or zero adoption after the trial window — in which case remove the provider and keep the adapter seam.