Senior Full Stack Developer

Проблем: Верига магазини с десетки обекти и стотици служители управляваше HR, склад, ТРЗ, доставки и продажби през разпръснати Excel таблици и ръчни процеси — без единен източник на истина и с нарастващ риск от грешки при мащабиране. Роля: Lead Developer & Technical Owner: проектирах и изградих системата от нулата, водя доставката за двама допълнителни разработчици (336 от 550 PR-а мои, ~90% от 599 слети PR-а минават през мен), изградих quality pipeline (GitHub Actions CI, Pint, PHPStan 9, ParaTest, проверка за SQL write извън транзакция) и поддържам продукцията от край до край: cPanel, cron и queue worker-и, ежедневни бекъпи, scheduler за 51 задачи с ежедневен имейл отчет и миграции върху живи данни. Интеграции: Еконт, Спиди, Box Now (вкл. подписани webhook-ове), PRIM, OpenCart, IMAP, Google Business, банкови файлове, Tuya IoT; контрол на достъпа по роли и категории с IP whitelisting. Предизвикателство → решение: Бърз растеж в зони с пари, наличности и ТРЗ без регресии и прекъсвания на споделен хостинг. → Задължителен quality gate (Pint, PHPStan 9, ParaTest, audit, проверка за транзакции), сервизни класове по домейни, нощен график на задачите с отчитане на натоварването и ежедневен отчет, автоматични бекъпи и прегледан списък с изключения за наследените файлове.

Проблем: Малкият бизнес иска онлайн магазин без да наема разработчик и без да опира до бедни 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 токен.

Проблем: Книгите, които чета, оценявам и искам да прочета, бяха разпилени между приложения и сайтове, а безплатните български книги от Читанка нямаха връзка с Google Books и с личен списък. Роля: Цялостно: Laravel 13 приложение с Breeze + Tailwind, клиенти за Google Books и Читанка (HTTP client + кеш), рафтове през pivot таблица със статус/рейтинг/бележки, страничен четец за текстове от Читанка, вход с Google (Socialite), queued job за препоръки през официалния Anthropic PHP SDK, rate limiting и feature тестове. Предизвикателство → решение: Два външни източника с различни данни и лимити (Читанка ограничава клиентите), сдвояване на Google Books запис с издание в Читанка, и AI препоръки, които не блокират страницата и не предлагат вече прочетени книги. → Отделни Service класове за GoogleBooks, Chitanka и Claude с 24-часов кеш — грешка в единия източник не чупи страницата. Пълните текстове от Читанка се теглят веднъж, пазят се на диска и се странират оттам. GenerateRecommendations job иска структуриран JSON от Claude, маха книгите от рафтовете и сменя старите препоръки в транзакция; таблото poll-ва, докато job-ът върви.

Проблем: Приложението Smart Life не дава удобен начин да се виждат и именуват кой с какво е отключил, да се раздават временни кодове и да се получават известия по имейл, нито API, което да се вгради в друга система (напр. Laravel). Роля: Цялостно: TuyaClient с HMAC-SHA256 подпис (v2), кеширан токен и retry при изтекъл токен; SmartLockService (статус, unlock/lock с ticket → door-operate и fallback, логове, кодове, временни пароли); JSON API + фронтенд на чист JS; защита с bcrypt парола, CSRF и заключване след 5 грешни опита; audit log; cron монитор за аларми с имейл; тестове с fake transport. Предизвикателство → решение: Бравата е на батерии и „спи“ — изпълнява команди само когато е будна; постоянните кодове трябва да се криптират с ticket ключа; лимитът на заявки към Tuya API е малък; а през тази връзка минава отключването на входната врата. → Ticket-базирано отключване с fallback към open-door; офлайн временните пароли се изчисляват в cloud-а и работят без бравата да е онлайн; polling за заявка от вратата само докато табът е видим и до 10 мин; проектът стои извън web root (видима е само public/), задължителен HTTPS и никога изключена проверка на сертификата.

Проблем: Хоби проект за излизане извън уеб разработката: пълен, игрален 2D платформър с класически механики, който се сваля и пуска с двоен клик. Роля: Цялостно: геймплей скриптове на C# (PlayerController с двоен скок, GameManager, пикъпи, препятствия, PatrolEnemy, HitBlock, CameraFollow), Editor инструменти за процедурно генериране на нивото (терен, пропадания, врагове, удароблокове), звук и Windows билд. Предизвикателство → решение: Дълго ниво с много препятствия, което се балансира и пренарежда бързо, и честно наказание при грешка, без да се връщаш в началото. → Нивото се генерира от Editor tool (GameSetupTools.cs), така че разположението се сменя с едно пускане; checkpoint на последното безопасно място при докосване на вода/шипове; удароблокове с брояч и смяна на цвета, бонус живот на всеки 100 кокала кумулативно.

Проблем: Нужда от бързо генериране на съдържание за тестове и проследимост на опити без ръчно въвеждане на десетки въпроси. Роля: Пълен поток: контролери, 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 само в демо контекст.