ИТ-проекты пикабушников

Проблема

Если коротко, то у онлайн-школ есть основная проблема, им каждый день пишут много студентов, особенно во время онлайн-трансляций, и в эти моменты они не успевают отвечать всем сразу. Вопросы, могут быть такого плана:

• «Где ссылка на вебинар?»

• «Почему не открывается урок?»

• «А запись будет?»

• «Не могу войти в личный кабинет»

Решение

Мы сделали ИИ-сотрудника поддержки, который встраивается в GetCourse и сам отвечает на типовые вопросы, видит статусы учеников, оплаты и уроки, а сложные случаи передаёт человеку.

Просто подключил и...

Если честно, то нейросеть подключить непросто. Не достаточно заплатить нам деньги и все заработает, как минимум потому что "ИИ-сотрудника" нужно настроить, а именно:

• Составить базу знаний школы, по которой будет отвечать ИИ (вопросы про цены, состав курса, преподавателей и т.п)

• Настроить логику работы учитывая специфику школы (если "это", тогда сделай "это". Например: "Если не знаешь ответ, передай вопрос менеджеру")

• Составить промты под описанную логику, чтобы соответствовать стилю школы

Сначала никто не хотел покупать, так как многие уже обожглись обертками ChatGPT, которые писали бред и откровенно вредили репутации бренда

Как это работает на примере школ

Первая продажа была ооочень сложной и случилась буквально через нетворкинг. Один мой знакомый знал другого... Таким образом вышли на школу.

Онлайн-школа "Лунара"

Проводит до 15 параллельных вебинаров, где участвуют тысячи учеников. На одного сотрудника поддержки получается около 120−140 обращений в день, а время ответа от 30 минут и выше.

Каждый запуск для школы это боль, потому что приходится выводить на линию больше людей. Хочешь больше продаж, нанимай еще больше людей.

Чтобы решить проблему, мы сделали следующее:

1. Разложили все обращения по типам

2. Собрали структурированный FAQ

3. Обучили на этом AI и встроили его в GetCourse

4. Настроили правила типа: "не уверен — передай человеку"

5. Несколько раз докрутили тон и формулировки

В итоге, не с первого раза, но все заработало. AI стал закрывать около 30% обращений сам. Нагрузка на людей упала почти вдвое, а время ответа сократилось, при том что качество не упало.

После этого кейса уже было совсем просто подключать другие школы, так как были конкретные результаты, плюс к нам приходили по рекомендациям.

Примеры ответов

В итоге, почему такой "простой" продукт «зашёл»

На бумаге всё выглядит просто: «Сделайте ботика в GetCourse, чтобы на сообщения отвечал», но по факту «очевидное» мало кто делает нормально.

• Первое, наше преимущество оказалось в том, что мы выбрали узкую и понятную нишу. Продюсеру не надо объяснять, что мы делаем. Он слышит: «мы экономим Х% от вашего ФОТ на поддержке в GetCourse» и все.

• Второе, мы сразу выбрали узкую нишу и начали бить только в эту сторону. Не отвлекались на все остальное.

• Третье, мы не сорили фичами не делали все подряд, а сознательно начали с одного самого горячего функционала — поддержки.

• Четвертое, мы запустили первый и единственный сервис интегрированный именно с GetCourse. Другие пока только работают в самих школах, но не интегрированы

Если у вас онлайн-школа на GetCourse

Меня зовут Александр Иванов

Если вы хотите подключить бота, который сможет отвечать на 80% сообщений в поддержке, то просто напишите мне в телеграм (@GoldBatya)

Посчитаем вместе сколько стоит ваша поддержка сейчас и окупиться ли внедрение нашего ИИ-сотрудника.

• Доставка до клиента организована на уровне магазинов (не склада).

• Товарная матрица жёстко фиксирована: перемещение ассортимента между точками возможно только в рамках допустимых категорий (например, нельзя заменить «Телефоны» на «Хлеб» при перераспределении).

• Доступны фактические данные по:

  • продажам (с доставкой / без),

  • остаткам на точках,

  • SKU-уровню заказов с доставкой (включая адреса и объёмы).

На основе этих данных можно реализовать следующие аналитические и управленческие модули:

1. Определение зон покрытия магазинов
   По адресам доставок (без привязки к квартирам) и частоте заказов за период (например, за год) строится геопространственная область — зоны ответственности каждого магазина. Границы определяются экстремальными точками доставок.

2. ABC-анализ по SKU на уровне точки
   На основе фактических продаж формируется структура ассортимента: приоритетные, средние и низколиквидные SKU — с учётом оборачиваемости и вклада в выручку.

3. Моделирование альтернативного размещения при закрытии точки
   Сопоставление товарных матриц, зон покрытия и ABC-профилей позволяет идентифицировать подходящие точки-реципиенты для перераспределения остатков — с минимальными логистическими и коммерческими потерями.

4. Планирование перераспределения
   Комбинируя:

   • текущие остатки (на отправляющей точке),

   • лимиты хранения и нормативы по категориям (на принимающих точках),

   • совместимость товарных матриц,

   • пересечения зон покрытия и клиентской базы,
     формируется оптимальный план перемещения запасов — как при частичной реорганизации сети, так и при полном закрытии объекта.

Пример конфигурации:
Объект А характеризуется своей зоной покрытия и текущими остатками. Объекты Б, В, Г и др. — собственными остатками, ограничениями хранения по категориям, продажной динамикой и клиентскими зонами. Система оценивает все взаимодействия и предлагает планы по перераспределению товаров (Зон ожидается в будущем)

Компания Х решила закрыть объект А. Теперь нужно оценить, как это повлияет на:

- остатки товаров в других магазинах и на складе;

- зоны доставки других магазинов;

- среднее время доставки клиентам и стоимость перераспределения товарных остатков.

На основе этого анализа мы составим техническое задание для программы. Вот его основные пункты:

1. Определить регион, в котором находится объект А.

2. Выяснить фактические остатки товаров на этом объекте.

3. Найти ближайшие объекты с аналогичной товарной матрицей.

4. Провести ABC-анализ товаров на всех объектах за последний год.

5. Разработать план перераспределения товаров. Учитывать информацию из пунктов 1–3, а также средние затраты на перевозку одного кубического метра (задается при создании региона). Рассчитать оптимальное перераспределение.

Предложенная логика в целом корректна, однако в текущей реализации не учитывается стоимость доставки как функция пройденного расстояния или объёма груза.

Например, можно оперировать не стоимостью за километр, а средней себестоимостью перевозки на единицу объёма — скажем, при известных затратах в 1,5 млн ₽ на перевозку 160 м³ получаем удельную стоимость ~9,4 тыс. ₽/м³. (Цифра условная и приведена для иллюстрации.)

Более гибкий и масштабируемый подход — задать набор типов транспорта («траков») с атрибутами: тип маршрута, грузоподъёмность, объём и соответствующая средняя стоимость перевозки. Это позволит учитывать различия в логистике более точно.

С учётом этого, скорректирую модель и вернусь к дальнейшей проработке.

Программа, следуя установленным правилам, рассчитывает оптимальное размещение товаров. Если отключить АВС-анализ, она будет учитывать только остатки, местоположение и матрицу.

Ниже приведу пример работы данного функционала, данные заглушка и программа не может правильно разместить товары, поэтому все = 0.

P.S. Сейчас создание достоверных данных не является приоритетом.

Да, так как и писал - данные тестовые и в самом деле в регионе нет аналогичных матриц

Аналогично скрину выше, не нашли куда перевозить, доставка = 0.

И теперь основной вопрос "А что будет с доставкой? Как сильно закрытие повлияет на SLA по скорости?". Данный расчет сейчас является приоритетной доработкой которой я занимаюсь.
Логика которая мною вкладывает в анализ - следующая:

1. Смотреть на расстояние различных точек на карте

2. Делить действующую зону на кластеры

3. Определить оптимальные объекты по времени которые находятся рядом

4. Сделать ренден всех 3-ех пунктов и показывать изменения в зонировании доставки с отчетом об изменении среднего времени и какие районы слишком далеко.

Для инфраструктуры это очень важный фактор, от которого зависит многое. Так же этот фактор должен работать и при открытии нового объекта. Но сейчас такой функционал не реализован

Функция выбора источника данных для программы и совместная работа с одним исполняемым файлом.

В параллели с влиянием на регион, мне удалось внести не большую доработку в систему. Теперь пользователи могут выбирать исполняемый файл.

2 пользователя работают с одним исполняемым файлом, вносят корректировки, строят дашборды, удаляют или дополняют данными программу. Но как копии приложения узнать что внесены изменения в хранилище? Для этого было реализовано metadata таблица. исполняемое приложение запускается, запоминает метаданные времени БД и проверяет обновления, в случае изменения метаданных моментально сигнализирует о том что необходимо обновить данные.

В рамках подготовки программы к первому тестированию на живых данных в нашей компании была реализована функция "Отправить отчет об ошибке".

После отправки - логи приходят ко мне в ТГ через бота. Все логи запаковываются в zip архив, параллельно запускает процесс удаления логов из папки.

Почему я быстрее реализовал совместный доступ и отправку логов, вместо того что бы наполнить данными и показать на примере где все логично? Наверное потому что лень тратить много времени на создание данных, а потом их дополнять и править. Программа не окончательная, система хранения меняется. Например сейчас я понял что стоимость доставки и распределения товара можно завязать на типы траков - буду реализовывать и менять хранение. Менее затратно по времени дописать скрипт, чем создавать новую логику в 1000 строк данных.

Всем спасибо за то что дочитали.

Если есть желание предоставить тестовые данные с логикой - буду очень рад, поможет при тестировании. Шаблон данных могу предоставить.

желтый, как вы понимаете, неподтвержденный урок. он ожидает подтверждения от ученика, чуть позже добавлю туда клавишу "подключиться к видеоконференции".

Вид со стороны ученика:

И... как долго я ругался с этим фронтом, ненавижу js! С сервером проблем нет и небыло за все время! написал сервисы, эндпоинты, энтити, все работает, curl запросы отправляет, данные ходят во все стороны, но на странице нормально не отображается, или вообще модальное окно не открывается вовсе. Но, я победил.

следующий этап: "оставьте отзыв" на преподавателя и кастомизация подключение jitsi.

еще пришла в голову идея сделать тесты для пользователей, чтобы учитель мог сделать на платформе тестовые формы, и мог давать их своим ученикам.

точки и запятые насыпал вот тут: .............,,,,,,,,,,,,,,,, кто "чувствительный" могут брать оттуда и расставлять по своему усмотрению.

как то так, всем спасибо за внимание!

Час 1 — из идеи в «о, оно уже что-то умеет»

В lovable.dev набросал задачу в духе:

«Сделай веб-сервис, где пользователь вводит параметры объекта недвижимости, а сервис генерирует описание. Нужны фронт и бэк».

Через какое-то время у меня:

• уже есть работающие основные "команды"

• компоненты

• базовые стили

• бэкенд-эндпоинты

Технически всё ок, но визуально это кричало:
«Я — авто-сгенерированный шаблон, меня делали за пять минут».

Поэтому первый час ушёл на приведение этого в человеческий вид:

• подчистил верстку

• попросил сделать интерфейс более минималистичным и сфокусированным

• поправил отступы и шрифты, чтобы не выглядело как демка конструктора

• упростил сценарий: зашёл → ввёл параметры → нажал «сгенерировать»

Без фигмы, без дизайна в сто итераций. Просто спорил с ИИ ассистентом, пока картинка не стала минимально приятной.

Через час уже был понятный интерфейс, которым не стыдно пользоваться.

Час 2 — прикручиваем мозги: ИИ, база и PDF

Когда внешне всё перестало раздражать, надо было заставить сервис делать что-то полезное.

Во второй час я попросил подключить ИИ модель и базу данных.

Генерация текста

• настроил бэкенд-эндпоинт, который принимает ввод пользователя и настройки

• подключил к нему вызов модели

• добился, чтобы на фронт возвращалась не просто простыня текста, а нормальная структура

База данных

Сохраняю:

• сгенерированные описания

• немного метаданных — какие параметры были, когда сгенерировано и т. д.

Это нужно, чтобы потом можно было посмотреть, чем люди вообще пользуются и что стоит улучшать.

PDF

• сделал эндпоинт, который берёт готовый текст

• рендерит его в аккуратный PDF

• отдаёт файл на скачивание

Итого ко второму часу у меня уже есть рабочее ядро:

Пользователь вводит данные → жмёт кнопку → получает описание + PDF.

Не идеально, но больше, чем «получите ваш список параметров обратно».

Час 3 — домен, HTTPS и ощущение «что-то поехало»

Следующий логичный шаг — вытащить всё это на нормальный домен.

В несколько кликов получилось:

• зарегистрировать realt-texts.com

• привязать его к сервису (там какая-то магия была, в основном все само случилось)

И вот через какое-то время применились все настройки, вбиваю в адресную строку только что купленный домен — и там открывается мой сервис.
Красота!

+8 часов — ИИ пишет, но читать это не хочется

На этом этапе можно было бы сказать «ну всё, готово», но нет.

Интерфейс есть, логика есть, домен есть.
Пробую генерировать тексты — и получаю:

«Предлагается к вашему вниманию прекрасная квартира, которая станет идеальным вариантом для комфортной жизни…»

То есть формально всё нормально, но сухо, однообразно и кривовато.

И.... дальше примерно 8 часов ушло на то, чтобы ИИ перестал звучать как робот.

Что пришлось делать

1. Мучить system prompt

Переписывал его много раз, задавая:

• более живой тон

• нежелательные клише и фразы

• как себя вести, если информации мало

• как реагировать, если пользователь прислал гигантский текст со своими формулировками

2. Тестировать реальные сценарии

Гонял всё подряд:

• «мне нужно описание студии в новостройке» — и больше ничего

• длинные описания с кучей условий и запретов

• кривые, обрывочные фразы — как обычно пишут в реальных формах

3. Борьба с тараканами

Вылезали классические проблемы ИИ:

• слишком общий, безликий текст

• игнорирование части инструкций

• неожиданные скачки стиля — от "канцелярита" до странного дружеского «эй, бро, смотри какая квартирка»

4. Задание структуры

Пришлось более жёстко задавать рамки:

• примерную длину описания

• порядок: сначала локация и ключевые плюсы, потом уже детали

• как обходиться с отсутствующей информацией — чтобы ИИ не додумывал «вид на море» там, где максимум вид на соседний подъезд

И да, это действительно заняло больше всего времени.
Код, база, домен — всё это делается намного быстрее, чем «сделай так, чтобы ИИ писал как нормальный человек».

+2 часа — полировка, чтобы не казалось, что это сырая демка

Когда тексты перестали вызывать внутренний фейспалм, я сел доводить всё до состояния «этим не стыдно поделиться с незнакомыми людьми».

За примерно 2 часа:

• сделал адекватные состояния загрузки, пока модель думает

• добавил нормальную обработку ошибок, чтобы вместо сухой «ошибка» был понятный текст

• переписал подписи на кнопках и подсказки, чтобы всё звучало проще и дружелюбнее

• проверил мобильную версию и поправил всё, что поехало на маленьких экранах

Вроде мелочи, но уже ощущение, что у меня получается что-то приличное.

Аналитика, cookies и немного SEO

Перед тем как думать о посетителях, хотелось хотя бы понимать, что они будут делать на сайте, а еще у нас же международный сервис - нужно кукис принимать в явном виде.

За примерно час:

• подключил Google Analytics, проверил, что события прилетают

• добавил простой баннер про cookies (там тоже как-то сразу из гугла мне предложило несколько сервисов, которые это настраивают)

После этого уже имело смысл чуть-чуть заняться SEO.
Тут помог ChatGPT:

• накидали фразы, которые могут вводить риелторы и продавцы

• переписали заголовок страницы, описание и часть текста так, чтобы и понятно было, и поисковикам не грустно

• нагенерили тексты, описания, отзывы (ну да, грешен :)

Настоящим SEO это не назовёшь, но для старта пока нормально.

Что по времени в итоге

• 1 час — базовый внешний вид и верстка

• 1 час — генерация текста + база + PDF

• ~1 час суммарно — домен, аналитика, cookies

• 8 часов — настройка поведения ИИ и промптов

• 2 часа — полировка интерфейса и пользовательских мелочей

• 2 часа — мини-SEO вместе с ChatGPT

В сумме получилось около 15 часов от идеи до живого AI-сервиса на отдельном домене.

• 📝 Перехват удаленных сообщений. Если собеседник отправил сообщение, а через секунду его удалил, бот успеет пересылать вам копию. Это работает со всеми типами контента: текст, голосовые, стикеры, файлы, геолокация и т.д.

• 🔄 История изменений. Когда кто-то редактирует свое сообщение, меняя его смысл, бот присылает наглядное уведомление в формате «Было» / «Стало».

• 📸 Сохранение исчезающих медиа. На мой взгляд, это самая сильная функция. Бот умеет перехватывать самоуничтожающиеся фото и видео. Вместо одноразового просмотра вы получаете полноценный медиафайл, который сохраняется в вашем чате с ботом.

Немного цифр и первых инсайтов

За несколько месяцев тестирования накопилось примерно 21 тысяча событий (изменение/удаление/исчезающие медиа). И главное открытие: люди куда чаще отправляют исчезающие медиа, чем удаляют текст. Текст чаще просто исправляют. А вот фото — прячут намеренно.

P.S. (это анонимные логи операций, не содержащие содержание сообщений — только типы действий: удаление, редактирование, исчезающие медиа). Если что — бот не сидит с лупой над вашей перепиской. Максимум, что он “видит”, это то, что кто-то где-то что-то удалил. Представляете? У нас даже нет пункта «почитать драму», только «о, кто-то снова нажал удалить у всех». Так что бот остаётся цифровым Форрестом Гампом: он знает, что что-то произошло, но понятия не имеет, что именно. 😄

Под капотом: возможности и ограничения Telegram Business API

Бот работает исключительно через официальный Telegram Business API. Это не сторонний клиент и не "серая" схема.

Однако важно понимать и его ограничения, чтобы не было ложных ожиданий:

1. Бот не видит историю. Он начинает работать только с момента подключения и не имеет доступа к сообщениям, отправленным ранее.

2. Бот работает только в личных чатах. Технология Telegram Business API на данный момент не позволяет отслеживать события в групповых чатах.

Что дальше?

Проект продолжает развиваться. Сейчас я собираю обратную связь, чтобы понять, какие еще функции могут быть полезны пользователям. Буду рад, если вы поделитесь в комментариях своими идеями или кейсами, где такой инструмент мог бы пригодиться.

Ссылка на бота: @dialog_guard_bot

Спустя время мы конечно закрыли проект со всеми расчетами, применили изменения. Но только вдумайтесь, целый департамент на протяжении пары месяцев считает рентабельность изменения целой инфраструктуры и влияние на него всего лишь закрытием 1-2 объектами. Это колоссальные затраты для компании.

Со временем я перешел в IT, сменил свою сферу деятельности, в свободное время изучал различные языки программирования, фреймворки и понял "А что если разработать аналог для логистической инфраструктуры. Да, конечно дизайн будет не броский, но нам важна лишь функциональность и работоспособность данной программы". Соответственно в начале 25г мною было принято решение начать разработку. Как раз время AI инструментов, не идеальные, но какие-то нюансы они могут подтянуть что бы не лезть в тех доку на изучение той или иной функции/метода/условия.

Язык: Python.

Библиотеки для интерфейса: PyQt6.

Хранилище всей информации: SQLite3.

Частично использовалось: HTML, JS.

И множество второстепенных библиотек для кодирования информации, реализации возможности подключения внешних БД, работы с таблицами и т.п.

Python — язык не самый лучший, да и PyQt библиотека своеобразная и довольно хорошо нагружает систему, сама программа начинает весить тоже немало. Но ведь мы не гонимся за «вау-эффектом».

Перед началом создания программы мною были проведены анализы существующих аналогов. Были варианты на европейском рынке, но все не то либо очень дорого. В основном по моим запросам выдавались программы для

«Оптимизации доставок», «1С:Транспорт», «SAP», «Транспортный анализ» и т.п. Но ни одной подходящей под мое описание программы не было.

Что включало в себя мое виденье всей системы:

1. Интерактивная карта с маркерами объектов.

2. Автоматический расчет зонирования регионов в зависимости от исторических данных продаж с доставками.

3. Отображение линий снабжения объекта прям на карте в формате «Объект А -> Объект Б -> Объект С».

4. Планирование маршрута при выборе определенных объектов.

5. Возможность построение интерактивных дашбордов.

6. Возможность создание различных интерактивных виджетов и их настройка.

7. Внутренний аналитический куб.

8. Подключение к внешним БД как к источнику данных и тонкая настройка самим пользователем с маппингом полей.

9. Создание регионов по складам (ручное выделение самого региона на карте).

И прочие функции, по типу DAX-языка при создании вычислительных полей.

Вишенка на торте всей программы:

10. Анализ инфраструктуры автоматически на ядре программы в формате «Что если?».

А что, если мы закроем магазин на Савеловской — как это повлияет на зону доставок ближайших магазинов/складов. А куда перевозить товар? Сколько машин надо и какая утилизация будет? А какие магазины есть в регионе? А что будет с инфраструктурой, если мы закроем целый склад? Кто теперь будет снабжать товаром магазины? А какая матрица товара есть сейчас? Как изменится структура поставок от основного склада на магазин, будем ли мы задействовать транзитные склады?

Первое, что я начал делать — накидывать БД, да, мы не имеем сервера, поэтому нам надо хранить данные для работы программы локально. Почему не сделать под клиента? Ну-у-у... Возможно, потому что у всех своя структура хранения, а аналитики есть везде, написать SQL-запрос и выгрузить данные по шаблону куда проще, чем делать программу с адаптивом. Имея опыт в работе с логистикой и инфраструктурой, я понимал, какая +- система хранения у всех компаний, труда собрать хранение мне не составило.

Вторым моим шагом стало изолирование всех действий с БД в программе. Т.е. все методы программы не должны общаться на прямую с хранением, а ходить через выделенный файл (ресурс).

Третий шаг — создание интерфейса, вкладок, виджетов и т.д. Можно было сделать через WebView, писать отдельно файлы форм, настраивать JS-логику, передавать сигналы в .py-файлы и т.д. Но это слишком усложняет весь проект, расширяя его код. В таком случае один я уже не смог бы вывести. Поэтому выбрал PyQt6. Долго анализировал, как лучше сделать, но ничего умнее не придумал. Так и родился первый интерфейс программы:

Скриншотами выше я показал лишь часть того, что реализовано в программе. В действительности функционал гораздо больше.

Четвертый шаг — создание ядра всего мыслительного процесса, пользователь нажал на кнопку, а что дальше? Дальше как раз таки отдельные компоненты, которые получают запрос и идут по логике дальше, забирают/обновляют/удаляют данные через шаг 2, интерпретируют их и отдают ответы на модули, которые вызывали.

Да, конечно, с ядром программы я возился довольно долго. Ввиду того что это не 1С, а свой, по сути, уникальный продукт, мне на 80% удалось создать полный конструктор ядра. Что это значит? Значит то, что всю дальнейшую логику мне надо лишь описывать в исполняемых файлах core. Это дало прирост к написанию более качественного кода, более чистого. Да, репозиторий программы увеличился с 15 mvp файлов до 80. Отдельный исполняемый файл практически на каждую форму и отдельно логический файл. Зато мы сразу имеем максимально декомпозированную структуру, которую легко править и изменять процессы.

Далее было много различных шагов, криптография подключения к БД, логирование действий для отслеживания ошибок программы, перевод карты на формат HTML+JS. Получение API ключей и т.д.

В последний момент я задался вопросом: «Как распространять обновления программы? Ведь если я внесу новые правки — пользователь должен их получить. Также я должен делать логирование для использования программы».

Долго я думал над тем, как сделать это все на бесплатном формате. Получилось сделать обновление через Яндекс Диск, авторизацию выделено и рассылку информации о грядущих обновлениях пользователям.

Интерфейс для лаунчера я накидал быстро с помощью нейронки, вручную написал код для авторизации на js с py. Настроил всё и протестировал. И «О чудо!» не имея большого бюджета у меня получилось реализовать это всё, над безопасностью авторизации еще, безусловно, стоит потрудиться.

Через некоторое время написал тест кейсы, написал алгоритм для тестирования всех модулей, поправил баги, которые вызывали сбои. Сейчас готова версия 0.5.8. До релиза v1.0.0 еще далеко, много разделов, которые моя голова хочет реализовать.

Что делать дальше? Когда я только начинал, был уверен, что проект можно продать. Я видел такие кейсы и раньше. Думал, что смогу развивать его сам, возможно, еще на год разработки в свободное время меня хватит, и я не погрязну во всей архитектуре. Но год спустя сомнения все чаще берут верх. Может, я зря трачу время?

Возможно, данным постом я смогу найти тех, кого воодушевит мой проект или просто он кому-то приглянется. А возможно, просто получу дельные советы.

Если у вас есть идея и желание реализовать её самостоятельно, смело действуйте.

В скором времени постараюсь выложить еще пост о новых функциях программы.

Делитесь своими комментариями и мнениями.

Если у вас нету клиента, скачивайте latest версию 1.1.2 -
https://github.com/yamixdev/vk-desktop/releases
Исходный код - https://github.com/yamixdev/vk-desktop
Хотите помочь с разработкой и предложить свои идеи, я открыт!
Также насчёт билда под LINUX, у вас есть исходный код программы, можете себе собрать версию и модифицировать под себя, по желанию!