Full stack Web Developer

Проблем: Верига магазини с десетки обекти и стотици служители управляваше HR, склад, ТРЗ, доставки и продажби през разпръснати Excel таблици и ръчни процеси — без единен източник на истина и с нарастващ риск от грешки при мащабиране. Роля: Цялостно проектиране и разработка: архитектура на 9-те сервизни домейна, HR модул (график, отпуски, ТРЗ импорт от PDF фишове), склад и логистика с интеграция на няколко куриера (Econt, Speedy, Box Now, PRIM доставчик), POS продажби, B2B портал и продажбена фуния, следене на автопарк с живи събития от автомобилите, административен контрол на достъпа по роли и категории с IP whitelisting. Предизвикателство → решение: Една система движи HR, склад, POS, ТРЗ, логистика и B2B за активна търговска верига — всеки модул работи с живи бизнес данни, а кодовата база трябваше да продължи да расте (200+ модела, 2 400+ комита) без да се появяват регресии. → Строг composer quality gate преди всеки комит (Pint форматиране + PHPStan ниво 9 + паралелен PHPUnit + security audit), бизнес логиката е организирана в Service класове по домейни (HR, склад, автопарк, ценообразуване, продажби, B2B…), а за наследения код се поддържа малък прегледан списък с изключения вместо тихо потискане на нови типови грешки.

Проблем: Малкият бизнес иска онлайн магазин без да наема разработчик и без да опира до бедни drag-and-drop конструктори. А мулти-наемната архитектура (един код, много магазини на поддомейни с изолирани данни) и page builder, който изглежда еднакво в редактора и на живо, са нетривиални за изграждане. Роля: Цялостно: мулти-наемна архитектура (`tenant_id` scoping през trait + глобален scope, резолюция на наемателя по заявка хост), Laravel 13 backend, Inertia v3 + React 19 + TypeScript админ панел, page builder с рекурсивни вложени блокове (контейнер „Колони“), Stripe за плащания на витрината и абонаменти на платформата (Cashier), пълна двуезичност (BG/EN), деплой на споделен cPanel/LiteSpeed хостинг с wildcard поддомейни. Предизвикателство → решение: Един и същ набор от секции да се рендира идентично в редактора и на живата витрина; вложени блокове (колони в контейнер) с рекурсивна валидация и drag-and-drop; строга изолация на данните между магазините; отделен hostname с валиден сертификат за всеки магазин на споделен хостинг. → Споделен section registry — една дефиниция захранва и editor canvas, и storefront. Вложените блокове са `Block.columns: Block[][]` с рекурсивни helper-и и React context за рендиране без излишни отстъпи. `BelongsToTenant` trait със скрити глобален scope; наемателят се вади от `$request->getHost()`. Wildcard поддомейн `*.shop.sasho-dev.com` + wildcard TLS, така че нов магазин работи веднага без ръчна настройка.

Проблем: Хора с малко SQL знания трудно пишат заявки с JOIN-ове и агрегации; а и синтаксисът се различава между диалектите (LIMIT / TOP / FETCH FIRST). Роля: Цялостно: визуален query builder на чист JavaScript (сглобяване на SQL, авто-кавички, диалект-специфичен LIMIT), PHP backend с официалния Anthropic PHP SDK и prompt дизайн, отворен REST API с опционален токен и per-IP rate limit, модерен UI без framework с EN/BG превод и превключване тъмна/светла тема. Предизвикателство → решение: Един UI да върши работа и за начинаещи (полета), и за напреднали (свободен текст); надежден валиден SQL за правилния диалект; предпазване на API кредитите при публичен endpoint. → Табове: клиентски builder + ИИ режим споделят подсветка и copy. System prompt с фиксиран диалект и JSON договор + устойчив парсър; file-based fixed-window rate limit; CORS и опционален Bearer / X-Api-Key токен.

Проблем: Нужда от бързо генериране на съдържание за тестове и проследимост на опити без ръчно въвеждане на десетки въпроси. Роля: Пълен поток: контролери, OpenAI услуга, модели, миграции, Blade изгледи и точкуване. Предизвикателство → решение: Надежден JSON от модела, коректен correct_option и таймер/лимит без да се чупи submit на отговорите. → OpenAiService с Chat Completions, AttemptScoringService, UUID за анкета и опит, настройки в конструктора преди старт.

Проблем: Услуги със записани часове (салони, студия, консултации) се нуждаят от ясно моделиране на локации, работно време, услуги и резервации; желателни са API за интеграции и опционални AI подсказки без да се разчита само на ръчно подреждане на слотове. Роля: Пълен Laravel поток: модели и миграции, Blade + Bootstrap 5 UI, Sanctum REST API, конфигурируем OpenAI слой и документация за защитените endpoint-и. Предизвикателство → решение: Достъп до бизнеси и локации по потребител, коректни слотове спрямо продължителност и работни часове; опционални AI функции само при валиден OPENAI_API_KEY. → Домейн модел с venues/services/bookings/customers, wizard за първоначална настройка, JSON API с Sanctum token flow; AI endpoint-и изолирани и активни при конфигурация.

Проблем: Маркетинг и content екипите се нуждаят от един работен поток за статии, ключови думи, конкурентен анализ и публикуване към WordPress, вместо разпилени инструменти и ръчни копирания. Роля: Пълен Laravel поток: CRUD за съдържание, AI генерации, SEO мета, Sanctum API, WordPress интеграция и UI за ежедневна работа. Предизвикателство → решение: Съчетаване на редакторски процес, SEO структура и външни интеграции (OpenAI/WordPress) с предвидимо поведение и бърз UI. → Laravel 13 монолит с модулни секции (статии, keywords, rewrite, competitors, WordPress), централизиран API слой под /api/v1 и UI с Bootstrap 5 + Vite.

Проблем: Нужда от „уеб пощенски клиент“ без инсталация на десктоп приложение, с коректно картографиране на IMAP папки при различни доставчици и опция за интеграции през API. Роля: Пълен Laravel поток: IMAP слой, акаунти и настройки, Blade + Tailwind UI, Sanctum за /api/v1 и документация за клиентите на API. Предизвикателство → решение: Стабилна работа с различни IMAP сървъри, сигурно съхранение на пароли за поща и ясни граници между уеб UI и JSON API. → webklex/laravel-imap + откриване на SMTP/IMAP настройки, шифровани идентиали в профила, отделни маршрути и токени Sanctum за машинен достъп.

Проблем: Феновете и любителите на F1 искат бързо живо табло, календар на уикендите и класирания без тежък SPA или платени източници. Роля: Проект цялостно: PHP API слой към OpenF1, страници за табло / календар / класиране, клиентски JS за опресняване (~5 сек) и UI за Race Control. Предизвикателство → решение: Стабилно показване при различни типове сесии (квалификация без интервали, състезание с интервали), временни грешки от API и смислено кеширане за календар/класиране. → Отделни JSON endpoints (live, calendar по година, standings), клиентско fetch с контрол на опресняването и обработка на празни полета описана в README/ЧЗВ.

Проблем: Нужда от структуриран каталог имоти и съдържание без тежка custom CMS от нулата. Роля: Custom плъгин, тема, CPT, shortcodes и шаблони за архиви. Предизвикателство → решение: Гъвкави филтри и повторна употреба на блокове на началната страница. → CPT + таксономии, shortcodes и консистентни шаблони.

Проблем: WordPress трябва да показва и създава резервации чрез съществуващ Laravel API, без дублиране на бизнес логика. Роля: WordPress плъгин + тема: HTTP към API, форми, списъци. Предизвикателство → решение: Синхрон на dropdown-и (стаи, дати) и коректно ценообразуване в UI. → Единен API договор, валидация на входа и ясни състояния на формата.

Проблем: Салони трябва да управляват резервации и ресурси от едно място. Роля: Плъгин (CRUD, права), тема, shortcode за клиенти. Предизвикателство → решение: Конфликти по часове и ясни роли (клиент / админ). → Моделиране на услуги, служители и слотове с валидация.

Проблем: Нужда от проследяване на посещения и география за анализ без външен SaaS. Роля: Laravel backend, админ UI, export, Swagger, планирани имейли. Предизвикателство → решение: Филтри и обем данни в таблици; четимост на отчетите. → Индексирани заявки, изгледи таблица/карта и насрочени обобщения.

Проблем: Вграждане на живи футболни данни в WordPress без тежък frontend. Роля: Плъгин: API клиент, shortcodes, стилове. Предизвикателство → решение: Лимити на API и кеширане на отговори. → Shortcodes с параметри и разумен кеш спрямо endpoint-и.

Проблем: Хотелският PMS е извън уеб приложението — нужна надеждна синхронизация с външен API. Роля: Backend: команда за sync, модели, опашки, UI за статус и логове. Предизвикателство → решение: Обем, повторяемост и проследимост при грешки от API. → Опашки за асинхронна обработка, логове и експорт след sync за проверка.

Проблем: Моделиране на заеми и график на вноски с проследимост. Роля: Laravel: миграции, модели, Blade UI, seeders. Предизвикателство → решение: Коректни изчисления и състояния на плащания. → Ясна релационна структура и валидация на бизнес правила.

Проблем: Вграждане на чат с OpenAI в Laravel с четим UI. Роля: Backend proxy към API, frontend с Tailwind, обработка на грешки. Предизвикателство → решение: UX на натоварване и отговори от API. → Асинхронни заявки и ясни състояния в интерфейса.

Проблем: Една кодова база за различни типове бизнеси и доставчици. Роля: Модели, Sanctum API, филтри и динамика по доставчик. Предизвикателство → решение: Обобщен модел без да се губи специфика по домейн. → Eloquent връзки и конфигурируеми филтри по контекст.

Проблем: Кредитна логика за българския пазар с лимити и проследяване на статуси. Роля: Laravel приложение: auth, домейн правила, UI с пагинация. Предизвикателство → решение: Валидация на суми и съвкупни лимити. → Централизирана валидация и ясни статуси в базата.

Проблем: Образователна/демо визуализация на изграждане на SQL заявки в Laravel. Роля: Builder клас + Blade UI за SQL и резултати. Предизвикателство → решение: Безопасно показване на генериран SQL (без raw user SQL в прод). → Контролиран builder API и preview само в демо контекст.