Mixpost Laravel Package

Technical Evaluation

Architecture fit. Mixpost is not a thin library — it is a full Laravel application module (routes, migrations, models, Livewire/Vue UI, Tailwind assets, config, console commands, jobs). It assumes it owns a large surface of the host app: /mixpost route namespace, mixpost_* tables, its own auth/workspace model, its own asset pipeline. That fits cleanly in two scenarios: (a) a greenfield or dedicated Laravel app whose purpose is social publishing, or (b) an existing Laravel monolith where social scheduling is a bounded, separable domain and route/table collisions can be avoided. It is a poor fit for non-Laravel stacks, heavily customized admin UIs, or apps where route/middleware ownership is contested.

Integration feasibility. Composer install plus vendor:publish for config/migrations/assets is a known, low-friction path. The real integration work is not the package — it is the platform side: registering OAuth apps per network, completing Meta/LinkedIn/TikTok app review and permission grants, handling X API paid-tier quotas, and provisioning a queue worker plus a per-minute scheduler. None of that is package-specific, and all of it has multi-week external lead time. Technically feasible; operationally gated by third-party approvals.

Technical risk.

• Platform API churn is the dominant risk. Social APIs deprecate endpoints and change token scopes on their own cadence; the package must chase them, and so must you on upgrade.
• Core/Pro split. The MIT core covers scheduling and publishing; analytics, team permissions, AI captioning, and multi-workspace are Pro-licensed. Feature scoping must be validated against the paid tier before committing, otherwise the "no subscriptions" premise is only partially true.
• Token custody and tenancy. OAuth tokens are stored in your database. If you multi-tenant or expose Mixpost to end users, token encryption, isolation, and revocation handling become your security obligation, not the vendor's.
• Upgrade coupling. Deep Livewire/Vue/asset integration means major-version bumps (Laravel, Livewire) can require forking or patching.
• Idempotency and publish correctness. Duplicate-post behavior on queue retry is worth verifying early — it's a trust-destroying failure for end users.

Key questions.

1. Single-tenant internal tool, or multi-tenant/SaaS with external users? (Determines auth, isolation, and support burden.)
2. Which networks, in priority order, and do we already hold approved developer apps for each?
3. Are Pro-only capabilities (analytics, approvals, workspaces) in scope? If so, budget for the license.
4. Does it live inside the primary Laravel app, or as a sidecar service with SSO?
5. Who owns ongoing platform-compliance work (app review renewals, API version migrations)?
6. What is the exit plan if upstream maintenance stalls — fork, or replace?

Integration Approach

Stack fit. Strong if the host is Laravel 10/11 on PHP 8.1+, MySQL/Postgres, Redis, and S3-compatible storage. Weak-to-poor on Symfony, Rails, Node/Next.js, or .NET — there the realistic pattern is a standalone Mixpost deployment behind a shared identity provider, linked from the primary product, not embedded.

Migration path. Two viable routes:

• Sidecar first: deploy Mixpost as its own app, wire SSO (SAML/OIDC or shared Laravel session via a common user table), link out from the main product. Lowest risk, fastest to value, keeps blast radius small.
• Embedded: install into the primary Laravel app once route/table/asset collisions are cleared and the admin shell can host its views. Higher value (seamless UX, shared data) but requires asset-pipeline and middleware reconciliation.

Recommend sidecar for a 6–8 week proof, then decide on embedding based on user feedback rather than upfront.

Compatibility. Pin and record the support matrix explicitly: Laravel minor, PHP minor, Livewire major, DB driver, cache/queue driver, filesystem disk. Verify Vite/Tailwind version overlap with the host app before embedding — asset conflicts are the most common silent breakage. Confirm the package's published migration set does not collide with existing table prefixes.

Sequencing.

1. Week 0–1: Standalone Docker deploy; connect two networks with test accounts; publish a scheduled post end-to-end.
2. Week 1–2 (parallel, long lead): Start OAuth app registration and platform review submissions for the full target network list — this is the critical path, not the code.
3. Week 2–3: Infra: queue worker with supervision, scheduler at 1-minute cadence, S3 media disk, Redis, Horizon for observability, encrypted token storage.
4. Week 3–5: Identity integration (SSO or shared session), branding, network-policy configuration.
5. Week 5–6: Load and failure testing — token revocation, 429 handling, retry idempotency.
6. Week 6–8: Pilot with a bounded user group; content migration if replacing an incumbent tool.
7. Post-pilot: Decide embed vs. remain sidecar; decide Pro license.

Operational Impact

Maintenance. Treat it as a vendored subsystem, not a dependency. Budget recurring effort for upstream release tracking, Laravel/Livewire major upgrades, and — unavoidably — platform API migrations. Any local patches create fork debt; keep them minimal and documented. Because the free/Pro boundary moves over time, re-verify the feature set at each upgrade rather than assuming parity.

Support. Ticket volume will concentrate almost entirely on connected accounts, not on the scheduling UI. Build a runbook early: reconnect flow, token refresh diagnostics, per-network error surfacing. Internal users need a short training pass on the calendar/queue model; external users need docs on platform-specific constraints (media aspect ratios, Instagram's public-URL requirement, character limits, per-network posting rules) that no package can abstract away.

Scaling. Two independent ceilings. First, publish throughput: bounded by queue worker concurrency and, harder, by per-network rate limits and daily caps — horizontal scaling of workers does not buy throughput past a platform's quota. Second, storage and data growth: media library and per-post analytics tables grow monotonically; plan retention policy and S3 lifecycle rules from day one. Scheduling precision is bounded by scheduler cadence; per-minute cron is the practical floor. Multi-tenant deployments add per-workspace isolation and noisy-neighbor concerns on the shared queue.

Failure modes to instrument for.

• Silent publish failure from expired/revoked tokens — alert on consecutive failures per account, not just job exceptions.
• 429 rate-limit storms during peak scheduling windows — add jitter and per-network backoff.
• Duplicate posts on queue retry — verify or add idempotency keys.
• Media fetch blocked by hotlink protection or expiring signed URLs.
• Scheduler not running in containerized/immutable environments — this fails quietly and halts all publishing.
• Timezone/DST drift in scheduled slots.
• Disk exhaustion on media or backup growth.

Ramp-up. A mid-level Laravel developer reaches productive contribution in roughly one to two weeks; the package's conventions are idiomatic enough that no specialist knowledge is needed for the core. The genuine ramp-up cost is domain knowledge — OAuth lifecycle, per-network publishing quirks, and API review processes — which is not in the codebase and should be assigned to a named owner. Plan for ~0.25–0.5 FTE ongoing operations for a single-tenant internal deployment, higher if exposed to external users or if Pro features must be reimplemented in-house.