Вартість кастомізації Odoo визначається не «ціною модуля», а трудомісткістю: кількістю годин аналітика, розробника й тестувальника, помноженою на ставку. Зміна поля чи друкованої форми займає години, окремий модуль із власною логікою — тижні, складна інтеграція — місяці. До цього додаються витрати, яких у першому кошторисі зазвичай немає: адаптація коду під кожну нову версію Odoo.
Далі — п’ять рівнів складності, дві моделі оплати та спосіб зменшити бюджет ще до початку розробки.
П’ять рівнів доопрацювань
Перше, що робить інтегратор, отримавши запит, — визначає, до якого рівня він належить. Від цього залежить і ціна, і ризики.
| Рівень | Що це | Хто виконує | Порядок трудовитрат | Ризик на оновленнях |
|---|---|---|---|---|
| 1. Налаштування | Права доступу, етапи, шаблони, правила автоматизації, звіти стандартними засобами | Консультант | Години | Майже відсутній |
| 2. Odoo Studio | Нові поля, екрани, прості автоматичні дії, друковані форми без коду | Консультант | Години — дні | Низький, але зростає з кількістю змін |
| 3. Невеликий модуль | Додаткова логіка в наявному документі: розрахунок, перевірка, нове поле з обробкою | Розробник | Дні | Помірний |
| 4. Складний модуль | Новий бізнес-об’єкт із власним процесом, звітами, правами, зв’язками з обліком і складом | Аналітик, розробники, тестувальник | Тижні | Високий |
| 5. Інтеграція | Обмін даними із зовнішньою системою: банк, маркетплейс, облікова програма, обладнання | Аналітик, розробник | Від днів (готовий конектор) до місяців | Залежить ще й від змін на боці зовнішньої системи |
Орієнтири в колонці трудовитрат — це порядок величини, а не норматив: точну оцінку дає лише опис задачі.
Два практичні висновки. Перший: значна частина запитів, які замовник називає «розробкою», закривається рівнями 1 і 2, і це слід перевірити перед тим, як писати код. Другий: Odoo Studio доступна лише в тарифному плані Custom, тож ця різниця в ліцензіях теж є частиною вартості — подробиці на сторінці тарифів Odoo. Модулі з власним кодом на Odoo Online не встановлюються: для них потрібен власний сервер або платформа Odoo.sh, де окремо оплачуються воркери, сховище й тестові середовища (калькулятор Odoo.sh). Коли вистачає Studio, а коли потрібен код, розбираємо у статті «Odoo Studio чи розробка власного модуля».
Що саме збільшує кількість годин
Дві задачі з однаковою назвою можуть відрізнятися за ціною в кілька разів. Причини майже завжди ті самі.
- Кількість зачеплених модулів. Зміна, яка стосується лише CRM, дешевша за зміну, що проходить через продажі, склад і бухгалтерію.
- Втручання в облік. Усе, що впливає на проведення, собівартість чи податки, вимагає участі бухгалтера-методолога та значно довшого тестування.
- Винятки. Основний сценарій зазвичай займає меншу частину годин. Решту забирають «а якщо клієнт повертає частину товару», «а якщо документ уже проведено».
- Обсяг даних і швидкодія. Звіт на тисячу рядків і звіт на мільйон — різні задачі.
- Якість зовнішнього API. Для інтеграцій: документація, тестове середовище й стабільність на боці партнера впливають на ціну не менше, ніж сам Odoo.
- Вимоги до інтерфейсу. Нестандартні екрани, мобільні сценарії, робота зі сканером.
Окрема стаття — готові модулі з Odoo Apps або від локальних розробників. Готовий конектор чи модуль локалізації майже завжди дешевший за розробку з нуля, але має власну ціну ліцензії та власний графік оновлень під нові версії. Перед купівлею перевірте, чи підтримується він для вашої версії Odoo.
Погодинна оплата чи фіксована ціна
Ставок у гривнях тут немає: відкритих ринкових даних про ставки Odoo-розробників в Україні, на які можна надійно послатися, ми не знайшли, а ставки відрізняються залежно від кваліфікації команди та формату договору. Важливіше розуміти, як працює кожна модель.
| Погодинна модель (Time & Materials) | Фіксована ціна | |
|---|---|---|
| Що оплачується | Фактично витрачені години за звітом | Результат, описаний у ТЗ |
| Кому належить ризик | Замовнику: перевитрата годин — його витрати | Виконавцю, тому в ціну закладається резерв на невизначеність |
| Зміни під час роботи | Вносяться легко | Кожна зміна — додаткова угода і перерахунок |
| Коли підходить | Вимоги ще уточнюються, робота йде ітераціями, підтримка після запуску | Задача чітко окреслена, є ТЗ і критерії приймання |
| Що контролювати | Попередню оцінку, ліміт годин, щотижневі звіти | Повноту ТЗ: усе, чого там немає, не входить у ціну |
На практиці добре працює змішаний підхід: обстеження й оцінка — за фактом, розробка чітко описаних модулів — за фіксованою ціною, підтримка — пакетом годин на місяць. Якщо вам називають фіксовану ціну без жодних уточнювальних запитань, у ній або великий резерв, або майбутні додаткові угоди. Як ми організовуємо ці роботи, описано на сторінці послуги налаштування та кастомізації Odoo.
Прихована вартість: оновлення версій
Odoo щороку випускає нову основну версію. За умовами підписки Enterprise оновлення стандартної бази даних входить у ціну, але серед того, що у вартість не входить, вендор прямо називає супровід власного коду. Кожен власний модуль доведеться перевірити й адаптувати під нову версію — власними силами або з інтегратором.
Через це вартість доопрацювання правильно рахувати як суму трьох частин:
- Розробка і тестування.
- Супровід: виправлення помилок, зміни через оновлення зовнішніх сервісів.
- Адаптація під кожну наступну версію Odoo, на яку ви переходитимете.
Що глибше модуль втручається у стандартну логіку, то дорожча третя частина. Модуль, який додає нову сутність поруч зі стандартом, переживає оновлення легше, ніж модуль, що переписує проведення складських документів. Якісний код із тестами дорожчий на старті й дешевший на кожному оновленні. Як планувати такі переходи, читайте в матеріалі про оновлення Odoo на нову версію з кастомними модулями.
Звідси правило, яке економить найбільше: перед кожним доопрацюванням запитайте, чи не дешевше змінити процес. Якщо стандартна функція закриває більшу частину потреби, решту часто варто закрити регламентом, а не кодом.
Як написати ТЗ, щоб розробка коштувала менше
Нечітке завдання — головна причина перевитрат: розробник добудовує вимоги на власний розсуд, а замовник бачить результат і просить переробити. Добре технічне завдання не мусить бути довгим, але має містити сім речей.
- Мета мовою бізнесу. Не «додати поле», а «менеджер має бачити прострочену дебіторську заборгованість клієнта до підтвердження замовлення».
- Як процес відбувається зараз і що саме в ньому не влаштовує.
- Ролі. Хто створює запис, хто погоджує, хто лише переглядає.
- Сценарії крок за кроком, включно з винятками: повернення, скасування, часткове виконання.
- Дані. Які поля, звідки беруться, які обов’язкові, приклади реальних документів.
- Критерії приймання. Перелік перевірок, після проходження яких робота вважається зданою.
- Що не входить у задачу. Цей пункт запобігає багатьом суперечкам під час приймання.
Ще три прийоми зменшують бюджет. Поділіть вимоги на обов’язкові та бажані й запускайте спочатку перші. Попросіть інтегратора запропонувати альтернативу стандартними засобами для кожного пункту. Об’єднуйте дрібні зміни в один пакет: аналіз, тестування і розгортання для десяти правок разом дешевші, ніж для кожної окремо.
Якщо доопрацювання все ж потрібне, його оцінюють за таким ТЗ у межах послуги розробки модульних рішень Odoo. Місце цієї статті в загальному бюджеті проєкту показано в матеріалі «Скільки коштує впровадження Odoo в Україні у 2026 році».
Часті питання
Чи можна обійтися без кастомізації взагалі? Невеликим компаніям зі стандартними продажами, складом і закупівлями — часто так, достатньо налаштування. Але українська локалізація обліку та інтеграції з місцевими сервісами зазвичай потребують додаткових модулів, готових або розроблених.
Хто володіє кодом розробленого модуля? Це визначає договір, тому умову про передачу майнових прав і вихідного коду слід прописати до початку робіт. Без неї зміна підрядника може означати розробку заново.
Чому оцінки різних інтеграторів на одну задачу так відрізняються? Найчастіше вони оцінюють різний обсяг: один урахував винятки, тестування й документацію, інший — лише основний сценарій. Порівнюйте склад робіт і критерії приймання, а не підсумкову суму.
Чи зламаються доопрацювання після оновлення Odoo? Самі не зламаються, поки ви лишаєтеся на своїй версії. Під час переходу на нову кожен власний модуль треба перевірити й адаптувати, і цю роботу варто закладати в бюджет заздалегідь.
Якщо маєте перелік доопрацювань і хочете зрозуміти, що з нього закривається стандартом, а що потребує розробки, покажемо це на безкоштовній 30-хвилинній демонстрації. Записатися можна на сторінці контактів Plugit.
Читайте також: – Скільки коштує впровадження Odoo в Україні у 2026 році – Odoo Studio чи розробка власного модуля: що обрати – Оновлення Odoo на нову версію з кастомними модулями
