Ozon Support Laravel Package

Product Decisions This Supports

• Resetting the "Ozon channel" roadmap line. The artifact set describes a support/profile-type module: one Composer install plus one console command (baks:users-profile-type:ozon-support) that registers an "Ozon Support" user profile type inside a BaksDev application. Nothing in the README, description, or release notes evidences Ozon Seller API coverage — no OAuth2, orders, pricing, stock, delivery, Ozon Pay, or webhooks. The first decision this package supports is a scope correction: any epic, estimate, or launch plan that assumes marketplace capability must be rewritten before the next planning cycle.

• Build vs. buy — and the defensible answer is "build the small thing." The delivered surface is a registration command and package scaffolding. Weighing that against 0 stars, 0 dependents, one apparent maintainer, opaque release notes, and a hard PHP 8.4 floor, re-implementing the profile type inside our own user model is a lower total-cost-of-ownership option than a permanent third-party dependency. Buy only if engineering's source review shows material logic we would otherwise have to reverse-engineer.

• Laravel fit is a gating question, not a detail. The package is advertised as Laravel/PHP, but the only concrete tooling is Symfony-shaped (bin/console, baks: namespace, PHPUnit group). If our stack is Laravel, this is not a "composer require and go" decision — it is a "adopt a foreign framework convention" decision, and the answer is no.

• Support-operations segmentation, if and only if that is the real need. The legitimate use case is internal: typing agents, tickets, or accounts as Ozon-related within an existing user model so routing, reporting, and permissions can be filtered. That is a genuine but modest operational win — worth a spike, not worth a roadmap slot.

• Dependency policy precedent. MIT license, trivially forkable, no vendor lock-in. This package is a useful test case for a standing rule: adopt third-party code only pinned to an exact version, wrapped behind an internal interface, with a named owner. Version numbers advancing (7.4.13 → 7.4.17) with release notes that repeat the version string are exactly the pattern that rule exists to contain.

• Sizing the opportunity cost. Engineering time here is days, not weeks — but only inside BaksDev. The decision that actually moves metrics is whether Ozon is a channel we sell through. If yes, the critical path is a real Seller API integration and this package is an optional adjacent convenience, sequenced behind it.

When to Consider This Package

Consider it if:

• The application is already BaksDev on Symfony with PHP 8.4+, and the user/profile subsystem is in place. Outside that, the install instructions do not apply.
• The requirement is narrow and named: an Ozon-support profile type so support staff, tickets, or accounts can be typed and segmented.
• Engineering has completed a source review — composer.json requires, the bundle/service-provider class, and migrations — and confirmed the behavior matches the label. The README is roughly fourteen lines; the release notes carry no signal.
• We are prepared to pin an exact version, commit the lockfile, and wrap the vendor type behind an internal adapter so removal is a one-class change.

Look elsewhere if:

• The need is Ozon Seller API integration in any form. Source that separately — official Ozon documentation or a maintained client — and do not let this install be reported upward as marketplace readiness.
• The stack is Laravel or framework-agnostic PHP. The Symfony console tooling is the only evidenced integration path.
• Documentation, changelogs, CI visibility, SLAs, or bus factor matter to the decision. Zero dependents and zero stars mean we own every bug we find, permanently.
• The target market is outside Russia/CIS, where Ozon is not a relevant channel and the Russian-only README becomes pure onboarding cost.
• A PHP 8.4 floor conflicts with our hosting, container base images, or CI matrix — validate that first, because it gates the whole cohort of baks-dev/* packages, not just this one.

How to Pitch It (Stakeholders)

To executives: "This is a small internal support-typing module for Symfony/BaksDev applications, not an Ozon marketplace integration. It can standardize how we label Ozon-related support identities, which is useful if Ozon support volume is already a bottleneck. It will not generate revenue, process orders, or connect us to Ozon's seller systems. My recommendation is a one-week engineering spike with a written capability confirmation before any further commitment — and a correction to any internal narrative that treats this as channel readiness."

To engineering: "Read the source before we plan around it. Confirm whether it makes any outbound call to Ozon or is purely a local profile-type label, what baks-dev/* packages it hard-requires, what schema the command writes and whether it reverses, and what actually changed between 7.4.14 and 7.4.17. If we adopt, we pin the exact version, keep domain code off baks-dev namespaces via an adapter, and wire the --group=ozon-support test set into our own pipeline — because it is opt-in and will not run otherwise."

To the business owner / support lead: "If the goal is segmenting agents and tickets that touch Ozon sellers, this is a cheap, low-risk enabler on our existing stack. If the goal is selling on Ozon, this package does not address it at all, and scoping it as though it does would cost us a quarter."