Популярні питання

Custom-розробка має сенс там, де є унікальна логіка, специфічні інтеграції або вимоги, які жоден готовий продукт не закриє без суттєвих компромісів.

Якщо задачу можна вирішити наявним інструментом, який покриє 80% потреб – скажемо про це на старті. Але якщо бізнес вже переріс шаблонні рішення або будує щось нестандартне, індивідуальна розробка дає повний контроль: логіка, ролі, інтеграції, звіти – все під конкретні вимоги.

Готова платформа – це швидкий старт у межах того, що в ній передбачено. Поки бізнес вкладається в ці межі, все працює. Але коли з'являються нестандартні процеси, специфічна логіка або потреба в глибоких інтеграціях, починаються обхідні шляхи, плагіни і постійні обмеження.

Індивідуальне рішення будується під вас: масштабується разом з бізнесом, інтегрується з будь-якими сервісами і не залежить від рішень сторонньої платформи щодо змін в API чи політиці.

Здебільшого це або інструменти для внутрішньої роботи компанії, або продукти, з якими взаємодіють клієнти чи партнери. Перші – це системи управління, облікові платформи, інтеграційні рішення між існуючими сервісами. Другі – веб і мобільні додатки, партнерські портали, e-commerce. Часто одне переплітається з іншим: наприклад, платформа для дистриб'юторів, яка всередині підключена до ERP і аналітики. Конкретний набір завжди залежить від того, який процес треба вирішити.

Від складності та обсягу. Інколи MVP можна зібрати за місяць, а повноцінну систему за декілька місяців. Якщо потрібна глибока інтеграція або розробка складної аналітики з нуля, терміни довші. Розробка завжди розбивається на фази, і перші результати з'являються раніше, ніж проєкт завершується повністю.

Починаємо з Discovery-етапу. Тут ми разом з'ясовуємо реальну задачу, обмеження і критерії результату. Це точка, де ми перевіряємо, чи правильно сформульована задача, перш ніж починати її вирішувати.

Далі розробка рухається ітераціями з конкретним результатом у кожній фазі. Ви дивитесь звіти, даєте фідбек, і наступний етап враховує ваші коментарі. Так рішення вибудовується поступово, і у вас є можливість впливати на нього в процесі.

Щоденного занурення не потрібно, але повністю відсторонитися теж не вийде. На старті важливо якісно передати контекст і відповісти на ключові питання. Далі треба час від часу приймати рішення по пріоритетах, дивитись демо, звіти, давати фідбек. Чим чіткіша комунікація на кожному етапі, тим менше правок і непорозумінь в кінці.

На кожен проєкт є виділений менеджер, і саме він відповідає за комунікацію з командою, дедлайни, координацію, оновлення для клієнта. Ви спілкуєтесь з однією людиною, яка знає стан проєкту краще за всіх. Методологію обираємо під конкретний контекст: Scrum, Kanban або гібрид, якщо у вас вже є свої внутрішні процеси, під які треба підлаштуватись.

При T&M нові пріоритети просто вписуються в наступний цикл. З фіксованим бюджетом складніше, але керовано: сідаємо, дивимось на поточний обсяг і вирішуємо, що важливіше зробити зараз, а що відкласти. Головне, що жодне рішення не приймається без вашої участі. Все прозоро, і ви завжди в курсі, що і чому змінилось.

QA-інженер працює в тій самій команді і підключається до кожної функції. Ручне тестування закриває сценарії, де важлива логіка і користувацький досвід. Автоматизація підключається там, де треба перевіряти одне і те саме регулярно, без помилок через людський фактор.

Окремо тестуємо навантаження, безпеку і граничні випадки. Перед релізом клієнт проходить фінальне приймальне тестування на живій системі. Це повноцінна перевірка того, що буде запущено.

У backend-розробці працюємо з PHP (Phalcon, Yii2), Java, Symfony, для інтеграцій – REST API та GraphQL. Фронтенд найчастіше будуємо на Vue.js, для управління контентом використовуємо PIMCore, мобільні рішення – Swift та Kotlin. Це все використовували у конкретних проєктах для ритейлу, e-commerce, держсектору, медіа та виробництва.

Стек завжди підбирається під задачу. В одному проєкті у пріоритеті швидкодія, у іншому – гнучкість інтеграцій, у третьому – масштабованість. І ми завжди пояснюємо клієнту, чому пропонуємо саме такий набір інструментів.

Підключали продукти до CRM, ERP, складських систем, маркетингових платформ, платіжних шлюзів, поштових сервісів, державних API, маркетплейсів. Якщо система має відкритий API – підключаємось напряму. Якщо ні – шукаємо інший шлях: парсери, проксі, кастомні конектори. Головне, що результат має працювати в реальному операційному середовищі.

Код, документація та інфраструктура повністю переходять до вас після оплати. Передаємо все у ваш Git або іншу систему на ваш вибір. Жодних закритих модулів чи прихованих залежностей, через які ви були б прив'язані до нас. Хочете змінити підрядника або розвивати продукт власною командою – ніяких перешкод.

Код проходить кілька рівнів перевірки, ручне або автоматизоване тестування, перевірка на продуктивність та безпеку. Але ще важливіший момент – проєктування. Якщо функція погано продумана або логічно суперечить решті системи, вона не потрапляє в розробку. Виправляти архітектурні рішення після релізу набагато дорожче, ніж поставити правильні питання на початку.

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

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

Від мінімального моніторингу до повного технічного супроводу, залежно від того, що потрібно. Критичні проєкти закриваємо SLA з чітким часом реагування. Для менш критичних пропонуємо гнучкий формат за домовленістю. Підтримка охоплює роботу з багами, оновлення бібліотек, безпеку та оптимізацію.

Якщо архітектура спроєктована з урахуванням росту – так, і саме так ми її будуємо. Нові модулі, збільшення навантаження, додаткові інтеграції – все це закладається на рівні рішень, прийнятих ще до першого рядка коду. У нас є кейси, де MVP, зібраний за кілька тижнів, виріс у повноцінну платформу без необхідності переписувати систему з нуля.

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