- 1. Етапи розробки інтернет-магазину коротко: терміни і що погоджує власник
- 2. До старту: оцінка і що власнику підготувати заздалегідь
- 3. Етап 1. Аналітика, стратегія і вибір платформи
- 4. Етап 2. UX-проєктування: прототипи каталогу, картки і оформлення замовлення
- 5. Етап 3. UI-дизайн і специфікація дизайну сайту
- 6. Етап 4. Розробка: верстка, логіка магазину і адмінпанель
- 7. Етап 5. Інтеграції: 1С, CRM, оплата, доставка і фіскалізація
- 8. Етап 6. Наповнення каталогу і перенесення даних
- 9. Етап 7. Тестування і приймання: чек-лист перед запуском
- 10. Етап 8. Запуск і перші тижні після нього
- 11. Скільки часу розробляється інтернет-магазин: розрахунок за типом проєкту
- 12. Якщо магазин уже є: як змінюються етапи при редизайні або переробці
- 13. Типові помилки власника, через які проєкт затягується
- 14. Часті запитання
Етапи розробки інтернет-магазину коротко: терміни і що погоджує власник
Етапи розробки інтернет-магазину під ключ у Kliox такі: стратегія й аналіз, UX-проєктування, UI-дизайн, розробка, інтеграції, наповнення, тестування і запуск. У таблиці зведено, скільки триває кожен крок, що ви отримуєте на виході і що підписуєте. Тривалість подано з нашого досвіду для проєкту рівня «Комплексне рішення»: індивідуальний дизайн, каталог від 100 товарів, CRM, email і SMS-розсилки.
| Етап | Що відбувається | Тривалість | Результат | Що погоджує власник |
|---|---|---|---|---|
| 1. Стратегія й аналіз | Ніша, конкуренти, структура каталогу, функції, карта інтеграцій | 1–2 тижні | Технічне завдання | ТЗ, платформу, графік |
| 2. UX-проєктування | Прототипи ключових сторінок | 1–2 тижні | Клікабельний прототип | Мобільний і десктопний прототип |
| 3. UI-дизайн | Візуальний стиль, UI-кіт, стани інтерфейсу | 2–3 тижні | Макети і специфікація | Макети, UI-кіт, перелік станів |
| 4. Розробка | Фронтенд, бекенд, адмінпанель | 3–8 тижнів | Версія на тестовому сервері | Проміжні демо |
| 5. Інтеграції | 1С/BAS, CRM, оплата, доставка, Checkbox | 1–4 тижні, паралельно | Налаштований обмін даними | Схему обміну |
| 6. Наповнення | Імпорт, чистка даних, міграція | 1–2 тижні, паралельно | Заповнений каталог | Шаблон картки на 5–10 товарах |
| 7. Тестування | Функції, смартфони, швидкість, навантаження | 1–2 тижні | Акт приймання | Акт за чек-листом |
| 8. Запуск | Перенесення на робочий сервер, аналітика, контрольне замовлення | 1–3 дні | Магазин приймає замовлення | Дату запуску |
Інтеграції й наповнення йдуть паралельно з розробкою, тому загальний строк менший за суму рядків. Розрахунок за типами проєктів наведено нижче, у розділі про терміни. На кожному етапі є одна-дві точки погодження, і пропускати їх дорого. Перемістити блок у прототипі означає годину роботи дизайнера. Той самий блок після верстки зачіпає дизайн, фронтенд і тестування.
До старту: оцінка і що власнику підготувати заздалегідь
На першій зустрічі ми з'ясовуємо бізнес-модель (роздріб, опт чи обидва), обсяг асортименту, канали продажу, облікову систему і ринки, на які плануєте виходити. Ви отримуєте попередню оцінку діапазоном і рекомендацію тарифу. Точну ціну без вивантаження товарів назвати неможливо. Обсяг робіт більше залежить від варіацій, фільтрів і обміну з обліком, ніж від кількості сторінок. Сто товарів з одним розміром і сто товарів з десятьма розмірами й трьома кольорами дають зовсім різний обсяг роботи.
Чек-лист: що підготувати до першої зустрічі
- Вивантаження асортименту в Excel, CSV або з 1С: назви, артикули, характеристики, ціни.
- 2–3 сайти, які вам подобаються, і 1–2, які ні, з поясненням чому.
- Доступ до тестової бази 1С/BAS і контакт програміста 1С.
- ФОП або ТОВ і поточний рахунок для еквайрингу.
- Договір з Новою поштою або Укрпоштою.
- ПРРО (наприклад, Checkbox) для фіскалізації онлайн-оплат.
- Домен і хостинг або рішення, щоб їх підібрала студія.
- Логотип, брендбук, фото товарів або план фотозйомки.
- Умови доставки, оплати, повернення і гарантії.
Відсутність чогось зі списку не зупиняє старт, але зсуває конкретні етапи. Без договору еквайрингу оплату не вдасться підключити до запуску. Без доступу до 1С обмін тестуватимемо наприкінці, коли часу на виправлення вже мало. Призначте одну відповідальну особу з правом погоджувати. Коли рішення ухвалюють троє людей без фінального голосу, кожне погодження розтягується на тиждень, а правки суперечать одна одній. Як описати вимоги до функцій, ми розписали в матеріалі про технічне завдання на розробку інтернет-магазину.
Що має бути в договорі до початку робіт
- Фіксований обсяг робіт з переліком функцій і бюджет.
- Графік з датами етапів і оплата по етапах.
- Кількість раундів правок прототипу і дизайну.
- Строк реакції замовника, наприклад 2–3 робочі дні на погодження. Якщо відповідь затримується, графік зсувається на цей час.
- Порядок зміни обсягу: нова функція оформлюється окремим запитом з власною ціною і строком.
- Гарантія на виправлення помилок і передача прав на код, дизайн і доступи.
Kliox працює за офіційним договором з фіксованим бюджетом і термінами, без прихованих платежів. Якщо порівнюєте кількох підрядників, дайте всім однаковий бриф і просіть розбивку по етапах, а не одну суму. Так видно, хто заклав тестування й інтеграції, а хто їх пропустив, щоб пропозиція виглядала дешевшою.
Етап 1. Аналітика, стратегія і вибір платформи
Аналізуємо нішу й конкурентів, збираємо семантику, щоб дерево категорій відповідало реальним пошуковим запитам. Складаємо перелік функцій і ділимо його на «до запуску» і «потім». Малюємо карту інтеграцій: які системи обмінюються даними і в який бік. Результат фіксується в технічному завданні. Функції визначає ніша. Для KIEVMINER покупцям ASIC-майнерів потрібні були порівняння моделей і калькулятор окупності, що враховує курс монети й тариф на електроенергію. У TradeAuto сумісність автоаксесуарів залежить від марки, моделі й року авто, тому цю логіку заклали у фільтри й пошук. DermActe на ринку ОАЕ без оплати частинами, Apple Pay і цін в AED втрачав би покупців уже в кошику.
Як обирається платформа: порівняльна таблиця
Орієнтири з нашого досвіду. Остаточний вибір залежить від каталогу, інтеграцій і планів на 2–3 роки.
| Платформа | Коли підходить | Обмеження | Вплив на строк |
|---|---|---|---|
| WooCommerce | Каталог до кількох тисяч товарів, багато контенту | Залежність від плагінів, на великих каталогах потрібна оптимізація | Короткий старт |
| OpenCart | Класичний магазин середнього розміру, є модулі під український ринок | Модулі можуть конфліктувати, під піками потрібні доопрацювання | Швидкий старт, доопрацювання додають час |
| Shopify | Типовий магазин, закордонні ринки, невелика команда | Щомісячна підписка, обмежена кастомізація оформлення, зв'язок з українським обліком через сторонні застосунки | Найшвидший старт для типового сценарію |
| Magento | Великі каталоги, складні правила цін, кілька вітрин | Дорожчі розробка і хостинг | Довший строк |
| Next.js + Laravel (headless) | Десятки тисяч товарів, піки трафіку, кілька ринків, B2B | Усе розробляється під проєкт | Найдовший строк, але без обмежень платформи |
Кастомна архітектура виправдана, коли каталог налічує десятки тисяч позицій, реклама дає різкі піки або кілька ринків працюють на одній системі. У Sayvi Studio український та іспанський напрями мають окремі домени, а каталог, замовлення і бізнес-логіку обслуговує одна серверна система. Якщо магазин уже працює, етап починається з аудиту: Petronas Shop ми послідовно покращували на чинному OpenCart замість створення нової платформи. Ви погоджуєте: дерево категорій, список функцій до запуску і «на потім», перелік інтеграцій, платформу і графік. Тривалість 1–2 тижні.
Етап 2. UX-проєктування: прототипи каталогу, картки і оформлення замовлення
Прототип — це чорно-біла схема сторінок без кольорів і фото. На ньому видно розташування блоків і шлях покупця від головної до оплати. Перемістити фільтр чи прибрати зайвий крок оформлення тут займає хвилини. Обов'язковий набір: головна, категорія з фільтрами, картка товару, пошук, кошик, оформлення, особистий кабінет, сторінки доставки, оплати й повернення. Для B2B додаються оптовий кабінет, ціни для груп клієнтів і замовлення за артикулами. Найбільше часу йде на категорію і картку: які характеристики потрапляють у фільтри, як показати варіації, що бачить покупець, якщо потрібного розміру немає.
Чому мобільний прототип погоджують першим
У більшості магазинів, з якими ми працюємо, основний трафік приходить зі смартфонів. Тому мобільну версію ми проєктуємо як окремий сценарій, а не як стиснутий десктоп. Типове рішення: фіксоване нижнє меню тримає під рукою каталог, кошик і обране, а контакти, місто, відділення Нової пошти й спосіб оплати заповнюються без переходів між кількома кроками.
Як перевірити прототип, якщо ви не дизайнер
Пройдіть прототип як покупець: знайдіть товар за назвою, підберіть товар за параметрами, купіть з телефона. Порахуйте кроки до оплати і запишіть місця, де довелося зупинитися й подумати. Не оцінюйте прототип за естетикою. Кольори з'являться на наступному етапі, а фільтри, не закладені зараз, доведеться вбудовувати в готовий дизайн. Ви погоджуєте клікабельний прототип ключових сторінок у мобільній і десктопній версіях. Тривалість 1–2 тижні, кількість раундів правок визначена договором.
Етап 3. UI-дизайн і специфікація дизайну сайту
Дизайн будується на погодженому прототипі: кольори, шрифти, іконки, адаптиви і UI-кіт, тобто бібліотека повторюваних елементів (кнопки, поля, картки товарів, бейджі). Просіть використовувати у макетах ваші справжні фото, а не стокові. Інакше після наповнення каталог виглядатиме не так, як на макеті.
Специфікація дизайну: стани, які забувають намалювати
Специфікація дизайну — це макети плюс опис поведінки елементів у всіх станах. Без неї програміст вигадує поведінку сам, а ви бачите результат уже на тестовому сервері, де переробка дорожча.
| Стан | Що має побачити покупець |
|---|---|
| Порожній кошик | Підказку і посилання на популярні категорії |
| Товар закінчився | Позначку відсутності і кнопку «повідомити про надходження» |
| Не обрано розмір чи колір | Підсвічене поле і зрозуміле повідомлення |
| Фільтр без результатів | Пропозицію скинути один із фільтрів |
| Помилка оплати | Причину і повторну спробу без втрати кошика |
| Неправильний телефон чи відділення | Підказку біля конкретного поля, а не загальну помилку форми |
| Успішне замовлення | Номер, склад замовлення, наступні кроки і канал зв'язку |
У GOU картка товару одночасно показує актуальну й попередню ціну, суму економії, відсоток знижки і час дії пропозиції. Такий блок проєктується до розробки, інакше кожен елемент додаватиметься окремою правкою.
Як погоджувати дизайн, щоб не переробляти після верстки
Погоджуйте пакет, а не окремі гарні екрани: головна, каталог, картка, кошик і оформлення в обох версіях, UI-кіт і перелік станів. Відкривайте макети з телефона, а не лише на великому моніторі. Після погодження зміни дизайну оформлюються як зміна обсягу з окремим строком: одна «невелика» правка картки після початку верстки тягне переробку фронтенду, станів і тестів. Тривалість етапу 2–3 тижні.
Етап 4. Розробка: верстка, логіка магазину і адмінпанель
Фронтенд (те, що бачить покупець) і бекенд (каталог, ціни, замовлення, адмінпанель) розробляються паралельно на тестовому сервері, закритому від індексації. Кожні 1–2 тижні ми показуємо готові функції в робочому вигляді. Ви самі клікаєте фільтри й проходите оформлення, а не читаєте звіт про відсотки готовності. На цьому етапі реалізуються:
- каталог, фільтри, сортування і пошук з підказками;
- кошик, оформлення і швидке замовлення;
- особистий кабінет з історією замовлень;
- промокоди, знижки, акційні ціни;
- SEO-основа: зрозумілі URL, шаблони мета-тегів, мікророзмітка товарів, sitemap;
- оптимізація швидкості: стиснення зображень, кешування.
Адмінпанель: що перевірити до запуску
Ваша команда має без програміста додавати товари, міняти ціни й залишки, обробляти замовлення і змінювати банери. У GOU керування товарами, розмірами, складом і замовленнями перенесли в кастомну адмінпанель на Laravel, а вітрину для покупців зробили на Next.js. Попросіть контент-менеджера на демо самостійно додати товар з варіаціями і змінити ціну. Якщо це займає більше кількох хвилин або потребує довгої інструкції, адмінку варто спростити до запуску. Ви погоджуєте проміжні демо і перелік функцій, готових до тестування. Тривалість 3–8 тижнів залежно від обсягу.
Етап 5. Інтеграції: 1С, CRM, оплата, доставка і фіскалізація
| Інтеграція | Що дає бізнесу | Ризик для строку |
|---|---|---|
| 1С/BAS | Товари, ціни, залишки на сайт, замовлення назад в облік | Високий |
| CRM | Замовлення і клієнти в одному місці, статуси, повторні продажі | Середній |
| Нова пошта, Укрпошта | Вибір міста й відділення, розрахунок доставки, створення ТТН | Низький, якщо є договір і API-ключ |
| Monobank, LiqPay | Оплата карткою, оплата частинами (у LiqPay залежить від банку-партнера) | Середній, залежить від договору з банком |
| Checkbox | Фіскальні чеки для онлайн-оплат | Низький |
| Tabby, Apple Pay, Google Pay | Оплата частинами і в один дотик на закордонних ринках | Середній, залежить від верифікації |
Набір залежить від моделі бізнесу. GOU приймає оплату через Monobank і формує чеки в Checkbox. Petronas Shop пов'язаний з 1С, платіжною системою і Новою поштою. DermActe для ОАЕ отримав Tabby, Apple Pay, Google Pay і оплату при отриманні. Найризиковіша частина: обмін з 1С. Він залежить від конфігурації і від програміста на вашому боці, а тестувати його треба в обидва боки. У TradeAuto товари й залишки надходять з 1С на сайт, а замовлення повертаються в облік. У BabyKroha до інтеграції менеджери правили ціни й залишки вручну і помилялися, тепер дані синхронізуються без ручного втручання.
Що найчастіше затримує інтеграції
- договір еквайрингу не підписаний, банк ще перевіряє сайт;
- немає тестової бази 1С, а працювати з робочою ризиковано;
- програміст 1С завантажений і відповідає раз на тиждень;
- служба доставки ще не видала API-ключ;
- одна характеристика в обліку і на сайті називається по-різному.
Тому інтеграції ми запускаємо паралельно з дизайном: поки малюються макети, ви оформлюєте договори, а ми узгоджуємо формат обміну з програмістом 1С. Від вас знадобляться тестова база 1С і список полів для обміну, доступ адміністратора CRM, API-ключ служби доставки, ключі мерчанта від банку і дані каси Checkbox. Ви погоджуєте схему обміну: які поля передаються, як часто і яка система головна для цін і залишків. Тривалість 1–4 тижні паралельно з розробкою.
Етап 6. Наповнення каталогу і перенесення даних
Наповнення починається паралельно з розробкою, інакше готовий магазин тижнями стоїть порожній, а реклама чекає. Студія робить імпорт товарів, шаблони описів і мета-тегів, структуру характеристик для фільтрів. Від вас потрібні фото, ціни, особливості товарів і юридичні сторінки: оферта, умови доставки й повернення, політика конфіденційності. Перед імпортом дані чистять. Типові проблеми: дублі артикулів, одна характеристика під різними назвами («чорний», «Black», «чорн.»), товари без фото. Чернетки описів і мета-теги для тисяч карток можна згенерувати AI-інструментами за характеристиками, а редактор перевіряє і править результат. Так робота займає дні замість тижнів.
Перенесення зі старого сайту без втрати SEO
Якщо магазин переїжджає, ми складаємо карту старих і нових URL, налаштовуємо 301-редиректи, переносимо мета-дані, відгуки й історію товарів. Покроково процес розписаний у статті про міграцію інтернет-магазину без втрати SEO і замовлень. Ви погоджуєте шаблон картки на 5–10 реальних товарах до масового імпорту: помилку простіше виправити на десяти товарах, ніж на п'яти тисячах. Тривалість 1–2 тижні.
Етап 7. Тестування і приймання: чек-лист перед запуском
Команда перевіряє функції за сценаріями, відображення в Chrome, Safari, Firefox і на реальних смартфонах, швидкість у PageSpeed, захист форм від спаму. Навантажувальний тест обов'язковий, якщо плануєте рекламу в Instagram чи TikTok. GOU на попередній платформі втрачав стабільність саме тоді, коли Reels і Stories одночасно приводили багато покупців.
Чек-лист приймання для власника
- Контрольна покупка кожним способом оплати.
- Повернення коштів за тестовим замовленням.
- Фіскальний чек сформовано і надіслано покупцю.
- Замовлення з'явилося в 1С або CRM з правильним складом і сумою.
- Залишок товару оновився на сайті після продажу.
- Доставка розраховується і відділення обираються для різних міст.
- Покупець отримує листи і SMS про замовлення.
- Промокод застосовується і не сумується там, де не повинен.
- Покупка з телефона через мобільний інтернет, а не офісний Wi-Fi.
- Контент-менеджер додає товар через адмінку без допомоги.
Що блокує запуск, а що можна виправити після
Запуск блокують непрацююча оплата чи оформлення, замовлення, що не доходять в облік, неправильні ціни і критичні помилки на мобільному. Косметичні дрібниці, другорядні сторінки і відображення в рідкісних браузерах можна доробити після. Приймання фіксується актом, помилки після підписання виправляються в межах гарантії. Тривалість етапу 1–2 тижні.
Етап 8. Запуск і перші тижні після нього
План дня запуску
- Перенесення коду і бази на робочий сервер, встановлення SSL.
- Відкриття індексації, перевірка robots.txt і sitemap.
- Перевірка 301-редиректів, якщо був старий сайт.
- Підключення Google Search Console.
- GA4 з подіями e-commerce: перегляд товару, додавання в кошик, початок оформлення, покупка.
- Контрольне замовлення на живому сайті з реальною оплатою.
Запускайтеся в будній день зранку, не в п'ятницю. Між запуском і стартом реклами закладіть 1–2 тижні: за цей час виловлюються помилки, яких не було на тестовому сервері. Перед перемиканням ми робимо резервну копію старого сайту і бази, щоб за критичної помилки повернутися на стару версію без втрати замовлень. Перші 2–4 тижні ми стежимо за помилками сервера, швидкістю, конверсією кошика, а після міграції ще й за позиціями в пошуку. Як рахувати конверсію і з якими нормами порівнювати, розібрано в статті про конверсію інтернет-магазину.
Підтримка і розвиток після запуску
Кожен проєкт Kliox включає виправлення помилок після запуску і 10 годин безкоштовної підтримки, а в тарифі «Індивідуальне рішення» додаються 3 місяці VIP-підтримки. Далі магазин розвивається: функції зі списку «потім», нові інтеграції, покращення за даними аналітики. Копійку і BabyKroha ми ведемо на підтримці: стежимо за стабільністю, оновлюємо компоненти, усуваємо збої.
Скільки часу розробляється інтернет-магазин: розрахунок за типом проєкту
Терміни за тарифами Kliox
| Тариф | Що входить | Орієнтовний строк |
|---|---|---|
| «Швидкий старт» | Шаблон, до 10 товарів, оплати й аналітика, для тесту ніші | 2–4 тижні |
| «Комплексне рішення» | Індивідуальний дизайн, каталог від 100 товарів, CRM, email/SMS, SEO-фундамент | 6–10 тижнів |
| «Індивідуальне рішення» | Кастомна архітектура, B2B, інтеграція з 1С/ERP, мультимовність, 3 місяці VIP-підтримки | 3–6 місяців |
Строки орієнтовні, з нашого досвіду. Точний графік фіксується в договорі після аналізу ваших даних.
Приклад графіка комплексного проєкту по тижнях
| Тижні | Що відбувається |
|---|---|
| 1–2 | Аналітика, ТЗ, вибір платформи. Ви оформлюєте договори з банком і службою доставки |
| 2–3 | Прототипи ключових сторінок |
| 3–5 | UI-дизайн і специфікація станів, узгодження обміну з 1С |
| 5–9 | Розробка, паралельно інтеграції й наповнення каталогу |
| 9–10 | Тестування, приймання, запуск |
Прототипи стартують, щойно погоджено структуру каталогу, а інтеграції йдуть разом з розробкою. Завдяки цьому 10 тижнів вміщують роботи, які послідовно зайняли б 14–16.
Що збільшує і що скорочує строк
Збільшують строк:
- 1С нестандартної конфігурації або без тестової бази;
- кілька ринків, мов і валют;
- B2B-ціни для груп клієнтів і оптовий кабінет;
- міграція великого каталогу з чисткою даних;
- погодження довше за 2–3 робочі дні і контент, що надходить наприкінці.
Скорочують строк готові вивантаження, фото й доступи на старті, одна відповідальна особа з правом рішення і запуск MVP: мінімальний набір функцій плюс чіткий список того, що додається після. Бюджет формують ті самі фактори: складність дизайну, набір функцій, кількість інтеграцій, обсяг каталогу. Як складаються витрати, ми розібрали в матеріалі скільки насправді коштує інтернет-магазин. Бюджет лишається фіксованим, якщо обсяг закріплено в договорі, а нові побажання оформлюються окремо.
Якщо магазин уже є: як змінюються етапи при редизайні або переробці
Етапи ті самі, але на старті додається аудит, а наприкінці складніша міграція. Спершу треба вирішити, що робити з чинним сайтом.
- Доопрацювати чинну платформу, якщо основа стабільна, а проблема в UX, функціях чи дизайні. Так було з Petronas Shop на OpenCart.
- Перебудувати на новій основі, якщо ключові функції не працюють. У TradeAuto попередня команда працювала близько року, але частина функцій лишилася незавершеною. Клієнту вже треба було запускати рекламу, тому каталог, замовлення й адмінку зібрали на Laravel замість подальшого латання.
- Зробити новий магазин замість повільного, якщо платформа застаріла. У BabyKroha сторінки відкривалися із затримкою, особливо на смартфонах, і частина покупців ішла, не побачивши товару.
Ознаки, що латати вже невигідно: сайт падає під рекламою; мобільна швидкість не росте після оптимізацій; кожна зміна ламає щось в іншому місці; менеджери вручну дублюють дані, бо обміну з 1С немає. До етапів додаються технічний і SEO-аудит, фіксація поточних позицій, трафіку й конверсії для порівняння, карта 301-редиректів, перенесення клієнтів і замовлень, запуск без зупинки продажів. Під час такого переходу ми зберігаємо важливі адреси сторінок незмінними, щоб не втратити позиції, а швидкість порівнюємо з показниками, зафіксованими до старту.
Типові помилки власника, через які проєкт затягується
- Правки дизайну після початку верстки. «Давайте ще переставимо кнопку» легко коштує тиждень.
- Контент «потім». Розробка закінчена, а фото й описів немає, і запуск зсувається на тижні.
- Договори з еквайрингом і доставкою в останній тиждень. Банк перевіряє сайт кілька днів, і оплата з'являється вже після запланованої дати.
- Нова функція посеред розробки без оформлення зміни обсягу. Неформальне «додайте ще фільтр» зсуває строк і бюджет, а сторони потім по-різному пам'ятають домовленість.
- Запуск у день старту реклами. Перший потік покупців потрапляє на помилки, яких ніхто не встиг побачити.
- Вибір платформи лише за ціною старту. Коли з'являються 1С, опт і великий каталог, дешева основа перестає справлятися, а перебудова завжди дорожча за правильну архітектуру з початку.
Часті запитання
Чим етапи створення звичайного сайту відрізняються від розробки інтернет-магазину?
Для сайту-візитки чи лендингу процес зводиться до структури, дизайну, верстки і текстів. У магазині додаються каталог з фільтрами, кошик і оформлення, інтеграції з оплатою, доставкою й обліком, імпорт товарів і тестування замовлень. Тому магазин з тією самою кількістю сторінок займає помітно більше часу.
Скільки раундів правок дизайну входить у проєкт і що буде, якщо їх забракне?
Кількість раундів фіксується в договорі окремо для прототипу і для дизайну. Додаткові правки оцінюються окремо і можуть зсунути графік. Щоб вкластися, збирайте зауваження від усіх причетних в один список і передавайте через відповідальну особу.
Чи можна запустити магазин поетапно, з мінімальним набором функцій?
Так, і часто це найкращий варіант. До запуску робиться все, без чого не можна продавати: каталог, кошик, оплата, доставка, аналітика. Конфігуратори, програма лояльності, B2B-кабінет додаються наступними релізами, коли з'являються дані про реальних покупців.
Кому належать код, доступи і дизайн після запуску?
Вам. Kliox передає повні права на проєкт: код, макети, доступи до сервера, домену, адмінпанелі і сервісів. Перевірте, щоб домен і акаунти платіжних систем були оформлені на вашу компанію, а не на підрядника. Якщо плануєте новий магазин або переробку чинного, надішліть вивантаження асортименту й напишіть, з якою обліковою системою працюєте. Ми розпишемо етапи, строк і точки погодження для вашого проєкту. Як ми працюємо, дивіться на сторінці розробки інтернет-магазинів під ключ.
Поділіться своїми думками щодо цієї статті. Ваша оцінка допоможе зробити матеріали ще кориснішими.