Dime Timetracker Bundle Laravel Package

Product Decisions This Supports

• Build-vs-buy for the time-tracking backend. This repo is a working example of the "build" option: a REST API over users, projects, activities, and timeslips. It shows that entry capture is a low-differentiation, well-understood problem — cheap to build, but the unmaintained state of this package is the honest counterweight. Net effect on the decision: it makes buy (Harvest, Toggl, Tempo, Clockify) the default and forces "build" to justify itself on differentiation, not convenience.
• Roadmap sequencing for the reporting layer. The API surface here is raw entries and CRUD. Our customer value is aggregation — utilization, realization rate, project margin, invoicing exports. This supports a decision to deprioritize building our own entry-capture API first and invest in reporting and integration instead.
• Migration strategy for inherited Dime data. If an acquisition or legacy tooling leaves us with Dime-format data, this documents the schema and read path behind a one-off bridge or export job — it informs scoping, not a permanent dependency.
• Feature scoping for internal timesheets. Use its resource taxonomy and endpoint conventions as a checklist when writing our own spec: projects → tasks → entries, filters, time-range queries. Saves a week of design debate; commits us to nothing.
• Reversibility of the vendor choice. Twelve stars, zero dependents, Symfony2-era baseline. Any adoption is a one-way door. This supports the "spike, don't commit" call: study it, reimplement on our stack, don't take the dependency.

When to Consider This Package

Consider it only as source material, never as a dependency:

• You are on Symfony 2.x/3.x with FOSRestBundle and need a throwaway, internal, read-only endpoint set over an existing Dime database — single tenant, behind the firewall, short-lived.
• You need a domain-model reference while designing your own time-tracking schema or a checklist of REST resources.
• You are doing migration discovery and want to see how Dime entities were exposed historically.
• You accept it as fork-and-own code with a named internal maintainer and no expectation of upstream support.

Look elsewhere — and default to "elsewhere" — when:

• You are on Laravel. The "Laravel/PHP" framing in the request is wrong. Despite the label, this is a Symfony bundle (DI container, bundle registration, FOSRestBundle, JMS serializer). There is no service provider, no config publishing, and no adaptation shim. Framework mismatch alone is disqualifying.
• You need a supported runtime. PHP 8.x, maintained dependencies, security patching, and PSR-compliant HTTP handling are not on offer. An EOL PHP/Symfony baseline is a standing audit and security finding.
• Money or compliance is in scope. Billing, payroll, invoicing, or anything under SOC 2 / GDPR / time-and-attendance audit should not run on an abandoned 2010s-era bundle. Auth, rate limiting, pagination, and audit logging would all be ours to build regardless.
• You need multi-tenancy, RBAC, or webhooks. None provided; building them erases the "free" advantage.
• You want to ship this quarter. Fork maintenance and framework modernization cost more than a per-seat SaaS subscription for a small team.

How to Pitch It (Stakeholders)

To executives: This is a research artifact, not a dependency. It tells us what a time-tracking REST API looks like, which is enough to size the "build" side of the build-vs-buy call. Recommendation: buy, or build on our own stack — do not adopt. The license is free; the total cost of ownership is not. An unmaintained Symfony2 bundle with no user base means we own every bug, security patch, and upgrade ourselves, on the critical path of billing data. Adopting it has negative expected value. Reading it for a week has a modest, positive one — a saved design cycle.

To engineering: Treat this as git clone, not composer require. It's Symfony2, not Laravel, so there's no drop-in path regardless. Extract three things — the resource map (users / projects / activities / timeslips), the endpoint and filter conventions, and the relational shape — then implement them on our framework with current auth, validation, and observability. Budget a 2–4 day spike. If anyone proposes a hard dependency, the counter-arguments are stacked: no releases, no maintainers, no dependents, framework mismatch, and a one-way door for a commodity capability.

Bottom line: Low strategic value, real maintenance risk, genuinely useful as a design reference. Decision: study and reimplement. Revisit only if we inherit Dime data and need a short-lived internal read bridge.