# Заклала засадничі рішення платформи в тижні після відкриття репозиторію в листопаді 2025 року — поділ на рівні, доступ до даних передусім через базу даних та планку без жодних попереджень — і вони тримаються дев'ять місяців потому. 2025 **Ситуація.** Репозиторій відкрито 25 листопада 2025 року, і в ньому не було нічого. Те, що вирішується в перші кілька тижнів такого проєкту, має непропорційну вагу: поділ на рівні, місце, де дозволено жити бізнес‑логіці, планка якості. Такі рішення дешево ухвалювати на третій день і майже неможливо скасувати на шостий місяць, бо на той момент усе написане відтоді вже на них спирається. **Завдання.** Засадничі рішення мали бути ухвалені свідомо й рано, причому в такій формі, щоб вони пережили передачу іншим людям і кодовій базі, значно більшій за ту, що існувала на той час. **Дія.** Основну роботу зробили три рішення. Стек поділено на рівні так, щоб кожна частина мала одну роботу — фронтенд на Next.js, Go API, який валідує й передає далі, рівень функцій PostgreSQL, якому належать бізнес‑правила, — замість того щоб логіка опинялася там, де було зручно того дня. Доступ до даних із самого початку сховано за збереженими функціями, і саме з цього рішення випливає все інше, що стосується бази даних; впровадити його заднім числом означало б переписати кожен обробник. А планку нульових попереджень запроваджено ще до того, як з'явилося багато коду, який треба їй підпорядкувати, бо стандарт, уведений на коміті 5 000, — це проєкт із прибирання, тоді як той самий стандарт на коміті 50 — це просто те, як працює репозиторій. Жодне з цих трьох рішень не було легким варіантом на той момент, і всі три коштували темпу в перший місяць. **Результат.** Через дев'ять місяців і кілька тисяч комітів усі три тримаються: рівні не розмилися, жоден обробник не звертається до таблиці напряму, а білд і досі не має жодного попередження. Саме таку перевірку варто застосовувати до засадничого рішення — не чи звучало воно правильно, а чи пережило воно зіткнення з обсягом роботи, що прийшов далі, бо саме в цій точці зручні рішення зазвичай тихо полишають. --- - Роль: Керівник інженерії - Категорії: [Архітектура платформи](https://software.engineer.company/uk/categories/platform-architecture/), [Архітектура рішень](https://software.engineer.company/uk/categories/solution-architecture/), [Backend‑розробка](https://software.engineer.company/uk/categories/backend/), [Frontend‑розробка](https://software.engineer.company/uk/categories/frontend/), [Full‑Stack розробка](https://software.engineer.company/uk/categories/full-stack/), [Бази даних](https://software.engineer.company/uk/categories/databases/), [DevOps](https://software.engineer.company/uk/categories/devops/), [Безпека](https://software.engineer.company/uk/categories/security/), [Керівництво командою](https://software.engineer.company/uk/categories/team-leadership/), [Технічне лідерство](https://software.engineer.company/uk/categories/technical-leadership/) - Послуги: [Архітектура платформи та рішень](https://software.engineer.company/uk/services/platform-architecture/), [Backend- та API‑розробка](https://software.engineer.company/uk/services/backend-development/), [Frontend‑розробка](https://software.engineer.company/uk/services/frontend-development/), [Full‑Stack продуктова розробка](https://software.engineer.company/uk/services/full-stack-development/), [Технічне лідерство та консалтинг](https://software.engineer.company/uk/services/technical-leadership/)