Four Tochki Products Laravel Package

Product Decisions This Supports

Verdict up front: this package should not drive a product decision today. It is a single-vendor, zero-adoption, Russian-language module with no documented public API. The only decision it can responsibly support right now is "do we spend 2–3 days spiking this, or write our own integration?" Everything below is framed at that level of confidence.

• Category sourcing / dropship feasibility (the real decision). The package is scoped to 4tochki's product catalogue and partner warehouse list (b2b.4tochki.ru/Account/AvailableWarehouses). That makes it relevant to one decision: can we sell wheels/tyres sourced from 4tochki's B2B network without building a custom catalogue pipeline? If tyre/wheel adjacency is not on the roadmap, this package is irrelevant regardless of quality.

• Build vs. buy — buy is not currently the obvious answer. The package ships schema, Doctrine migrations, asset installers and a test group. It does not document an HTTP client, authentication flow, rate limits, or a single service class/endpoint in its README. That means the "buy" option likely still requires us to write the entire 4tochki API client ourselves, on top of an unfamiliar third-party data model. Buying a schema is not the same as buying an integration.

• Platform-fit correction that changes the estimate. The package is described as Laravel/PHP, but every documented command is Symfony: bin/console baks:assets:install, doctrine:migrations:diff, doctrine:migrations:migrate, PHPUnit test groups. Treat this as a Symfony bundle, not a Laravel package. If our stack is Laravel, adoption cost is not "composer require" — it is a Doctrine/Eloquent bridging exercise or a sidecar service. That is a roadmap-level cost, not a task-level cost.

• Roadmap sequencing (only if the spike passes). Phase 1 — read-only catalogue and warehouse import into our own tables. Phase 2 — stock/price sync with conflict rules. Phase 3 — order/fulfilment. Do not commit Phase 2 or 3 to a roadmap until Phase 1 proves the underlying data is usable.

• Use cases the package could plausibly serve, if it works: a B2B tyre/wheel storefront needing 4tochki catalogue + per-warehouse availability; a regional distributor routing orders to the nearest 4tochki warehouse; an internal ops tool replacing manual SKU entry. Note that all three presuppose a working API layer that the repository does not currently evidence.

• Data-quality flag for the decision log. The package shows 0 stars, 0 dependents, release notes that read literally v7.4.12 with no changelog, and a latest release date in the future relative to normal release cadence. Version 7.4.12 on a package with no visible adopters suggests internal versioning for a single consumer, not a maintained public library. Budget accordingly: no upstream support, no security response, no upgrade path.

When to Consider This Package

Adopt (or, more accurately, pilot) only if all of the following hold:

• 4tochki is a confirmed, material supplier — ideally already engaged commercially, with B2B credentials in hand. Without an account, the package cannot be evaluated at all.
• You are on PHP 8.4+ and comfortable with Symfony/Doctrine — or willing to run it as a separate service rather than inside a Laravel app.
• You need schema and entity definitions more than you need a working client, and your team can read Russian or can machine-translate a short README.
• The integration is low-blast-radius: catalogue read, internal tooling, or a non-customer-facing sync. Not checkout, pricing, or anything a partner's downtime could take down.
• You have accepted that you are the maintainer — no upstream SLA, no community, no changelog.

Look elsewhere if any of these are true:

• 4tochki is not a named supplier. Nothing here generalises; the package is single-vendor by construction.
• You are Laravel-first and want a Laravel-native DX. bin/console, Doctrine migrations and PHPUnit groups are a structural mismatch. A thin Guzzle client against 4tochki's B2B API is likely cheaper than reconciling two ORMs.
• You need production guarantees. No tests are evidenced beyond a group name, no CI badge, no issue history, no dependents. There is no signal of stability.
• You need English documentation, an SLA, or a security review path. MIT licence means no warranty and no obligation to patch.
• You are outside the Russian market or subject to payment/logistics constraints that make 4tochki fulfilment impractical — in which case the whole category is out of scope.
• Alternatives worth pricing first: (a) a bespoke ~200-line API client if 4tochki publishes B2B docs; (b) an existing ERP/PIM connector your ops team already runs; (c) manual CSV import if volume is low. Each of these has a known owner and a support path — this package does not.

Cheapest responsible next step: a 2-day, timeboxed spike — install, run the migrations, confirm whether any callable 4tochki client exists in src/, and report back. Fund nothing beyond that until the spike returns.

How to Pitch It (Stakeholders)

For executives — the honest version:

"There's an open-source module for integrating with 4tochki, a Russian tyre and wheel B2B supplier. It could shorten an integration if we decide to sell that category — but I want to be straight about the evidence: zero known users, one author, Russian-only docs, no changelog, and the codebase is Symfony while our stack is Laravel. It looks like an internal module someone published rather than a product.

I'm not asking for budget to adopt it. I'm asking for two engineering days to answer one question: does this contain a working 4tochki client, or just database schema? If it's just schema, we write our own — probably faster than adapting theirs.

The strategic decision this informs is whether tyre/wheel sourcing via 4tochki belongs on next quarter's roadmap. That decision is worth making on supplier terms and margin, not on the existence of a library. The spike just tells us the engineering cost of the yes."

For engineering — the working summary:

• What it actually is: baks-dev/four-tochki-products, MIT, v7.4.12, PHP 8.4+. Despite being tagged Laravel/PHP, the documented surface is Symfony: bin/console baks:assets:install, doctrine:migrations:diff/migrate, php bin/phpunit --group=four-tochki-products. Assumed to be a Symfony bundle providing Doctrine entities + migrations for 4tochki product/warehouse data.
• What's missing and must be verified in the spike: any HTTP client, auth flow, request/response models, retry/rate-limit handling, error semantics, actual test files, and any usage example beyond install. The README never shows a single line of application code.
• Known trade-offs: zero community, zero dependents, no changelog, no English docs, no security response path. We would own all bugs. Doctrine↔Eloquent friction if embedded in a Laravel app.
• Recommended shape if we proceed: run it as an isolated service (container) that owns the 4tochki data model and exposes a small internal API; keep it out of the main Laravel app. Do not fork or vendor the entities into our domain model.
• Spike acceptance criteria (2 days): (1) installs cleanly on PHP 8.4; (2) migrations run against a scratch DB; (3) src/ contains a callable client we can authenticate with using real B2B credentials; (4) one successful catalogue read. Fail any of these → recommend a bespoke client and close the ticket.
• Fallback cost estimate: a thin Guzzle/HTTP client plus DTOs against 4tochki's B2B API is a small, well-understood piece of work with no third-party dependency risk. In most scenarios this is the better buy.