Розробляю вебзастосунки, у яких інтерфейс не можна відокремити від бізнес-правил, даних та експлуатації. Це адмінпанелі, внутрішні робочі місця, звіти, API й інтеграційні сервіси. Для таких завдань зазвичай використовую React і TypeScript на клієнті, Node.js на сервері, PostgreSQL або SQLite для зберігання. Astro залишаю контентним сайтам: якщо головна цінність продукту — тривала сесія користувача, складні форми та стани, потрібен прикладний інтерфейс, а не маркетингова сторінка.

Якщо оператори досі живуть в Excel, пакетах PDF і папках сканів, додаю контур на Python (або Node), щоб дані доходили до дашборда чи ERP без копіювання руками. Приклади: GDCExcelWorker, PDFImageMerger, PDFPagesManager.

Роботу починаю не з переліку екранів, а з критичного сценарію та джерел даних. Хто створює сутність, хто може її змінити, що відбувається за повторного запиту, як оператор дізнається про збій? Відповіді визначають модель даних, API й ролі раніше, ніж вибір бібліотеки таблиць. Для наявного продукту спершу перевіряю залежності, збирання, міграції та шлях випуску; переписування з нуля пропоную лише тоді, коли його користь можна довести.

Межа послуги проходить по програмному продукту. Я можу зібрати інтерфейс, серверну частину, авторизацію, погоджені інтеграції, тести важливих шляхів і документацію запуску. Дослідження ринку, фірмовий стиль або цілодобова підтримка не потрапляють у кошторис автоматично. Приймання ґрунтується на робочих сценаріях: користувач входить із потрібною роллю, зберігає дані, бачить зрозумілу помилку за недоступності сервісу, а команда може запустити проєкт за інструкцією.

Якщо завдання закриває готова CRM, BI-система чи адміністративний модуль, відповідальніше налаштувати їх, ніж писати заміну. Власний код виправданий, коли процес відрізняється від типового, потрібні особливі права чи інтеграції або інтерфейс помітно впливає на щоденну роботу. Для публічної вітрини без складної сесії краще підійде сусідній кластер маркетингових сайтів; тут зібрані саме застосунки та інженерні складники навколо них.