Online store on Laravel

When Laravel is needed and when it isn't

• Laravel is justified when the store's logic goes beyond the standard. The price depends on the counterparty, the volume, and the currency. Stock lives in three warehouses and on a marketplace at the same time. A wholesaler logs into their account and sees their own price list, their own payment terms, and their own shipment history. An off-the-shelf solution here either gets rewritten with plugins until updating becomes a risk, or hits a ceiling at the first non-standard requirement.
• And the other way around. If you have 200 products, one price, one delivery method, and a plan to sell, we'll say so straight at the brief and recommend a ready-made platform. It comes out faster and cheaper, and the money saved goes into traffic. We build online stores on WooCommerce and don't consider that a compromise; it is simply a different class of task.
• The most common reason people come to us for Laravel isn't "we want a framework", it is "the current system won't let us do what the business needs". That is a fair starting point. Then the conversation starts not with technology but with the list of what is being done by hand right now.

The logic this gets written for

• Pricing that doesn't fit into an off-the-shelf platform's settings: price lists per counterparty, volume discounts, individual terms, several currencies with an exchange rate, price per unit of measure, promo mechanics with limits. The rules are set in the admin panel, not in code.
• Several warehouses and reservations: stock is visible per warehouse, a reserve is held against an order, and goods are picked from the warehouse closest to the buyer. Selling what you don't have stops being a daily story.
• B2B account: own price list, credit limit, deferred payment, repeat order in one click, invoice and closing documents, shipment history. If there are many accounts with roles of their own, the scope is already closer to a web application, and we'll say so before signing, not halfway through the work.
• A large catalogue and filters: a dedicated search subsystem (Meilisearch or Elasticsearch) instead of SQL search, tolerance for typos in the query, faceted filters by attributes. What that looks like in the heaviest case is on the auto parts store page.
• Background processes: queues for price list imports, price recalculation, sending documents and emails. A large price list is imported in the background, so the site doesn't go down and the manager doesn't sit watching the screen.

Integrations

• 1C and BAS: two-way exchange of items, prices, stock, and orders. We agree the format with your accounting system specialist before development starts, because this is the most common source of schedule slippage.
• Payment: LiqPay and Fondy, cards, Apple Pay and Google Pay, payment in instalments, bank transfer for legal entities with an invoice generated from the site.
• Nova Poshta: cost calculation, choosing a branch or a parcel locker on the map, creating waybills from the admin panel, tracking in the buyer's account.
• Marketplaces and feeds: exports to Rozetka, Prom, Google Merchant Center, and Meta, each with its own rules for prices and stock per channel.
• CRM and notifications: orders passed to your CRM or to Apros CRM, the lead and the order status in Telegram, emails to the customer and to the manager.

The code and the access belong to you

• Standard Laravel on the latest stable major version, with no in-house framework on top of the framework. Folder structure, naming, Eloquent, queues, events, all exactly as the official documentation describes. Any Laravel developer opens the project and finds their way around without our involvement.
• The database schema lives in migrations only, in the repository. No manual table changes on the production server that can't be reproduced later.
• The repository is yours from day one, and we are contributors in it. Access to the server, the domain, the payment providers, and analytics is registered to your company. You choose the hosting, there is no lock-in to ours.
• At handoff: a README with deployment instructions, a description of the environment variables, an integration diagram with exchange formats, and a guide for the content manager. Plus a call with your developer, if you have one, or with whoever you hire later.
• Tests on the critical paths: cart, checkout, price calculation, exchange with 1C. The coverage percentage doesn't interest us. Something else does: that the next person can change the code and see that nothing broke.