// компетенція

Розробка ПЗ та платформ

Розробка кастомного ПЗ для enterprise — від MVP до production-ready платформ. З архітектурною дисципліною замість швидких хаків і пошуком бізнес-цінності замість feature-фабрики.

// про практику

Що це і кому потрібно

Розробка ПЗ — це не «найняти 10 розробників на 3 місяці». Це інженерна дисципліна з власною методологією: domain-driven design, архітектурні рішення (моноліт vs. мікросервіси), TDD/CI/CD, code review як обов'язкова частина процесу.

У 2026 ключова перевага — не швидкість delivery, а keepalive якість: чи проєкт через 2 роки залишиться maintainable, чи стане legacy, який «легше переписати ніж підтримувати».

Вам це потрібно, якщо

  • Потрібен кастомний продукт, який не існує на ринку «коробки».
  • Існуюча система потребує реінжинірингу — старий код став блокером бізнес-агресивності.
  • Команда розробки росте, але швидкість delivery падає — час на архітектурний consulting.
  • Готується запуск нового продукту з невідомими ризиками — потрібен досвід проєктування з нуля.
// наша позиція

Чому ми робимо це інакше

01

Швидкість delivery без архітектурної дисципліни — це не швидкість, це борг.

Перший рік feature-фабрики дає illusion швидкості. На другому році команда витрачає 60% часу на refactoring і fixing. Це не bug, а закономірність — без архітектурних reviews кодова база деградує лінійно з часом.

02

Мікросервіси без operational maturity — це distributed monolith, який гірший за моноліт.

Мікросервіси виправдані для команд 50+ розробників з власним DevOps. Для команди з 5–10 — це overengineering, що подвоює complexity без переваг.

03

Code review — це не контроль якості. Це передача знань і training колег.

Команда, де code review — формальність («LGTM»), через рік перетворюється на n окремих експертів, що не розуміють чужий код. Bus factor = 1 для кожного компонента. Це organizational ризик першого порядку.

// чесний фільтр

Коли вам це потрібно — і коли ні

Чесніше сказати «вам це поки не треба», ніж продати engagement, який не дасть ROI.

✓ Потрібно

  • Потрібен custom продукт, відсутній на ринку
  • Існуюча система блокує бізнес-ініціативи
  • Готова інженерна культура (code review, тести, CI)
  • Готовий стратегічний sponsor проєкту на стороні замовника

✗ Поки не треба

  • Можна вирішити готовим SaaS — не варто будувати з нуля
  • Команда без культури тестування — спочатку інженерна зрілість
  • Хочете «MVP за 2 тижні» — кращий шлях через no-code/low-code
// процес

Як ми ведемо проєкт

01

Discovery & domain modeling · 3–4 тижні

Інтерв'ю з власниками процесів, event-storming для виявлення bounded contexts, ризиків. Output — domain model і architectural decision records (ADR).

02

Архітектурний дизайн · 3–4 тижні

Вибір моноліт vs. мікросервіси, технологічного стеку, дизайн API, схема даних, infrastructure-as-code підхід.

03

MVP/Pilot · 3–4 місяці

Перша версія для одного use case з реальними користувачами. Доводить технічну архітектуру і бізнес-припущення до production-якості.

04

Scale-out · 6–18 місяців

Поетапне розширення функціональності, оптимізація performance, додавання нових features за пріоритетом business value.

05

Continuous engineering · постійно

Regular architectural reviews, refactoring sprints, оновлення dependencies, security audits. Без цього код деградує за 12-18 місяців.

Проєкт ведуть: Softengi (custom software, AI/ML systems) та InBase (UnityBase low-code, enterprise platforms).
За потреби долучаються: SL Global Service (cloud-native architecture), Data Management IG (data layer design).

// антипатерни

Типові помилки, на яких ми вже бачили проєкти

Feature factory без архітектурного нагляду

Команда delivery-нула 50 features за рік. На другому році 30% часу йде на bug-fixing, ще 30% — на refactoring. Бізнес запитує чому швидкість впала.

Що робимо інакше: обов'язкові architectural reviews кожного epic, refactoring як частина sprint capacity (не «потім»).

Мікросервіси «на виріст»

Команда з 6 розробників робить 12 мікросервісів «бо це modern». DevOps overhead перевершує бізнес-логіку.

Що робимо інакше: починаємо з моноліту, виділяємо сервіси тільки коли є evidence-based reason: різні scaling profiles, різні release cycles, або teams >50 інженерів.

Тести «коли буде час»

Test coverage <10%. Кожен release — це manual QA на тиждень. Через 18 місяців жоден рефакторинг неможливий.

Що робимо інакше: тести як частина definition-of-done (не optional). Цільовий coverage >70% для бізнес-логіки.

// досвід

Типові сценарії з нашої практики

Без точних відсотків економії — реальні цифри залежать від стартової точки замовника. Натомість — конкретні архітектурні рішення та організаційні зміни.

Банк · CRM-платформа

Custom CRM на UnityBase

Замість впровадження готового CRM — кастомна платформа на UnityBase з інтеграцією до 14 банківських систем. 12 місяців до production, далі — continuous evolution.

Енергохолдинг · workforce management

Заміна Excel-процесів кастомним продуктом

Бізнес-процеси на 200+ Excel-файлах. Кастомна платформа з role-based UI, audit trail, integration з ERP. 8 місяців. Складність — domain knowledge transfer.

Державний реєстр · public API

API gateway з versioning і throttling

Custom API platform для держреєстру, що обслуговує 12 відомств і 200+ зовнішніх consumers. SLA 99.95%. 14 місяців.

// поглиблені матеріали

Що писали по темі

Дев'ять свіжих експертних матеріалів — від тематичних оглядів до конкретних архітектурних рішень.

07.05.2026 4 хв Детальніше →
30.04.2026 3 хв Детальніше →
26.04.2026 3 хв Детальніше →
// стек

Технології, з якими ми працюємо

Backend

Java · Python · .NET · Node.js · Go · PHP (UnityBase)

Frontend

React · Vue · Angular · Next.js · TypeScript · Svelte

Бази даних

PostgreSQL · MS SQL · MongoDB · Redis · ClickHouse · Elasticsearch

Архітектура

Domain-Driven Design · CQRS · Event Sourcing · API-first · Hexagonal architecture

DevOps & QA

Docker · Kubernetes · GitLab CI · GitHub Actions · Playwright · Cypress · JUnit · pytest

Стандарти

ISO/IEC 27001 · OWASP · SOLID · 12-factor app · Clean Architecture

// часті запитання

Поширені запитання

Моноліт чи мікросервіси для нового проєкту?

Майже завжди — модульний моноліт. Мікросервіси виправдані лише для команд 50+ розробників з established DevOps culture. Для всіх інших — overengineering з гірштим operational profile.

Скільки часу займає custom продукт?

MVP — 3–4 місяці. Production-ready — 6–12 місяців. Якщо обіцяють «продукт за 2 місяці» — це або шаблонне рішення (тоді нащо custom?), або product debt який доведеться сплачувати.

Як вимірювати якість команди розробки?

Три метрики: (1) lead time від commit до production (target <1 день); (2) deployment frequency (target кілька разів на тиждень); (3) change failure rate (target <15%). Це DORA metrics — найкращий індустріальний стандарт.

TDD виправдане у 2026?

Для бізнес-логіки — так, обов'язково. Для UI і scratch-prototypes — opt-in. Класичний test-first → green → refactor цикл вирішує 80% bugs ще до code review.

Що таке Domain-Driven Design?

Підхід до моделювання складних бізнес-доменів через ubiquitous language з business stakeholders і явні bounded contexts. Виправдано для проєктів >6 місяців з нетривіальною business logic. Для простих CRUD — overhead.

// інші компетенції

Суміжні напрямки

Реальні проєкти рідко вписуються в одну компетенцію. Подивіться, з якими ще напрямками ми працюємо.

Розкажіть про продукт, який хочете створити

30-хвилинна discovery-розмова з architect. Обговоримо вашу ідею, технічні ризики і реалістичні очікування.

Усі контакти