Technological tasks
The Tech-tasks module is tasks related to the development, implementation and improvement of new technologies, products and processes. If you have development, implementation and other needs you can post information below.
Intelligent Search
Goal: To develop an AI-based service (LLM + Vision models) for implementing multimodal search functionality and personalized recommendations on the e-commerce finishing materials platform. Description: The system must accept text queries or images as input, conduct a semantic search through the customer's product catalog and generate an expert advice article in real time. The delivery is carried out as an isolated Docker container for deployment in the customer's infrastructure (on-premise).
Decision acceptance deadline
27.02.26 (inclusive)
Preferred systems
Neurotechnology and artificial IntelligenceNumber of applications
7
Plugin development for iiko
Develop an interaction plugin between our loyalty system and iiko front
Decision acceptance deadline
26.02.26 (inclusive)
Preferred systems
Technologies in telecommunicationsNumber of applications
7
Budget Protection Module
Development of an algorithm for automatic control of limits for advertising campaigns with minimal delay. Create a microservice "watchman" that checks the internal balance of the wallet in almost real time with the predicted consumption in external systems and forcibly stops the impressions when a critical threshold is reached.
Decision acceptance deadline
25.02.26 (inclusive)
Preferred systems
Information processing and transformationNumber of applications
4
Determining the demand for unmanned aircraft systems with a load capacity of up to 5 kg in the civilian sector
Assessment of the demand potential and prospects for the development of the unmanned aircraft systems (UAS) market in the Republic of Kazakhstan, depending on the payload capacity, functional purpose and application areas.
Decision acceptance deadline
24.02.26 (inclusive)
Preferred systems
Unmanned aerial vehiclesNumber of applications
3
Development of an intelligent quality control system for clinic staff
The purpose of the system Create a digital tool that: • collects data on the work of employees • analyzes them according to uniform criteria • identifies deviations and strengths • generates understandable metrics and reports
Decision acceptance deadline
24.02.26 (inclusive)
Preferred systems
Other technological solutionsNumber of applications
5
Creation of a unified integration layer (Integration Gateway / Digital Core)
The purpose of the project Create a single integration layer that will become: • a central data exchange point • the standard for the interaction of all internal and external systems • the "bus" of the clinic's digital ecosystem • the basis for scaling and connecting new services
Decision acceptance deadline
24.02.26 (inclusive)
Preferred systems
Other technological solutionsNumber of applications
5
Development of an algorithm for intelligent optimization of a patient's route in a medical clinic (Protocol)
The purpose of the algorithm Create an algorithm that automatically generates the optimal route for the patient, taking into account: • medical recommendations • loading the clinic • Patient restrictions • Treatment priorities • the probability of completing the course
Decision acceptance deadline
24.02.26 (inclusive)
Preferred systems
Other technological solutionsNumber of applications
6
Creation of a neural network for processing and analyzing data from medical clinic clients
The purpose of the project Create a neural network that: • combines all patient data into a single model • analyzes behavior, medical and service parameters • reveals hidden patterns • predicts key events • helps the clinic to make management and medical decisions
Decision acceptance deadline
24.02.26 (inclusive)
Preferred systems
Other technological solutionsNumber of applications
7
Creation of an integrated SaaS solution for tracking and analyzing call center calls in a digital medical system
Create a SaaS solution that: • automatically captures and analyzes call center calls • provides objective analysis of the quality of communications • identifies the causes of patient loss • integrates with medical CRM / MIS / Digital Clinic Hub • helps to increase conversion without increasing the advertising budget
Decision acceptance deadline
24.02.26 (inclusive)
Preferred systems
Other technological solutionsNumber of applications
5
Creating a back office platform
1. Общая цель и контекст проекта Нужно создать единую внутреннюю платформу для бэк-офиса компании (административный контур), которая заменит разрозненные таблицы, чаты и ручные согласования. Платформа должна собрать в одном месте задачи, документы, заявки, бюджеты, платежи, статусы и контроль исполнительской дисциплины. Главная ценность: прозрачность, управляемость, контроль сроков и денег, снижение хаоса и “потери” задач между людьми и подразделениями. 2. Что считается “бэк-офисом” в рамках платформы Внутренние подразделения и функции, которые обслуживают основной бизнес: финансы/оплаты, закуп/счета, договора, маркетинг-операции, подрядчики, HR-админ, IT/доступы, юридические согласования, контроль бюджета, календарь встреч/обязательств, контроль KPI/отчетности. Важно: платформа не для пациентов/клиентов, а для сотрудников компании. 3. Основные пользователи и роли Нужно ролевое разграничение доступа (RBAC). Минимальные роли: Администратор системы (создает роли, доступы, настройки). Руководитель (видит отчеты, бюджеты, статусы всех задач, утверждает заявки). Менеджер/координатор (создает и ведет заявки, задачи, документы). Исполнитель (получает задачи, сдает результат, прикрепляет файлы). Финансист/бухгалтерия (обрабатывает оплаты, счета, статусы оплат). Юрист (согласование договоров, правки, статусы). Маркетинг-оператор (размещение материалов, контроль подрядчиков). IT-специалист (доступы, интеграции, техподдержка). Опционально: внешний подрядчик (ограниченный доступ только к своим задачам/файлам). 4. Ключевые проблемы, которые платформа должна решить Заявки и задачи теряются в мессенджерах и устных договоренностях. Нет единого источника правды по статусам: кто делает, какой срок, что согласовано. Бюджеты “переваливают” или “недокручиваются” без контроля. Нет прозрачного процесса согласования счетов и оплат. Нет единого архива договоров/документов с версиями и комментариями. Нет системной фиксации встреч, обязательств и дедлайнов (в календаре и в задачах). Сложно понять нагрузку по команде и контроль исполнения. 5. Модули платформы (что должно быть внутри) 5.1. Модуль “Заявки” (единый вход) Это основа. Любая потребность в бэк-офисе оформляется как заявка. Типы заявок: Оплата/счет (поставщик, сумма, дедлайн, основание). Закуп/заказ (что купить, сколько, где, кому нужно, срочность). Договор/юридическое согласование (контрагент, предмет, версия файла). Маркетинг-заявка (креатив, размещение, тексты, дизайн, сроки). IT-заявка (доступы, настройка, интеграции, баги). HR-заявка (справки, документы, оформление). Каждая заявка имеет: номер, автора, подразделение, приоритет, дедлайн, ответственного, статус, чек-лист, файлы, комментарии, историю изменений. Статусы: “Новая” → “В работе” → “На согласовании” → “Ожидает оплаты/выполнения” → “Выполнено” → “Закрыто”. Плюс: “Отклонено” и “Возврат на доработку”. 5.2. Модуль “Задачи” (исполнение) Из заявки автоматически создаются задачи по шагам и назначаются исполнителям. Поддержка зависимостей (задача Б после задачи А). Подзадачи, чек-листы, вложения, комментарии. Напоминания и просрочка. Сдача результата: обязательное поле “что сделано” + приложить файл/ссылку. Возможность “вернуть на доработку” с причиной. 5.3. Модуль “Финансы и оплаты” Реестр счетов и оплат: Карточка счета: контрагент, реквизиты, сумма, валюта, назначение, проект/филиал, статья бюджета, дедлайн оплаты, файл счета, договор/основание, кто согласовал. Статусы: “Получен” → “На согласовании” → “Согласован” → “Оплачен/В оплате” → “Закрыт”. Контроль бюджета: фиксируем “план” и “факт”, отклонения, причины. Важная логика: нельзя отправить “в оплату” без обязательных полей (основание/документы/согласование). Экспорт в Excel/CSV обязателен. 5.4. Модуль “Бюджеты и лимиты” Бюджеты по: месяцу, проекту, филиалу, статье расходов, ответственному. Лимитирование: если заявка/счет превышает лимит, система требует дополнительного согласования (например, руководитель/фин директор). Поля: план, фактические траты, остаток, прогноз (по заявкам “в работе”). Отчет “перевалили/недокрутили бюджет”. 5.5. Модуль “Документы и договоры” Единый архив: договоры, допсоглашения, счета, акты, ТЗ, референсы. Версионность: новая версия файла не затирает старую. Маркировка статусов: “Черновик”, “На согласовании”, “Подписан”, “Истек/закрыт”. Поиск по названию/контрагенту/дате/проекту. Права доступа по ролям. 5.6. Модуль “Календарь и встречи” Встречи должны фиксироваться внутри платформы и/или синхронизироваться с Google Calendar. Обязательные поля: тема, участники, дата/время, цель, список обязательств по итогу. Автоматическое превращение “обязательств” в задачи с дедлайнами. Отдельный раздел “обязательства руководителю/команде” для контроля. 5.7. Модуль “Отчетность и дашборды” Для руководства: Сводка по заявкам (сколько новых/в работе/просрочено). Сводка по оплатам (ожидает согласования, в оплате, оплачено). Бюджет план/факт по периодам. Нагрузка по сотрудникам (сколько задач, просрочка, средний срок закрытия). Фильтры: город/филиал/проект/тип заявки/ответственный/период. 5.8. Модуль “Коммуникации внутри задач” Комментарии, упоминания @, уведомления. Шаблоны сообщений: запрос уточнения, согласование, возврат на доработку. История активности: кто что изменил и когда. 6. Бизнес-логика и правила Приоритеты: низкий/средний/высокий/срочно. SLA: для срочных заявок — обязательное подтверждение принятия в работу. Эскалации: если просрочка N часов/дней — уведомление руководителю. Контроль качества: закрыть задачу можно только при заполненном “результате” и приложенном файле/ссылке (если тип задачи это требует). Обязательные поля зависят от типа заявки. Заявка “Оплата” не может перейти в “Согласован” без прикрепленного счета + основания (договор/акт/ТЗ). 7. Интеграции (желательно, но прописываем как требования) Google Workspace: Google Calendar (встречи). Google Drive (хранение файлов, либо внутреннее хранилище). WhatsApp: Генерация ссылок/кнопок “написать в WhatsApp” для внутренних процессов не обязательно, но уведомления в WhatsApp можно как опцию (если будет API/провайдер). Email: уведомления о статусах, согласованиях. CRM/колл-центр/регистратура (если у вас есть) — пока можно как этап 2, но в ТЗ предусмотреть “API-ready” архитектуру. 8. Нефункциональные требования Веб-версия обязательна, адаптив под мобильный желателен. Скорость: загрузка страниц до 2–3 секунд при обычной нагрузке. Надежность: логирование ошибок, бэкапы. Безопасность: роли, права, журналы аудита, защита данных. Хранение данных: база данных + файловое хранилище. Локализация RU (минимум), KZ опционально. 9. Техническая архитектура (можно как рамки) Front: web (React/Vue — на выбор подрядчика). Back: REST API. DB: PostgreSQL/MySQL. Файлы: S3-совместимое хранилище или Google Drive интеграция. Авторизация: JWT + роли, либо SSO Google Workspace. 10. Этапы внедрения (чтобы подрядчик понимал объем) Этап 1 (MVP, 4–8 недель условно): заявки + задачи + базовые роли + уведомления + файлы. Этап 2: финансы/счета + бюджеты + согласования. Этап 3: документы/договоры + календарь + расширенная аналитика. Этап 4: интеграции с внешними системами (CRM/колл-центр/регистратура). 11. Что вы хотите получить от разработчика в ответ на ТЗ Оценка сроков по этапам. Оценка стоимости по этапам (или диапазон). Предложенная архитектура и стек. Макеты экранов или прототип (Figma) на ключевые сценарии. План внедрения и обучения пользователей. Условия поддержки после релиза (SLA, багфикс, доработки). Уточнение по хостингу и владению кодом. 12. Коммерческая часть Стоимость работ определяется после обсуждения, уточнения требований и рассмотрения заявки подрядчика. Подрядчик должен предложить смету по этапам и условия сопровождения.
Decision acceptance deadline
23.02.26 (inclusive)
Preferred systems
Other technological solutionsNumber of applications
12
