Бюджет: 6999 EUR Термін: 40 днів
Готовий, взяти в роботу.
Робимо все під ключ
роботи можна подивитися в профілі або тут echocode.app
Потрібно розробити крос-платформенний мобільний додаток для автосервісу в (експрес заміна масла, фільтрів, сервіс АКПП, кондиціонера тощо). Додаток має спростити запис клієнтів, пришвидшити роботу майстрів і підвищити лояльність.
Основні функції для клієнта (мобільний додаток):
Реєстрація / вхід (email + пароль або Google/Apple Sign In).
Додавання автомобілів (номерний знак, марка, модель, рік, об'єм масла, тип коробки тощо).
Онлайн-запис:
Вибір дати і часу (календар з вільними слотами).
Вибір послуг: заміна масла + фільтри, діагностика, сервіс АКПП, сервіс кондиціонера, додаткові опції.
Вказівка потрібного масла (Shell Helix Ultra ECT C3 5W-30 та ін.), фільтрів (Mann тощо).
Можливість замовити перекус (чебуреки, кава, сендвічі).
Сімейна знижка: один акаунт може прив'язати кілька машин (до 4–5), автоматична знижка 15–25 % при обслуговуванні будь-якої з них.
Історія відвідувань, фото-звіти, роздруківки діагностики.
Push-сповіщення: нагадування про наступну заміну, підтвердження запису, акції.
Оплата онлайн (інтеграція Stripe або аналог) — опціонально на першому етапі.
Функції для сервісу (веб-адмінка / планшет у боксі):
Календар записів (день/тиждень) з кольоровою індикацією завантаження.
При в'їзді машини — автоматичне розпізнавання номера (ANPR): камера на в'їзді зчитує реєстраційний знак → система одразу показує на екрані:
Хто клієнт,
Що замовив,
Скільки масла лити,
Які фільтри ставити,
Додаткові послуги.
Швидкий ввід результатів: завантаження фото (колодки, старий фільтр, шини), нотатки, роздруківка звіту по всім послугам клієнту.
Управління складом (залишок масла в бочках, фільтрів) — проста таблиця.
Статистика: кількість машин на день, середній чек, популярні послуги.
Технічні вимоги:
Крос-платформа: Flutter або React Native (бажано Flutter).
Бекенд: Firebase (Auth, Firestore, Storage, Cloud Functions) або Node.js + MongoDB/PostgreSQL.
ANPR: інтеграція готового модуля (OpenALPR, Plate Recognizer або аналог через API). На першому етапі можна без камери — просто ручний ввід номера.
Адмінка: веб-панель (React/Vue або навіть у Flutter Web).
Дизайн: простий, чистий, в стилі автосервісу (темні тони + акценти).
Етапи і бюджет:
Бюджет: (готовий обговорювати).
Перший реліз (MVP): 6–8 тижнів.
MVP включає: запис, список послуг, сімейні знижки, календар в адмінці, ручний ввід номера (ANPR — друга черга).
Додатково:
Джерельний код передається повністю.
Підтримка і доопрацювання після запуску — окремо.
Бюджет: 6999 EUR Термін: 40 днів
Готовий, взяти в роботу.
Робимо все під ключ
роботи можна подивитися в профілі або тут echocode.app
Бюджет: 3000 EUR Термін: 31 день
📌Привіт.👋
⭐️Мене звати Андрій.
⭐️Мій досвід роботи: 12 років+
• ➡️Можу показати роботи саме по мобільним додаткам
• 🎨Портфоліо: Freelancehunt
• ✅Рейтинг робіт на Behance (більше 500.000 переглядів)
• 💼Більше робіт тут: Dribbble
Бюджет: 25 EUR Термін: 7 днів
Вітаю, займаюся розробкою мобільних додатків на Flutter під ios/android, маю комерційний досвід роботи в компаніях, є досвід створення додатків самостійно з нуля до публікації в магазинах (є докази в відгуках). Також роблю кастомний бекенд на Python/Firebase з подальшим розгортанням на серверах. Вільний до роботи, можу почати вже зараз. Готовий проконсультувати з усіх питань.
Бюджет: 5000 EUR Термін: 10 днів
Уявіть собі, як ваш сервіс стане більш ефективним і орієнтованим на клієнта завдяки нашому унікальному додатку. Я спеціалізуюсь на крос-платформенній розробці і відмінно володію Flutter, що дозволяє мені реалізувати ваш проект, забезпечуючи плавну інтеграцію всіх необхідних функцій. З моїм досвідом у CRM та адмініструванні серверів, адмінка буде інтуїтивною і функціональною. Давайте обговоримо деталі і створимо додаток, який спростить процеси і підвищить зручність для ваших клієнтів.
Бюджет: 8000 EUR Термін: 30 днів
Привіт. Має великий досвід з React/React Native/Node.js. Готовий до співпраці.
Бюджет: 5000 EUR Термін: 60 днів
Доброго дня!
Проект дуже цікавий, з задоволенням готовий взятися за реалізацію 👍
Функціонал зрозумілий і логічний, формат автосервісу чудово підходить для мобільного додатку.
Єдиний момент, який хотів би запропонувати обговорити — бекенд. Я б рекомендував робити його на Laravel з інтеграцією Firebase через API (Auth, Push, Storage за необхідності). Це дасть гнучкість, зручну бізнес-логіку і хорошу масштабованість.
Мобільний додаток можемо реалізувати як на Flutter, так і на React Native — обидва варіанти підходять. Особисто мені ближче React Native, оскільки з ним більше практичного досвіду, але вибір не принциповий.
Також можемо зробити зручну веб-адмінку для сервісу (календар, записи, склад, статистика тощо).
Працюю не один — є невелика команда фронтенд і бекенд розробників, тому можемо реалізувати проект повністю “під ключ”, від MVP до подальшого розвитку.
Буду радий обговорити деталі, етапи і бюджет. Звертайтеся 🙂
Бюджет: 1000 EUR Термін: 10 днів
Дам реальну оцінку, як побачу дизайн. Можу зробити під ключ.
Резюме - https://github.com/ReactNativeFanDev
Бюджет: 300 EUR Термін: 1 день
Коротко про нас: Mobiwolf — 15 років у мобільній розробці (iOS / Android / Flutter). Робили сервіси з онлайн-записом, календарями, лояльністю, адмінками й складнішою бізнес-логікою, тож ваш кейс нам дуже близький.
Як ми бачимо MVP
Фокус правильний: запис + зручність для майстра + лояльність клієнта. Для першого релізу логічно йти без ANPR і складної автоматизації, але одразу закласти архітектуру так, щоб її легко додати пізніше.
Flutter + Firebase виглядає оптимально для швидкого MVP:
• швидкий кросплатформений старт,
• push, auth, storage “з коробки”,
• мінімум DevOps на першому етапі.
Орієнтовна оцінка (ballpark)
MVP (6–8 тижнів) — цілком реалістично.
Грубо по годинах:
• Мобільний застосунок (клієнт): 220–260 год
• Backend / Firebase логіка: 120–150 год
• Веб-адмінка (календар, замовлення, склад): 120–150 год
• Тести, стабілізація, реліз: 40–60 год
Разом: 500–620 год
Рейт: $35/год
Рекомендований формат — time & material (fixed можливий після деталізації сценаріїв).
Питання для уточнення
1. Один сервіс на старті чи мережа автосервісів?
2. Чи потрібні різні бокси / майстри з окремими слотами?
3. Сімейна знижка — фіксована чи залежить від кількості авто?
4. Оплата точно не входить у MVP?
5. Мови: одна чи одразу кілька?
Наступний крок
Пропоную короткий discovery (3–5 днів):
• фіналізуємо MVP,
• фіксуємо стек і межі першого релізу,
• даємо точні строки та бюджет.
Бюджет: 17000 EUR Термін: 45 днів
Доброго дня!
Мене звуть Олексій, я представляю групу розробників – NC-1. Більше п'яти років ми створюємо веб-сайти, мобільні додатки, інтернет-магазини, ERP/CRM системи та інші e-commerce продукти. У нашій команді є спеціаліст (flutter-розробник, full stack, senior) з необхідним для Вас досвідом і знаннями.
Додатки на flutter, які він зробив:
https://play.google.com/store/apps/details?id=com.kpapp.solution
https://play.google.com/store/apps/details?id=com.onevoiplanet.onephone
Кейси: https://1drv.ms/b/c/b7a0d31a9dae1bc5/IQCpK38gmEvWT6F_Cso40Li-AXAKkSs-J67mCwll-C732pw?e=v4VVF5
З повагою,
Олексій М.
Бюджет: 5000 EUR Термін: 40 днів
Доброго дня!
Ми компанія з великим досвідом розробки крос-платформених мобільних додатків на Flutter та React Native для сервісних та бізнес-орієнтованих проектів. Реалізовували додатки з онлайн-записом, календарями, push-сповіщеннями, управлінням замовленнями, складом та інтеграцією з зовнішніми API.
Як ми бачимо реалізацію вашого проекту:
- Клієнтський додаток (iOS / Android) на Flutter або React Native
- Веб-адмінка / планшет для сервісу з календарем, статусами та швидким введенням даних
- Інтеграція з Firebase або Node.js бекендом
- Підтримка push-сповіщень, історії візитів, фото-звітів
- Гнучка логіка послуг, додаткових опцій та сімейних знижок
- Підготовка архітектури під подальше підключення ANPR (на MVP — ручний ввід)
MVP (6–8 тижнів)
- Онлайн-запис з календарем вільних слотів
- Каталог послуг та вибір витратних матеріалів
- Прив'язка кількох автомобілів до одного акаунту
- Сімейні знижки
- Адмін-календар завантаження сервісу
- Сповіщення та базова статистика
Ми працюємо поетапно, одразу закладаючи масштабованість та можливість подальших доопрацювань (ANPR, онлайн-оплата, склад, аналітика).
Пропонуємо обговорити деталі MVP — після цього зможемо:
- підтвердити стек (Flutter / React Native),
- зафіксувати етапи,
- сформувати обґрунтований бюджет та терміни.
Готові взяти проект в розробку та супроводжувати після запуску.
Бюджет: 4500 EUR Термін: 30 днів
Доброго дня, можу реалізувати крос-платформенний додаток для автосервісу з фокусом на зручну онлайн-запис, історію обслуговування та адмінку для майстрів, з MVP на Flutter і швидким запуском за 6–8 тижнів. Архітектуру одразу закладу з урахуванням масштабування (оплата, ANPR, склад), бюджет і етапи пропоную обговорити в особистих повідомленнях.
Бюджет: 1000 EUR Термін: 5 днів
Привіт! Готовий виконати цей проект, маю великий досвід розробки різних додатків.
Бюджет: 200 EUR Термін: 1 день
Доброго дня
Готова до співпраці. Великий досвід у веденні проектів, зокрема написання Технічного завдання (ТЗ), тестуванні, підборі та роботі з дизайнерами і розробниками для отримання вами потрібного результату. Впевнена, що зможу вам допомогти) Вартість погодинна
Досвід роботи РМ з розробки сайтів та мобільних додатків (плюс реклама) більше 8 років (4 роки в офісі і плюс зараз віддалено більше 4 років).
Знаходжусь у ТОП - 1 як технічний письменник
У ТОП - 2 з управління проектами
У ТОП - 8 з тестування
Готова допомогти при веденні клієнта, постановці завдань розробникам, тестуванні, написанні документації, прототипуванні, консультації не лише загальних питань, але й етапів розробки.
Бюджет: 1712 EUR Термін: 60 днів
Добрий день!
Готова розробити кросплатформений мобільний додаток для вашого автосервісу (iOS + Android) з веб-адмінкою. Пропоную реалізувати проект на Flutter для мобільних додатків і React для веб-адмінки. Бекенд можна побудувати на Firebase (Auth, Firestore, Storage, Cloud Functions) або на Node.js + PostgreSQL/MongoDB — це дозволить гнучко управляти даними і масштабувати функціонал.
Як я бачу етапи роботи:
MVP (6–8 тижнів, бюджет 85 000 грн):
- Реєстрація та авторизація клієнтів (email, Google/Apple)
- Додавання автомобілів і історії обслуговування
- Онлайн-запис з вибором послуг і дати/часу
- Сімейні знижки і базовий список послуг
- Адмінка: календар записів з ручним введенням номера автомобіля
- Push-сповіщення
- Проста статистика і звіти
- Розширення функціоналу (за узгодженням, окремий етап)
- Інтеграція ANPR для автоматичного розпізнавання номерів
- Онлайн-оплата (Stripe або аналог)
- Розширена аналітика і управління складом
- Фото-звіти і друк документів
- Підтримка і доопрацювання після запуску
- Виправлення помилок і багів
- Додавання нових функцій за необхідності
- Оптимізація продуктивності і UX
Вихідний код повністю передається, все робиться з урахуванням можливості подальшої доопрацювання.
Терміни MVP — 6–8 тижнів, бюджет — 85 000 грн, що дозволить створити якісний і стабільний додаток, готовий до експлуатації.
Якщо вам зручно, можу підготувати покроковий план розробки з мокапами екранів і архітектурою бази даних, щоб ви одразу бачили, як буде реалізований весь функціонал.
Буду рада обговорити деталі і приступити до проекту.
Бюджет: 3000 EUR Термін: 30 днів
Доброго дня, я можу зробити таку програму, маю досвід, якщо потрібно, то можу обґрунтувати по кожному пункту вашого ТЗ (наприклад, який бекенд краще і т.д.)
Бюджет: 2000 EUR Термін: 14 днів
Доброго дня.
З інтересом ознайомилася з Вашим проектом. Впевнена, що зможу зробити ефективну та якісну роботу, що відповідає Вашим вимогам та очікуванням. Досвід роботи понад 8 років. Готова обговорити деталі та розпочати роботу. Буду чекати Вашої відповіді, пишіть, обговоримо.
Бюджет: 6300 EUR Термін: 60 днів
Доброго дня!
Мене зацікавив ваш проект для автосервісу. Завдання зрозуміле і близьке мені за досвідом — це не просто додаток, а інструмент для оптимізації процесів сервісу та підвищення лояльності клієнтів.
Я досвідчений full-stack розробник з практикою створення складних продуктів «з нуля» (повний життєвий цикл від ідеї до роботи в реальних умовах).
Самостійно розробляв і запускав проекти рівня онлайн-таксі (мобільні додатки + адмінка + бекенд).
Також є досвід у роботі з камерами та розпізнаванням образів, що допоможе безшовно інтегрувати такий функціонал у майбутнє MVP.
Я працюю не тільки як розробник, але й вникаю в бізнес-логіку:
• аналізую процеси бізнесу (сервісу),
• допомагаю спростити роботу співробітників (майстрів),
• думаю наперед про масштабування (друга точка, мережа сервісів тощо).
Тобто ви отримуєте не «просто код», а MVP-рішення під реальні завдання ринку, яке не вимагатиме великих трудозатрат для переведення проекту в бойовий статус.
Терміни та формат роботи
• MVP: 6–8 тижнів (180 - 240 годин) (повністю укладається в заявлені рамки)
• Ставка: 30 EUR / година (за домовленістю, відкритий до обговорення)
• Вартість: 5400-6300 EUR (відкритий до обговорення або оптимізації під бюджет)
• Джерельний код передається повністю
• Готовий до подальшої підтримки та розвитку проекту після запуску
Буду радий обговорити деталі, пріоритети MVP і запропонувати оптимальну архітектуру під ваш бюджет.
Бюджет: 3000 EUR Термін: 30 днів
Добридень! Підтримую щодо Flutter, - на ньому можна ок зробити все (адмінку теж).
Щодо firebase, - я б все ж порадив заюзати Postgres (supabase), бо вже був досвід, коли файрбейз раптом став дорогим (багато клієнтів), а переїзжати без даунтаймів складно.
Щодо беку, - пропоную Hono (його можна розмістити на Cloudflare Workers, що коштуватиме 5$ на місяць, принаймні поки навантаження не виросте то дуже великіх обсягів), він норм працюватиме и на CF, і на будь якому хостінгу, якшо буде потреба.
Також використання Cloudflare знимає потребу в devops (він вміє сам збірати з github\gitlab репозіторія).
MVP можливо так, десь за місяць (+\-, тож 6 тижнів навіть з запасом).
Ціна, -3Кевро за MVP, дали треба буде дивитися, як рухатимется процес, гадаю, ще + так само раз на місяць, в залежності від того, які нові фічі зїявляться тощо
Бюджет: 5000 EUR Термін: 1 день
Вітаю, маю досвід реалізації застосунків від ідеї до публікації
Перший крок - це розробка дизайну з усією бізнес логікою. Потім переходимо до написання коду. Якщо є готовий дизайн, можемо починати працювати над частиною розробки.
Буду радий Вам допомогти!
Про компанію та поточну роботу Компанія продає товари через: кілька магазинів Rozetka; 5–8 магазинів Prom.ua; кілька магазинів Epicentr. Обсяг: орієнтовно 50–100 замовлень на день. Планується підключення хорошоп найближчим часомВикористовувані системи та способи оплати Rozetka; Prom.ua; Epicentr; Нова пошта; NovaPay; PrivatBank; monobank; RozetkaPay; Checkbox. Способи оплати: накладений платіж через Нову пошту / NovaPay; RozetkaPay; прямий переказ на IBAN; планується оплата за посиланням через еквайринг monobank. NovaPay та RozetkaPay перераховують гроші загальною сумою за реєстрами: в реєстрі NovaPay вказані ТТН; в реєстрі RozetkaPay вказані замовлення. Основні цілі Налаштувати KeyCRM так, щоб власник міг в одному місці: -Бачити всі замовлення з усіх магазинів. -Не втрачати замовлення та ТТН. -Бачити поточний стан кожної відправки. -Бачити фактичний рух грошей за замовленнями. -Автоматично пов'язувати отримані платежі з відповідними замовленнями. -Бачити неприв'язані платежі, недоплати, переплати та інші розбіжності. -Контролювати дії співробітників. -Мінімізувати ручну роботу.-Автоматичну фіскалізацію - Вибудувати автоматизацію правильну по руху замовлення Провести аудит діючого KeyCRM Перевірити: -поточні статуси, поля та автоматизації; -банківські та платіжні підключення; -ролі та права співробітників; -історію дій; -поточну настройку Checkbox; -можливість реалізації вимог штатними засобами KeyCRM. За результатами аудиту надати: -список знайдених проблем; -перелік необхідних налаштувань; -перелік завдань, для яких потрібна API-інтеграція або зовнішній сервіс; -рекомендації для кращої роботи сервісу -оцінку термінів та вартості. Налаштувати надходження та обробку замовлень Необхідно: налаштувати єдину послідовність обробки замовлень; налаштувати обов'язкові поля, без яких замовлення не можна передати на наступний етап; створити контроль замовлень, які не завантажились, завантажились з помилкою або залишились без відповідального. Налаштувати рух та звірку оплат Підключити до KeyCRM всі використовувані рахунки та платіжні сервіси: PrivatBank; monobank; NovaPay; RozetkaPay; еквайринг monobank після його підключення. Необхідно реалізувати: -Автоматичне отримання доступних виписок та транзакцій. -Відображення фактичних надходжень по кожному ФОП та рахунку. -Автоматичну прив'язку прямого платежу на IBAN до замовлення за номером замовлення в коментарі. -Звірку загальної виплати NovaPay з реєстром і подальшу прив'язку рядків реєстру до замовлень за ТТН. -Звірку загальної виплати RozetkaPay з реєстром і подальшу прив'язку рядків реєстру до замовлень за номером замовлення. -Автоматичну обробку оплат за посиланням після підключення еквайрингу. -Окремий список оплат, які неможливо зв'язати автоматично. Виявлення: -недоплати; -переплати; -часткової оплати; -дубльованої оплати; -оплати без знайденого замовлення; -замовлення, відміченого оплаченим без підтвердженого надходження. -Щоденну звірку сум по ФОП, рахункам та способам оплати. -Статус «Оплачено» повинен встановлюватись автоматично після підтвердженого зарахування грошей на відповідний IBAN. Співробітники не повинні мати права встановлювати його вручну. Якщо штатних можливостей KeyCRM недостатньо, інтегратор повинен: пропонувати API-інтеграцію або зовнішній модуль; описати його логіку; окремо оцінити розробку; забезпечити журнал помилок та повторну обробку; не прив'язувати оплату автоматично при неоднозначному збігу. Налаштувати контроль втрачених замовлень Потрібен окремий робочий список або звіт: замовлення надійшло, але не взято в роботу; замовлення підтверджено, але не передано на склад або дроп; замовлення готове, але ТТН не створена; ТТН створена, але посилка не передана перевізнику; посилка довго не рухається; клієнт не забирає посилку; була переадресація; почався повернення; повернена посилка не отримана компанією; замовлення доставлено, але оплата не зарахована; оплата отримана, але не пов'язана з замовленням; замовлення залишилось в проміжному статусі довше допустимого терміну. По кожному виключенню повинні бути: відповідальний; термін реакції; завдання або сповіщення; зрозуміла причина; посилання на замовлення. 4.7. Налаштувати права та контроль співробітників Обов'язкові обмеження: -співробітники не можуть видаляти замовлення; -співробітники не можуть вручну ставити статус «Оплачено»; -співробітники не мають доступу до банківських підключень, API-ключів та адміністративних налаштувань.Налаштувати Checkbox Зараз чеки з KeyCRM не створюються. Інтегратору необхідно: -перевірити існуючі кабінети, каси та касирів Checkbox; -підключити каси відповідних ФОП; -налаштувати способи оплати; -налаштувати автоматичну фіскалізацію для погоджених сценаріїв; -налаштувати обробку помилок; -налаштувати чеки повернення; -провести тестування.Налаштувати звіти для власника Власник повинен бачити: -кількість нових і необроблених замовлень; -проблемні відправлення; -посилки в відділенні; -повернення; -доставлені замовлення без отриманої оплати; -отримані, але неприв'язані платежі; -недоплати та переплати; -ручні зміни співробітників.Формат може бути реалізований штатними списками, фільтрами, аналітикою, завданнями або зовнішнім звітом — спосіб пропонує інтегратор. Навчити співробітників Після налаштування провести навчання: власника — контроль, звіти, помилки та права; менеджерів — обробка замовлень; співробітника дропа — передача замовлення та контроль ТТН; співробітника складу — створення ТТН та відправка; відповідального за фінанси — обробка неприв'язаних платежів та розбіжностей. Надати короткі інструкції або відеозаписи основних операцій. Очікуваний результат Після виконання робіт: -всі замовлення обробляються в KeyCRM; -пропущені та завислі замовлення автоматично виявляються; -кожна ТТН пов'язана з замовленням і відстежується; -проблемні посилки потрапляють відповідальним співробітникам; -банківські та платіжні надходження видимі в CRM; -однозначні платежі автоматично пов'язуються з замовленнями; -реєстри NovaPay та RozetkaPay звіряються з надходженнями та замовленнями; -неоднозначні платежі потрапляють на ручну перевірку; -співробітники не можуть видалити замовлення або вручну відзначити його оплаченим; -власник бачить рух грошей і список відхилень; -Checkbox працює за погодженими сценаріями; -команда навчена роботі. Формат пропозиції від інтегратора До початку впровадження виконавець повинен надати: -Результат аудиту. -Пропоновану схему налаштування. -Що буде реалізовано штатними засобами KeyCRM. -Що вимагатиме API або зовнішнього сервісу. -Вартість штатної настройки. -Окрему вартість розробки. -Терміни по етапах. -Перелік необхідних доступів. -План тестування та запуску.
Розробка міжнародного мобільного додатку під ключ (Дизайн + Код) Для здешевлення, можливо не робити в купити готовий дизайн 1. Загальні вимоги до проекту Платформа: Кросплатформова розробка на фреймворку Flutter (один код під iOS та Android). Тип платформи: Соціальний беттінг / Ігрові суперечки на дисципліну (Peer-to-Peer 도전戰). Завдання Виконавця: Повний цикл розробки (UI/UX Дизайн у Figma, фронтенд, бекенд-сервер, база даних, інтеграція IoT-датчика контролю та платіжного шлюзу). Мультимовність: Повна підтримка локалізації (i18n) та робота з кількома валютами. 2. Вимоги до UI/UX Дизайну Потрібна розробка сучасного, неоново-технологічного інтерфейсу в темних тонах (Dark Mode). Акцентні кольори: Глибокий графітовий (фон), яскравий зелений (фінанси, баланс), яскравий червоний (режим охорони включень, штрафні події). Функціонал: Відображення 4 головних екранів нижньої навігації (Дашборд, Ігрові кімнати, Гаманець, Налаштування пристрою). Потрібні динамічні анімації зміни балансу та спливаючих алертів. 3. Фінансова архітектура (Escrow/Holding/Split) Додаток пов'язань на утримання депозитів за дотримання правил дисципліни. Критично важливою є інтеграція платіжного шлюзу, що підтримує Split Payments (Розщеплення платежів) та Холдування коштів (Stripe Connect для глобального ринку/аналоги для локального). Логіка транзакцій (API-команди бекенда): Поповнення: Кошти користувачів прив'язуються до їх облікового запису та заморожуються на транзитному (ескроу) рахунку платіжної системи. Вони не надходять безпосередньо на рахунок компанії. Режим SOLO: При настанні тригерної події від IoT-датчика у заборонених годин бекенд дає команду платіжній системі перевести фіксовану суму (штраф) з транзитного рахунку користувача на розрахунковий рахунок компанії. Режим GROUP (Кімнаті): Користувачі формують загальний пул (наприклад, 10 осіб $10). Гроші заморожуються у межах конкретної Ігрової Кімнати. При настанні тригерного події в одного з учасників сума його штрафу автоматично розщеплюється: 15% (комісія платформи) йдуть на розрахунковий рахунок компанії, а 85% залишаються усередині призового фонду кімнати. Після закінчення терміну челенджа бекенд автоматично розподіляє нагромаджений призовий фонд між переможцями, а платіжна система робить автоматичний переказ (Payout) ним на картки. 4. Структура кабінетів Кабінет 1: "Персональний Трекер" (Режим SOLO) Індикатор статусу моніторингу (Активний/Доступний/Заблокований). Конфігуратор часових інтервалів охорони (Time Picker) та налаштування вартості штрафного тригера. Панель стану зовнішнього пристрою IoT (заряд батареї датчика у %, рівень сигналу, статус синхронізації). Кабінет 2: «Ігрові Кімнати» (Режим GROUP) Інструментарій створення приватних кімнат (генерація інвайт-посилань/кодів для друзів) та список публічних глобальних ліг. Турнірна таблиця (Лідерборд) учасників з відображенням їхнього поточного статусу в реальному часі, таймер до кінця челленджа та вбудований груповий чат. Загальний розділ: Мультивалютний гаманець Відображення балансу з автоматичним конвертуванням локальних валют у реальному часі. Історія транзакцій із прозрачним логом списань, комісій та виграшів. 5. Вимоги до Бекенду та Інтеграції IoT Стек: Node.js/Python/Go (на вибір виконавця, аргументовано). Зв'язок із IoT: Прийом пакетів даних від зовнішнього Wi-Fi модуля. Швидкість надсилання Push-повідомлення (через FCM) на смартфон при настанні події від датчика – менше 1 секунди. Антифрод-логіка: Сервер повинен аналізувати передані датчиком телеметричні дані вбудованого акселерометра (accel_x/y/z). Якщо подія відбувається при нульовій зміні осей прискорення, транзакція позначається системою як підозрілий (захист від статичного утримання датчика), користувачеві надсилається попередження.
Нам потрібно підключити платіжну систему до high risk сайту. Основні вимоги — прийом фіатних коштів та виведення коштів у криптовалюту. Бажано no kyc. Тільки тим, хто мав подібний досвід. Ціна — за домовленістю