Product Decisions This Supports
- Offline-first as a differentiator, not a rewrite. Duo lets you test whether "works on a plane / on a flaky warehouse Wi-Fi" is a real buying criterion for your users before committing a quarter of engineering to a custom sync layer. The
WithDuo trait + @duoMeta + Vite plugin path is small enough to prototype in a spike (a day or two), which makes it a cheap way to validate demand for an offline roadmap item.
- Build vs. buy on sync. Optimistic UI + a queued sync engine + conflict handling + schema extraction from Eloquent is genuinely expensive to build correctly. This package is a candidate "buy" (MIT, free) for the narrow case it covers: single-user-scoped CRUD records, IndexedDB, Livewire components. Useful as a reference architecture even if you ultimately don't adopt it — the
Syncable trait's approach to schema extraction and the user() relationship-based ownership is a sensible pattern to copy.
- Feature scoping in the Livewire/Volt stack. The package implicitly constrains which features are "offline-eligible": model-backed lists and forms with simple field types. That's a useful forcing function for prioritization — if a roadmap feature needs offline and can't be expressed as a scoped Eloquent model, it's a separate build.
- Local-first for internal tools and field apps. Highest-fit use cases: checklists, inspections, field data capture, lightweight CRM/todo-style records — verticals where connectivity is genuinely unreliable and the data model is one record per user.
- Adoption as a wedge for Livewire 3+/Volt consolidation. If you're standardizing on Livewire, this reduces the temptation to bolt on a separate SPA just to get offline behavior — a real architectural-cost argument.
- Risk decision, explicitly. With 0 dependents, a WIP banner, 36 stars, and no evidence of production use, this is a bet on a maintainer, not a bet on a market-standard library. That framing should be on the roadmap doc, because it changes the support and on-call story.
When to Consider This Package
Consider it when:
- You're on Laravel + Livewire 3 (or Volt) and offline capability is a differentiator for a specific, bounded workflow — not a platform-wide requirement.
- Your offline data model is simple, per-user, CRUD-shaped, and tolerant of last-write-wins or easy merge rules. No multi-user collaborative editing, no complex relational graphs.
- You can absorb the dependency risk: vendored/forked pin, an engineering owner who can read the PHP and TypeScript, and an exit plan (the trait boundary makes ripping it out relatively contained).
- You're time-boxing a spike to answer "do users care about offline?" — the zero-config trait means a throwaway prototype is genuinely cheap.
- You have a plan for the non-obvious gaps: index/query strategy on the client, large-dataset performance, schema migrations on the browser side, and what happens when a queued sync conflicts after days offline.
Look elsewhere (or build) when:
- Offline is core to the product. A "VERY MUCH A WIP" package with no dependents should not be load-bearing on day one; you'd be adopting an unproven sync engine and inheriting its bugs.
- You need multi-user sync, CRDT-style merge, real-time collaboration, or background sync across devices.
- Your models are relational beyond a single
user() ownership edge. The security model shown (don't put user_id in $fillable, let Duo assign from the user() relation) is narrow by design and won't generalize cleanly.
- You're not on Livewire/Alpine — the whole value proposition is the component transformation, which is irrelevant outside that stack.
- You need vendor support, SLAs, security review evidence, or a maintained CVE process. None of that exists here yet.
- You're on a team without spare capacity to read the source and debug sync edge cases yourself.
Decision rule to write into the doc: green-light only as an experiment behind a feature flag on one bounded workflow, with a named engineering owner and a documented rollback. Never as a foundational dependency.
How to Pitch It (Stakeholders)
For executives: This is a low-cost, low-commitment experiment, not an architecture decision. It lets us test whether offline capability changes user behavior in [specific workflow] — one trait and a layout directive gets us a working prototype. The risks are honest and containable: the package is early-stage and unproven, so we'd isolate it behind a flag on one feature, with a clear exit path. Cost is a spike, not a quarter. If the experiment shows users care, we've validated an investment; if not, we learned it cheaply.
For engineering: The pitch is not "adopt this library." It's "here's a reference implementation of the hard part." The Syncable trait auto-extracts column types, nullability, and defaults from your Eloquent schema into an IndexedDB manifest, and the WithDuo trait compiles Livewire components down to Alpine with x-for/x-text bindings and an optimistic-update + queued-sync path. That's a real design we'd otherwise spend weeks speccing. We can either vendor a pinned fork and own it, or mine it for the pattern and build a thin internal sync layer. Either way, be clear-eyed: 0 dependents, WIP README, no production references — treat the source as a spec, not a dependency. The security note is worth internalizing regardless: never put user_id in $fillable; derive ownership server-side from the relationship.