The post has been translated automatically. Original language: Russian
I would like to tell you my development path. Maybe my story will help a novice startup in creating their own product.
My name is Ayan Nukenov, I am a solo developer and founder of SoloCRM AI, a mobile CRM for the self-employed and microbusiness.
The idea was born from a simple observation: my sister, a pastry chef, kept orders in notes and correspondence, regularly lost something, and ready-made CRM systems for such a scale are either missing or too heavy and expensive. I have already written about this human part separately.
Today I want to show a different side.: how the product works technically and what I, as one developer, really keep in production.
We'll agree on honesty right away, because I'm not a super duper senior with 20 years of experience and the audience here is technical, I think you'll understand everything I write here without any problems. I'm not selling "AI magic." I'll tell you what really works in the system, where it's a trained model and where it's regular statistics, and what decisions could be reconsidered.
Architecture: why there are five services, not a monolith
SoloCRM is not a single project, but five separate services around a common database (and yes, it's better to reconsider having one common database, so if you've just started developing with a microservice architecture, then think about this point. More on this later):
- backSoloCRM is the main API on Node.js and TypeScript (Express). Several workers under PM2. Socket.io plus Redis for realtime updates.
- frontSoloCRM is a mobile application for React Native (Expo), several dozen screens, react-native-iap for iOS and Android subscriptions, Firebase Crashlytics for crashes, Meta SDK for installation and event analytics (I especially want to highlight: do not neglect analytics, it is very necessary and the numbers will give you an honest answer to the effectiveness of the product since you, as the "creator", will fall in love with your project and this can play a "cruel joke" on you - this is my seventh project, I closed six of them and some of them later than they should have been and all because of the love for them).
- solocrm is an ai analysis service in Python (FastAPI). This is SolAI ("solai" is from Kazakh for "like this" and echoes the name of the application itself, and I liked it. So, when you name your project, then start from an inner conviction and from logic :). It works with the database in read-only mode so that heavy calculations do not interfere with the main API.
- solocrm-wa - integration with WhatsApp. Multi-tenancy: one service serves multiple businesses.
- solocrm-tg are grammY Telegram bots, with a branded bot for each business owner.
Everything is deployed on Railway, data in MongoDB Atlas, files in Cloudflare R2.
You might ask why a solo developer needs five services instead of a simple monolith. The main reason is practical: services have different life cycles and different risks.
Tip: if you are making a B2B application, it is important that if something crashes, the main functionality is not affected and the basic functionality is working (this will give you time to fix it).
AI calculations in Python cannot be kept in the same process as the Node API, otherwise a heavy pipeline will slow down the return of realtime data. WhatsApp integration is inherently unstable, and I want it to not drop the entire product. Telegram bots live by their webhook logic. Splitting gives me the opportunity to roll and restart parts independently, and in general it gives flexibility to the project.
On the downside: a common base for everyone is a conscious compromise, which I follow as the load increases. This is not ideal for textbook microservices. But for one developer, complete data isolation at the start would have given more operational pain than benefit. I chose the complexity that I can actually handle alone.
SolAI: its own model, not a wrapper over LLM
The most common question I get asked is "SolAI is GPT under the hood?" No. And this is a conscious decision. I wanted something of my own, though modest by the standards of tech giant products, but my own!
SolAI is a hybrid of two honestly separated parts.
The first part is a trained ML model. This solves the problem of predicting customer churn. This is a classic supervised task based on tabular behavioral data (order history, frequency, dynamics of customer activity), and gradient boosting is used for it. The model is retrained as data accumulates in the product: the longer a business uses the application, the more accurate forecasts for its customer base become.
The second part, statistics and heuristics. These are RFM segmentation (Recency, Frequency, Monetary) and Customer Value Assessment (CLV). I intentionally don't call it a "model". This is transparent mathematics based on business data, and that's exactly why it is understandable: an entrepreneur does not see a black box, but a clear logic of why a particular client got into a particular group.
Why didn't I make a wrapper over the external LLM, even though it's faster this way (well, I mentioned the most important reason above:), but also here:
- The nature of the task. Outflow forecasting and segmentation based on tabular behavioral data is something that gradient boosting and statistics solve more cheaply, faster and more predictably than the language model. LLM here it would be like firing a cannon at sparrows on a wire.
- Cost and latency. It calculates its own model locally, without paying for each request to an external API and without network delays. One of the problems of novice startups is a small budget or no budget at all. (Tip: try to optimize infrastructure costs, use trials/free plans actively at first, and don't worry that it won't be enough because you think "damn, what if the free plan can't handle the number of users" - it will, and if you get to this problem that the number of users is loading some service, then this is not a problem, but happiness :).
- Privacy. I do not upload the user's client data to a third-party service.
- Determinism and control. I understand each layer of the pipeline and can reproduce it, rather than relying on the behavior of someone else's model, which can change without me. Independence and freedom are something that cannot be taken away from us Kazakhs :) in short, I didn't want to depend on this part.
And honestly about the scale: SolAI is modest. There are not millions of data yet, and this is a decision support tool, not an oracle. But it's my own, I understand it through and through and can develop it for the real scenarios of my users, and not customize the task for someone else's API.
Integrations: WhatsApp, Telegram and receipt generation
WhatsApp. This is probably the most fragile integration in the product, and I treat it accordingly. Any automation of working with a messenger is a high-risk area: the rules of the platform may change, and the tools around it are unofficial. Therefore, I keep this part isolated from the core (if it crashes, the main functionality continues to work) and do not build on it what cannot be experienced in case of failure.
If you do something similar, the main advice is not about coverage, but about responsibility. The user's business phone number and his relationship with clients are at stake. The security priority of this number should be higher than the desire to send out more messages. You are a startup, your task is to bring benefits to the user, not a headache. Any mechanics here should be designed as carefully and conservatively as possible in relation to the user's account.
Telegram on grammY. It's quieter here, as I've read on various TV channels that it's working stably. The logic is based on webhooks, each business owner has his own branded bot, and requests from customers are automatically logged into the system through the main API.
Generating invoices as images. A small but pleasant engineering detail. The invoice is rendered in PNG without a headless browser: the markup is converted to SVG via Satori, then SVG to PNG via resvg-js, and the finished image goes to Cloudflare R2. It turns out to be easy, fast and most importantly free in theory.
The Reality of solo development
Keeping five services to one is primarily a complexity management discipline. I rely on deployment automation (Railway), process management (PM2), crash collection (Crashlytics), and modern AI tools in development itself, without which solo pace would be impossible.
About honest rakes. One of the most annoying classes of problems I have is related to native binaries: a library that depends on a native module built for a specific platform can quietly break after being re-installed in the cloud, and the media function stops working without a single error in the code. Such things are not described in the tutorials, and they are the ones that take up the most time. This is the real price of "magic": not to write a feature, but to make it live stably in production.
Tip: neural networks (I use Claude Code on Sonnet 4.6 inside VS Code for development, Opus 4.8 for planning, Gemini 3 Flash for cross-planning). Architecture planning is an important part. Without a good architecture, your project is likely to give you surprises over time! Consider this.
Another tip: vibe coding is vibe coding, but I recommend learning the programming base! You better be able to understand (at least more or less) what LLM offers you!
Some results
class="paragraph"> Now SoloCRM AI has its first paying users and an organic influx (the first traffic to me came from a pastry chef's chat on WhatsApp, through a sundress and from Threads - horror published about 40 branches here, but I still did not understand the principle of their algorithms).
Advice and supervision
The most basic problem for startups is not development skills, perseverance, and getting them to work, but distribution! Promote your product!
My mistake was that I sat and worked on development 80% of the time, and devoted the rest to marketing.
Do not repeat this mistake, because you are a startup and time is important to you and it is often not on your side!
I hope this article will help at least one of you on the difficult startup path.
Good luck and good luck!
Хотелось бы рассказать свой путь разработки. Быть может, мой рассказ поможет начинающему стартаперу в создании своего продукта.
Меня зовут Аян Нукенов, я соло-разработчик. В одиночку делаю и держу в продакшене мобильное приложение для учёта заказов, клиентов и финансов небольшого бизнеса.
Идея родилась из простого наблюдения: моя сестра-кондитер вела заказы в заметках и переписках и регулярно что-то теряла. Про эту человеческую часть, как я вообще пришёл к продукту, я уже писал отдельно.
Сегодня хочу показать другую сторону: как продукт устроен технически и что я, как один разработчик, реально держу в продакшене.
Сразу договоримся про честность, потому что я не супер пупер сеньор с 20-летним стажем, а аудитория здесь техническая, думаю вы без проблем поймёте всё, что тут напишу. Я не продаю «магию ИИ». Я расскажу, что в системе действительно работает, где это обученная модель, а где обычная статистика, и какие решения можно было бы пересмотреть.
Архитектура: почему пять сервисов, а не монолит
Проект это не один кусок кода, а пять отдельных сервисов вокруг общей базы данных (и да, тут лучше пересмотреть наличие одной общей базы, поэтому если вы только только приступили к разработке с микросервисной архитектурой, то продумайте этот момент. Об этом далее будет):
- backSoloCRM - основной API на Node.js и TypeScript (Express). Несколько воркеров под PM2, Socket.io плюс Redis для realtime-обновлений.
- frontSoloCRM - мобильное приложение на React Native (Expo), несколько десятков экранов, react-native-iap для подписок на iOS и Android, Firebase Crashlytics для крашей, Meta SDK для аналитики установок и событий (особо хочу выделить: не пренебрегайте аналитикой, она очень нужна, и цифры дадут вам честный ответ на результативность продукта, ведь вы как «создатель» влюбитесь в свой проект, и это может сыграть с вами в «злую шутку». Это мой седьмой проект, шесть закрыл, и некоторые из них позднее, чем следовало, и всё из-за любви к ним).
- solocrm-ai - аналитический сервис на Python (FastAPI). Это и есть SolAI («солай» с казахского «вот так», и перекликается с названием самого приложения, и мне это понравилось. Так что, когда будете называть свой проект, отталкивайтесь от внутреннего убеждения, ну и от логики:). Работает с базой в режиме только на чтение, чтобы тяжёлые расчёты не мешали основному API.
- solocrm-wa - интеграция с WhatsApp. Мультиарендная: один сервис обслуживает множество бизнесов.
- solocrm-tg - Telegram-боты на grammY, по брендированному боту под каждого владельца бизнеса.
Всё развёрнуто на Railway, данные в MongoDB Atlas, файлы в Cloudflare R2.
Вы, наверное, спросите, зачем соло-разрабу пять сервисов вместо простого монолита? Главная причина практическая: у сервисов разные жизненные циклы и разные риски.
Совет: если делаете приложение для B2B, то важно, чтобы при падении чего-то одного основной функционал не пострадал и работал (это даст вам время на починку).
AI-расчёты на Python нельзя держать в одном процессе с Node-API, иначе тяжёлый пайплайн будет тормозить отдачу realtime-данных. WhatsApp-интеграция нестабильна по своей природе, и я хочу, чтобы её падение не роняло продукт целиком. Telegram-боты живут своей логикой вебхуков. Разделение даёт мне возможность катить и перезапускать части независимо, да и в целом это придаёт гибкости проекту.
Про обратную сторону: общая база на всех это сознательный компромисс, за которым я слежу по мере роста нагрузки. Для микросервисов «по учебнику» это не идеал. Но для одного разработчика полная изоляция данных на старте дала бы больше операционной боли, чем пользы. Я выбрал ту сложность, которую реально могу обслуживать в одиночку.
Своя модель, а не обёртка над LLM
Самый частый вопрос, который мне задают: «SolAI это GPT под капотом?». Нет. И это сознательное решение. Я хотел что-то своё, хоть и скромное по меркам продуктов техногигантов, но своё!
SolAI это гибрид из двух честно разделённых частей.
Первая часть, обученная ML-модель. Здесь решается задача прогноза оттока клиентов. Это классическая supervised-задача на табличных поведенческих данных (история заказов, частота, динамика активности клиента), и под неё используется градиентный бустинг. Модель переобучается по мере накопления данных: чем дольше бизнес пользуется приложением, тем точнее становятся прогнозы по его клиентской базе.
Вторая часть, статистика и эвристики. Это RFM-сегментация (Recency, Frequency, Monetary) и оценка ценности клиента (CLV). Я намеренно не называю это «моделью». Это прозрачная математика на данных бизнеса, и она ровно поэтому объяснима: предприниматель видит не чёрный ящик, а понятную логику, почему конкретный клиент попал в ту или иную группу.
Почему я не сделал обёртку над внешним LLM, хотя так быстрее (ну, самую главную причину я назвал выше:), но ещё вот:
- Природа задачи. Прогноз оттока и сегментация по табличным поведенческим данным это то, что градиентный бустинг и статистика решают дешевле, быстрее и предсказуемее, чем языковая модель. LLM здесь был бы как из пушки по воробьям на проводах.
- Стоимость и латентность. Своя модель считает локально, без оплаты за каждый запрос к внешнему API и без сетевых задержек. Как раз одна из проблем начинающих стартаперов это маленький бюджет либо вовсе его отсутствие. (Совет: старайтесь оптимизировать расходы на инфраструктуру, пользуйтесь поначалу активно триалами и бесплатными планами, и не переживайте, что этого не хватит, от мысли «блин, а вдруг бесплатный план не выдержит количества пользователей». Выдержит. А если дойдёте до проблемы, что количество пользователей нагружает какой-то сервис, то это не проблема, а счастье:).
- Приватность. Я не выгружаю клиентские данные пользователей в сторонний сервис.
- Детерминизм и контроль. Я понимаю каждый слой пайплайна и могу его воспроизвести, а не полагаюсь на поведение чужой модели, которое может измениться без меня. Независимость и свобода это то, что у нас, казахов, не отнять:) короче, не захотел я зависеть в этой части.
И честно про масштаб: SolAI скромная. Данных пока не миллионы, и это инструмент поддержки решений, а не оракул. Но она своя, я понимаю её насквозь и могу развивать под реальные сценарии пользователей, а не подгонять задачу под чужой API.
Интеграции: WhatsApp, Telegram и генерация счетов
WhatsApp. Это, пожалуй, самая хрупкая интеграция в продукте, и я отношусь к ней соответственно. Любая автоматизация работы с мессенджером это зона повышенного риска: правила платформы могут меняться, а инструменты вокруг неофициальные. Поэтому я держу эту часть изолированной от ядра (если она падает, основной функционал продолжает работать) и не строю на ней то, что нельзя пережить при отказе.
Если будете делать что-то похожее, главный совет не про охват, а про ответственность. У пользователя на кону его рабочий номер телефона и его отношения с клиентами. Приоритет безопасности этого номера должен быть выше, чем желание разослать побольше сообщений. Вы стартап, ваша задача приносить пользователю пользу, а не головную боль. Любую механику здесь стоит проектировать максимально бережно и консервативно по отношению к аккаунту пользователя.
Telegram на grammY. Здесь спокойнее, так как читал в разных ТГ-каналах, что работает стабильно. Логика построена на вебхуках, у каждого владельца бизнеса свой брендированный бот, заявки от клиентов автоматически попадают в систему через основной API.
Генерация счетов на оплату как картинок. Небольшая, но приятная инженерная деталь. Счёт рендерится в PNG без headless-браузера: разметка превращается в SVG через Satori, затем SVG в PNG через resvg-js, и готовое изображение уходит в Cloudflare R2. Получается легко, быстро и, самое главное, бесплатно по идее.
Реальность соло-разработки
Держать пять сервисов одному это в первую очередь дисциплина по управлению сложностью. Я опираюсь на автоматизацию деплоя (Railway), процесс-менеджмент (PM2), сбор крашей (Crashlytics) и современные AI-инструменты в самой разработке, без которых соло-темп был бы невозможен.
Про честные грабли. Один из самых неприятных классов проблем у меня связан с нативными бинарниками: библиотека, которая зависит от собранного под конкретную платформу нативного модуля, может тихо ломаться после передеплоя в облаке, и медиа-функция перестаёт работать без единой ошибки в коде. Такие вещи не описаны в туториалах, и именно они отнимают больше всего времени. Это и есть настоящая цена «магии»: не написать фичу, а заставить её стабильно жить в продакшене.
Совет: нейронки (я использую Claude Code на Sonnet 4.6 внутри VS Code для разработки, Opus 4.8 для планирования, Gemini 3 Flash для перекрёстного планирования). Планирование архитектуры это важная часть, без хорошей архитектуры ваш проект со временем скорее всего выдаст вам сюрпризы! Учтите это.
Ещё совет: вайб-кодинг вайб-кодингом, но базу программирования рекомендую изучить! Вам лучше уметь разбираться (хоть более менее) в том, что предлагает вам LLMка!
Про дистрибуцию, и это, наверное, главное
Первый реальный трафик пришёл ко мне не из платной рекламы, а органически: из чата кондитеров в WhatsApp, по сарафану, и немного из Threads (опубликовал там около 40 веток и, честно, так и не понял принцип их алгоритмов).
Самая основная проблема стартаперов это не навыки разработки, усидчивость или доведение до прода, а дистрибуция! Продвигайте свой продукт!
Моя ошибка была в том, что я сидел и занимался разработкой 80% времени, а маркетингу уделял оставшееся.
Не повторяйте этой ошибки, ведь вы стартап, и для вас время важно, а оно зачастую не на вашей стороне!
Надеюсь, хоть одному из вас эта статья поможет на нелёгком стартаперском пути.
Успехов и удачи!
Share
