Mite Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for time-tracking integration. This package turns "we need to talk to mite" from a bespoke HTTP client project into a configuration task. The decision it unlocks is whether mite is the system of record for billable hours and whether we integrate directly versus through an existing PSA/accounting tool that already syncs.
• Feature bets on utilization and profitability reporting. The typed coverage of time entries, grouped reports, daily aliases, customers, projects, services and users is exactly the surface needed for utilization dashboards, project margin views, and "hours by customer/service" rollups — the raw material for roadmap items like capacity planning and realization-rate reporting.
• Incremental sync and audit features. Read-only DTOs plus a changes feed make it feasible to build a local mirror of mite data for reporting (avoiding API round-trips on every page load) and to support audit/history features without full re-fetch crawls.
• Lightweight "what is the team working on right now" surfaces. The tracker resource supports status widgets, standup views, and Slack/Teams bots — cheap, high-visibility features that don't require new backend domain modeling.
• Write-path features with bounded risk. Input DTOs with partial-update semantics mean we can ship time-entry editing, bookmark management, and project/customer maintenance from our own UI without hand-rolling merge logic or risking field clobbering on update.
• Roadmap dependency to track: ETag/If-None-Match caching is planned, not shipped. Any roadmap item assuming cheap polling (frequent change-feed sync, near-real-time dashboards) should be scoped with full-payload polling costs until that lands.

When to Consider This Package

Consider it when:

• Our stack is Symfony-based PHP and mite is (or will be) a data source or system of record for time tracking.
• We need broad, typed coverage rather than one or two endpoints — the value here is breadth (account, entries, grouped reports, tracker, bookmarks, customers, projects, services, users, changes feed).
• We want compile-time-ish safety and clear failure modes: read-only DTOs, enums instead of magic strings, and a distinct exception per mite error status behind a single MiteExceptionInterface — meaningfully cheaper to handle and test than raw Guzzle calls.
• We want config-driven setup (domain, api_key, user_agent, http_client) rather than a hand-rolled client, and we want to inject our own HTTP client for logging, retries, or proxy/timeout policy.
• The integration is internal tooling or a bounded product feature, where a young single-maintainer package is an acceptable dependency risk.

Look elsewhere — or plan to wrap it — when:

• The application is Laravel, not Symfony. This ships as a Symfony bundle. Laravel does not consume bundles; there is no service provider, no facade, no config publish. We would be using the bundle's underlying services via manual wiring or need a thin Laravel adapter we own. That adapter is real work and belongs in the estimate.
• We need official/vendor-backed support. mite is a small vendor and this is a community package; nothing here indicates mite itself endorses or maintains it.
• We need write operations beyond what's covered, webhooks, attachments/file uploads, or fine-grained permission handling — verify coverage against our actual flows before committing.
• We need caching or rate-limit strategy on day one. ETag support is planned, not delivered; polling-heavy designs must account for that today.
• Dependency-policy constraints apply (security review, licence review, maintainer-count/health thresholds, long-term support commitments). v1.0.0 with a single maintainer likely fails a strict third-party intake process; the mitigation is a thin internal abstraction layer so we can swap the transport.
• We are not on PHP at all, or we only need a one-off script — a few curl calls may be cheaper than a dependency.

How to Pitch It (Stakeholders)

For executives (one paragraph): We can integrate mite time tracking into our product and internal reporting in days rather than weeks, with a ready-made, typed client for essentially every mite resource — time entries, grouped and daily reports, customers, projects, services, users, the tracker, and a changes feed for incremental sync. That directly supports the utilization, project-profitability, and "who's working on what" features on the roadmap. It's a small community package from a single maintainer on a first stable release, so we should treat it as a replaceable component: adoption cost is low, and we'll isolate it behind a thin internal layer so a future swap or self-maintenance is a contained change, not a rewrite.

For engineering leads: Configuration-driven Symfony bundle (domain, api_key, user_agent, http_client) — we inject our own HTTP client, so observability, retries, and timeouts stay ours. Typed service per resource, read-only DTOs, enums, input DTOs with partial-update semantics, and one exception class per mite error status behind MiteExceptionInterface — predictable error handling and straightforward test doubles. Two caveats to design around: (1) it is a Symfony bundle, not a Laravel package — if we're on Laravel we own a small adapter (service provider + config mapping), and that work should be estimated explicitly; (2) ETag/If-None-Match caching is planned, not shipped, so don't design a high-frequency poller against it yet. Recommend we wrap the services behind our own interfaces so vendor churn is a one-file change, and pin the version.