Інтернет-магазин на Laravel

Коли Laravel потрібен, а коли ні

• Laravel виправданий тоді, коли логіка магазину виходить за межі стандартної. Ціна залежить від контрагента, обсягу і валюти. Залишки живуть у трьох складах і на маркетплейсі одночасно. Оптовик заходить у кабінет і бачить свій прайс, свою відстрочку і свою історію відвантажень. Коробкове рішення тут або переписується плагінами до стану, коли оновлення стає ризиком, або впирається в стелю на першій же нестандартній вимозі.
• І навпаки. Якщо у вас 200 товарів, одна ціна, одна доставка і план продавати — ми скажемо це прямо на брифі й запропонуємо готову платформу. Вийде швидше й дешевше, а зекономлені гроші підуть у трафік. Ми робимо інтернет-магазини на WooCommerce і не вважаємо це компромісом — це просто інший клас задачі.
• Найчастіша причина, з якою приходять по Laravel, — не «хочемо фреймворк», а «поточна система не дає зробити те, що потрібно бізнесу». Це нормальна відправна точка. Тоді розмова починається не з технології, а зі списку того, що зараз робиться руками.

Логіка, заради якої це пишеться

• Ціноутворення, яке не вкладається в налаштування коробки, — прайс-листи на контрагента, знижки за обсягом, персональні умови, кілька валют із курсом, ціна за одиницю виміру, акційні механіки з обмеженнями. Правила задаються в адмінці, а не в коді.
• Кілька складів і резервування — залишок бачиться в розрізі складів, резерв тримається під замовлення, товар підбирається зі складу, ближчого до покупця. Продаж того, чого немає, перестає бути щоденною історією.
• B2B-кабінет — свій прайс, ліміт кредиту, відстрочка, повторне замовлення в один клік, рахунок і закривні документи, історія відвантажень. Якщо кабінетів багато й у них свої ролі, це вже ближче до веб-додатка за обсягом — скажемо про це до підписання, а не в середині роботи.
• Великий каталог і фільтри — окрема пошукова підсистема (Meilisearch або Elasticsearch) замість SQL-пошуку, стійкість до одруківок у запиті, фасетні фільтри за характеристиками. Як це виглядає в найважчому варіанті — на сторінці магазину автозапчастин.
• Фонові процеси — черги на імпорт прайсів, перерахунок цін, відправку документів і листів. Великий прайс імпортується у фоні: сайт не лягає, менеджер не сидить біля екрана.

Інтеграції

• 1С і BAS — двосторонній обмін номенклатурою, цінами, залишками й замовленнями. Формат погоджуємо з вашим 1С-фахівцем до старту розробки, бо це найчастіше джерело зсуву термінів.
• Оплата — LiqPay і Fondy, картки, Apple Pay і Google Pay, оплата частинами, безготівковий розрахунок для юридичних осіб із рахунком із сайту.
• Нова Пошта — розрахунок вартості, вибір відділення чи поштомата на карті, створення ТТН із адмінки, трекінг у кабінеті покупця.
• Маркетплейси й фіди — вивантаження у Rozetka, Prom, Google Merchant Center і Meta, зі своїми правилами цін і залишків на канал.
• CRM і сповіщення — передача замовлень у вашу CRM або в Apros CRM, лід і статус замовлення в Telegram, листи клієнту й менеджеру.

Код і доступи належать вам

• Стандартний Laravel останньої стабільної мажорної версії, без власного фреймворка поверх фреймворка. Структура папок, іменування, Eloquent, черги, події — так, як написано в офіційній документації. Будь-який Laravel-розробник відкриває проєкт і орієнтується в ньому без нашої участі.
• Схема бази — тільки міграціями, у репозиторії. Ніяких змін таблиць руками на бойовому сервері, які потім неможливо повторити.
• Репозиторій ваш із першого дня, ми в ньому — учасники. Доступи до сервера, домену, платіжок і аналітики оформлені на вашу компанію. Хостинг обираєте ви, прив’язки до нашого немає.
• На здачі — README з розгортанням, опис змінних оточення, схема інтеграцій і формати обміну, інструкція для контент-менеджера. Плюс дзвінок із вашим розробником, якщо він у вас є, або з тим, кого ви наймете потім.
• Тести на критичних шляхах — кошик, оформлення, розрахунок ціни, обмін з 1С. Відсоток покриття нас не цікавить. Цікавить інше: щоб наступна людина міняла код і бачила, що нічого не зламала.