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