What it is: Software for tracking customers and deals — who reached out, what stage the deal is at, who should call and when. A replacement for the Excel sheet that sooner or later falls apart.
How we use it: We connect bots and automation to it through its API — requests from the website and Telegram land in the CRM straight away, no manual copying.
What it is: "Software as a service" — a product you use by subscription in the browser, with no installation and no server of your own (Zapier, Notion, most CRMs).
How we use it: We often offer a self-hosted alternative to a SaaS product when a client wants to stop depending on someone else's platform and pricing.
What it is: An automatic notification one service sends to another when something happens — "payment received" or "new order" — instead of asking "anything new?" every minute.
How we apply it: The backbone of most of our n8n automations: a marketplace order triggers the chain of actions immediately rather than waiting for someone to start it by hand.
What it is: Production is the live version of a service that real people use (as opposed to a test one). Deploying is the process of shipping a new version of the code to the server.
How we use it: We deploy through CI/CD — automatically, with no manual file copying and no risk of shipping the wrong version.
What it is: Hosting is the server where your website physically lives. A domain is its address on the internet (for example, devunit-lab.ru), registered separately and renewed every year.
How we use it: We help choose both for the task at hand and move websites between hosts with no downtime and no lost search rankings.
What it is: The "phone book" of the internet — it turns a readable site name (devunit-lab.ru) into the numeric server address the request actually goes to.
How we use it: We configure DNS records when moving a site or setting up email on a domain — without it, the right address simply leads nowhere.
What it is: A written commitment on response and recovery times — for example, "we answer within an hour and fix within a day". It protects both sides from vague expectations.
How we apply it: We write it into the support contract after handover — specific deadlines, not "as soon as we can".
What it is: Customer lifetime value — how much money a customer brings the company on average over the whole relationship, not from a single purchase.
How we apply it: A metric we grow with loyalty programmes and automatic customer win-back — keeping an existing customer is cheaper than acquiring a new one.
What it is: A document stating exactly what we build, what the client receives and how to check it is done. Without it the "I thought that was included" argument is inevitable.
How we use it: We write the specification after a free audit and set timelines once it is approved. The same document becomes the project README on delivery.
What it is: A letter with the scope, price and timeline for a specific task. Prices on our site are starting prices; the exact figure comes in the proposal after the audit.
How we use it: The proposal is free. No hourly billing: the price is fixed for the result, and payment is usually by stage.
What it is: The minimum working version of a product: only what is impossible to launch without. It tests the idea on real customers in weeks rather than months and grows from their feedback.
How we use it: The studio's own products started as MVPs: the VPN service with a bot, the player, the laser tag system. We suggest the same to clients: launch small, measure, extend.
What it is: A monthly fee for keeping a site, bot or server running: updates, backups, monitoring, small fixes. Cheaper than repairing after a failure.
How we use it: The first month after delivery is free, then from $100 a month. This is what makes keeping everything on your own server possible without hiring a sysadmin.
What it is: A system that stores every version of the code and lets you roll back to any of them. A repository is a project folder under its control, usually on GitHub, private.
How we use it: Every studio project is a private repository with a README written as a specification and a CHANGELOG. On delivery we hand access to the client: the code is theirs.
What it is: In plain words — your own private cloud server where you are the only owner, rather than a third-party service like Zapier or Make. Nobody can restrict your access, raise the price retroactively or shut the service down one morning.
How we use it: We deploy your automation, bots and internal services on it. The downside: full control means full responsibility — the server needs maintenance, updates and monitoring. Usually we take care of that 🙂
What it is: The way one program asks another for data or actions — for example, your website asks Telegram to send a message, or a marketplace for order data.
How we use it: If a service (CRM, warehouse, marketplace, bank) has an API, we plug it into your automation directly — no manual work and no copying data by hand.
What it is: A program inside Telegram or VK that can answer customers, take requests, notify about orders or keep records — with no human involved, 24/7.
How we apply it: We build bots on the official Telegram Bot API and the VK community API, with inline buttons and command menus instead of bulky keyboards. We connect them to your CRM, warehouse or payments. Prices are on the “Bots” service page.
What it is: A website is a page or a set of pages on the internet that tell people about your business, take requests or sell goods. Unlike a social media account or a marketplace listing, a website is fully yours: the address, the design and the data belong to you, not the platform.
How we use it: We build websites end to end — from a simple one-page landing with a single goal (a request, a sale, a booking) to an online store with its own admin panel. Unlike site builders (Tilda, Wix and the like), there is no monthly platform rent, no third-party limits, and any automation can be built in — a chat bot, request intake or a warehouse integration.
What it is: One of the most widespread programming languages — used for simple scripts and large backends alike (the server side: the part users don't see directly, but which handles data and logic).
How we use it: Our main language for bots and backends. FastAPI is a fast, modern framework (a ready-made toolkit so nothing is written from scratch) for APIs; Django is the "heavier" option for complex admin panels and business logic.
What it is: A compiled programming language from Google — as fast as C++, but noticeably simpler to develop in, with excellent built-in support for parallel work.
How we apply it: For services where performance under load matters — for example, media servers streaming video to many viewers at once.
What it is: A low-level programming language with direct hardware access — maximum performance at the cost of more complex development.
How we use it: Firmware for microcontrollers (ESP32) and calculations where microseconds count. We keep behaviour identical to the Python version through a shared protocol and automatic cross-checks in CI.
What it is: Programmatic access to Google's neural networks (the Gemini model family) — your code can "ask" the AI something and get an answer automatically.
How we use it: The AI assistant in the chat on this website runs on it — it answers visitors' questions and gathers the basics about their task before a call with you.
What it is: SQLAlchemy is the library a Python program uses to work with a database without hand-writing SQL for every step. Alembic is its companion for migrations: it changes the table structure step by step without losing the data already collected.
How we use it: The IT help desk bot has 20 tables and 16 Alembic migrations, and the online store applies its migrations automatically when the API starts. Taking a ticket locks the row in the database, so two administrators cannot take the same one.
What it is: A Python library for network calls that do not block: a bot talks to other services' APIs and keeps answering people at the same time. It works both as a client and as a small web server.
How we use it: The subscription-sales bot calls the Marzban panel API with it, the «Дыхание Поволжья» community bot reads the catalogue from the website, and the UNLOCK card service serves card settings and receives the recipients' replies.
What it is: A scheduler inside a Python program: it runs actions at the right time — a reminder at 9 a.m., a check every minute, a report on the 1st. Unlike cron, it lives inside the bot and sees its data.
How we use it: It sends birthday and subscription-expiry reminders, escalations and the monthly report in the help desk, and marks no-shows in the electronic queue. The time zone is always set explicitly to Europe/Moscow.
What it is: Asynchronous access to an SQLite database from Python: a query to the database file does not stall the bot while it answers other people.
How we use it: In the birthday bot, the gaming-club loyalty card and the voice transcription bot the whole database is one SQLite file, and aiosqlite reads and writes it without holding up message handling. A backup is a copy of the file.
What it is: Python libraries for PDF. pdfplumber carefully extracts text and tables; PyMuPDF can also change a page: erase and draw blocks without touching the rest.
How we use it: pdfplumber reads the PDF statements of four banks in the finance assistant. PyMuPDF stamps an accident commissioner's contacts onto an electronic car insurance policy: the form number, the data and the QR code stay untouched, and the file grows from 380 to 520 KB rather than to 6.5 MB.
What it is: Python libraries that build real .docx and .xlsx files with formatting, tables and sheets. People open them in the Word or Excel they know and never notice that a program made the file.
How we use it: python-docx builds documents for signature from Markdown in the accepted layout (A4, Times New Roman 12) — that is how the network survey set for a museum complex is produced. openpyxl exports the electronic queue to Excel for the lecturer and the finance assistant's operations to XLSX.
What it is: A Python library for images: open, rotate, shrink, save in another format, draw on top.
How we use it: In the gaming-club loyalty card it works with qrcode to draw the client's personal QR code, which the administrator scans to credit a visit.
What it is: Python libraries that turn a link or text into a QR code. A phone scans it with the camera and opens the right thing at once: a bot, a client profile, a page.
How we use it: qrcode produces the QR card of a gaming-club client: the code opens the bot with the client's number, and for anyone else the link gives nothing. segno draws the QR code on the accident commissioner's card on an insurance policy.
What it is: A Python library for calculations over large arrays of numbers: what ordinary code would take minutes to compute, numpy does in a fraction of a second.
How we use it: In ToshaMusic numpy breaks a fragment of a track down by frequency (FFT) and finds the spectral cut-off. That is how the bot catches a FLAC rebuilt from an MP3 and a CD master stretched to 24-bit / 192 kHz.
What it is: CMake builds a C++ program with one command on Linux, macOS and Windows, and CTest runs its tests. For the client this means the code builds on more than the developer's machine and the formulas are checked.
How we use it: The FEFCO box die-line library for a packaging manufacturer is built with CMake and plugs into production software as an ordinary library. Tests for the formulas, nesting and input validation run through CTest.
What it is: The most common way to build an API: every entity has its own address, and actions are ordinary HTTP requests to get, create or change it. The answer usually comes in JSON.
How we use it: The online store's REST API is written in FastAPI: catalogue, orders, site settings. The Tech Poly VPN bot drives the Marzban panel through its REST API and keeps money, terms and discounts itself.
What it is: A persistent connection between a browser or app and a server over which data flows both ways without new requests. Chats, live updates and some VPN tunnels need it.
How we use it: On the VPN route, the entry node in Russia proxies the VLESS WebSocket tunnel; a path without the Upgrade header answers 404, like a page that does not exist. A WS+TLS entry point is what the Windows 7 client uses.
What it is: A text data format almost every program understands: services pass orders and statuses to each other in it, and settings and exports live in files a person can read.
How we use it: n8n workflows are exported as JSON files and kept in git, the subscription-sales bot makes its backup as a JSON dump, and the help desk PC program writes a computer's passport into a JSON report.
What it is: A rule of "no more than N requests per period". It protects a site or bot from password guessing and spam, and an integration from being banned by someone else's service for calling it too often.
How we use it: After the move from Joomla, the WordPress login page accepts at most 20 requests a minute, the brief on the studio site at most three submissions per 10 minutes from one address, and the electronic queue one request per 0.5 seconds. ToshaMusic caps parallel downloads so the streaming account does not get banned.
What it is: A property of an operation: running it again does not change the result. Confirm pressed twice, a repeated webhook, the same file uploaded again — no duplicate appears.
How we use it: In Tech Poly VPN a payment is confirmed under a row lock in the database: the second administrator sees who already processed the request, and the subscription is not extended twice. The Joomla import can be re-run without duplicates, and uploading the same statement to the finance assistant again changes nothing.
What it is: The server edition of Windows from Microsoft. Office infrastructure usually lives on it: employee accounts (Active Directory), accounting systems, shared folders and remote desktops (RDP).
How we apply it: We set it up and maintain it when a business already runs on Windows: access rights, backups, secure remote login through VPN instead of RDP exposed to the internet.
What it is: A web server and reverse proxy — the part that accepts incoming requests and decides which service handles them.
How we use it: As the entry point of almost every project: it serves static files, proxies requests to the right containers and checks access before a request goes any further.
What it is: A "box" for a program. Any program needs an environment to run: the right library versions, settings, helper files. Docker packs the program and that whole environment into one box — a container. The box can be moved to any server and will work there exactly as it did with us: nothing needs reinstalling or reconfiguring by hand. Much like a shipping container: any port crane can lift it, no matter what's inside.
Why it matters for business: Moving to another server takes hours, not weeks; one program can't break another on the same server; if something crashes, the container restarts itself. In almost every project the bot, the database and the website live in separate containers. Compose is the "manifest" of all a project's boxes so they start with one command; Swarm spreads them across several servers.
What it is: A system that looks after Docker containers on its own: restarts crashed ones, balances load, scales with traffic.
How we use it: For projects where load spikes or downtime is critical. K3s is a lightweight version for small servers; Helm is a way to roll out ready-made configurations quickly.
What it is: A mail server on your own VPS: addresses like name@your-domain with no monthly fee per mailbox. DKIM, SPF and DMARC are DNS records without which mail lands in spam.
How we use it: We install Postfix and Dovecot or Mailcow in containers, set up the records and check deliverability to Gmail and Outlook. Important mail can be forwarded to Telegram.
What it is: A file describing which containers make up a project (site, database, bot) and how they connect. One command brings everything up, identically on any server.
How we use it: Every studio project is a folder with docker-compose.yml and .env on the server. Moving to another server means copying the folder and running one command.
What it is: A replacement for Discord or Zoom on your own server: voice rooms, chats, screen streaming. Keeps working when public services are blocked, and data never leaves for a third-party cloud.
How we use it: Our own "Peregovorka": voice over WebRTC, chats and streaming with a custom client. We also deploy ready solutions: Mumble, Matrix, Jitsi, depending on the task.
What it is: The server's built-in alarm clock: run a backup at night, check slots every five minutes, clean old files weekly. Works with no human involved.
How we use it: Database and site backups, monitoring, bot broadcasts. Container time is always set to the client's timezone so "3 a.m." means 3 a.m. locally.
What it is: A web interface for mail: messages on your own domain are read in a browser, like a familiar mail service, with nothing to install.
How we use it: It runs next to docker-mailserver on the studio's web server. Mail can be read in Roundcube or in any mail client, and new messages also arrive in a service Telegram chat.
What it is: The world's most popular content management system (CMS) — lets you edit content without a developer, through an admin panel in the browser.
How we use it: We build showcases and sites with a familiar admin panel on it, but with a custom theme and no third-party plugins or builders: fewer updates and vulnerabilities, light pages. The “Dykhanie Povolzhya” showcase is built this way. We also migrate and maintain existing sites: three sites moved from the outdated Joomla 3.10 to WordPress, keeping the catalogue, forms and search rankings.
What it is: The basic technologies of any web page: HTML is the structure, CSS the styling, JavaScript the interactivity.
How we apply it: For landing pages and small business sites without a CMS — when load speed matters most and there is no need for an admin panel to edit content regularly.
What it is: A toolkit for building fast websites: pages are served as ready HTML, so they open instantly and are fully readable by search engines. Vue is the interface language inside it.
How we use it: The studio site and an online store with an admin panel are built on Nuxt. Content lives in files in git or in a database, the design is custom, with no builder templates.
What it is: Two ways of serving pages. SSR: the server builds the page on every request, handy for stores with live stock. Static: pages are built in advance and stored as files, the server has almost nothing to do and nothing to hack.
How we use it: The studio's Russian site runs as SSR in one container; the international one is built to static files on a server in Moldova. One project, two build modes.
What it is: Your own slice of a data-centre server with full access: install what you like, pay a fixed monthly fee (from $5–15). Unlike "website hosting" it can hold a site, a bot, a database and mail at once.
How we use it: All studio projects live on VPS: sites, bots, n8n, VPN nodes. One properly configured server comfortably runs several sites in containers.
What it is: The domain is the site address (devunit-lab.business). DNS records say which server it points to, where to receive mail and who may send mail on its behalf. The domain is always registered to the client, never to the contractor.
How we use it: We check the domain is owned by the client and set up A, MX, SPF, DKIM, DMARC records and the verification records for search-engine dashboards.
What it is: The padlock in the address bar. It encrypts what a visitor types on the site and confirms the site is genuine. Without it browsers say "not secure" and search engines rank lower.
How we use it: Let's Encrypt certificates are issued and renewed automatically on the edge nginx; nobody has to remember them.
What it is: A service where a site is assembled from ready blocks and lives on the service's servers for a monthly fee (Wix, Squarespace, Tilda and the like). Quick to start, but the site cannot be taken away and features are capped by the plan.
How we use it: We do not use them. We build sites on the client's own server: code and data belong to the client, and the only fee is the VPS. Why — in the article "Your own server or a website builder".
What it is: A system through which the owner changes texts, prices and products without a developer. WordPress is the best-known ready CMS; a custom admin panel is written separately and does exactly what is needed.
How we use it: For showcases we install WordPress with a custom theme; for stores with stock we write a FastAPI panel: prices and availability are edited in one table, orders arrive in Telegram.
What it is: A worldwide network of servers that serves site images and files from the point nearest the visitor. Needed when visitors are spread across countries or traffic is high; a small site usually does fine with one server.
How we use it: We connect one when needed for international sites; for Russian sites a server in Russia and light pages matter more.
What it is: The language WordPress and most of its themes and plugins are written in. Not the trendiest, but every host and every web developer understands it.
How we use it: We write custom WordPress themes in PHP without third-party builders: pages stay light, with fewer updates and vulnerabilities.
What it is: A simple way to mark up text: a hash for a heading, asterisks for bold, a dash for a list. The file is readable without any software, and the site turns it into a page.
How we use it: Pages, case studies and articles of the studio site live in markdown files in git: editing the site means editing a text file. From the same files we build documentation in Word.
What it is: JavaScript with strict types: errors show up at build time, not in a visitor's browser. The standard for Nuxt and Vue sites.
How we use it: The studio site and the online store are written in it: types check that a product or case card is filled in correctly before the deploy.
What it is: An area of a web page where a script draws graphics itself: animations, charts, 3D scenes. It needs no external libraries, but has to be done carefully so a phone is not overloaded.
How we use it: On Valery Afanasiev's business-card site a 3D scanner is drawn on canvas 2D: up to 560 points per part, at most 30 frames per second, drawing only while it is visible, and a single static frame in data-saver mode.
What it is: A site header that tells the browser where fonts, scripts and images may be loaded from. The browser blocks everything else: foreign code cannot be slipped into the page, and the page does not call other people's servers.
How we use it: On the demo stand for a museum complex website the default-src 'self' policy forbids every external address: fonts, images and the map snapshot are on our own server, and the number of external loads can be checked right in the viewer's browser.
What it is: How a site works in several languages: each version has its own URL, the language is detected from the browser, and search engines understand that it is one page in different languages, not duplicates.
How we use it: The studio site on Nuxt: Russian with no prefix, English at /en. The @nuxtjs/i18n module detects the language on the first visit and remembers the choice in a cookie, every page has hreflang, and the English texts live in a separate folder with the same file names.
What it is: A small record a site leaves in the browser: remember the language, keep you signed in, count visits. Analytics counters on our sites switch on only after the visitor agrees, hence the cookie notice.
How we use it: On the studio site a cookie stores the chosen language, the online store's admin panel has its own session cookie on a separate subdomain, and on the «Дыхание Поволжья» site analytics loads only after consent. The video downloader bot uses a cookies.txt file for restricted YouTube videos.
What it is: An automation builder: it connects services to each other (CRM, spreadsheets, messengers, warehouse) without writing code from scratch for every link.
How we use it: We deploy it self-hosted — on your server, not in someone else's cloud — and build chains like "website request → Telegram notification → spreadsheet row" on it.
What it is: A secure private "tunnel" over the internet: it connects your devices and servers as if they were on one local network, even when they are physically in different cities.
How we apply it: We build private VPN networks for secure access to work services and for bypassing blocks — with no public exposure of your infrastructure to the internet.
What it is: A ready-made layer on top of WireGuard that removes manual key and route management — all devices find each other in a single mesh network.
How we use it: When many devices need connecting quickly without a dedicated VPN administrator — the team just installs the app and connects.
What it is: A protocol and tool for bypassing internet blocks — it disguises VPN traffic as ordinary encrypted web traffic (HTTPS), so it is much harder to block by its "fingerprint".
How we use it: For clients for whom a regular VPN is no longer enough — we build an "entry node in Russia → exit node in the EU" scheme with a permanent tunnel and route health monitoring.
What it is: A tool for forwarding ports through an intermediate server — it lets you reach a device behind NAT or a home router without opening dangerous "holes" to the internet directly.
How we apply it: For a permanent tunnel between a node in Russia and a standalone server abroad — traffic exits through a trusted point instead of being exposed on every node separately.
What it is: A VPN mode where only part of the traffic goes through the secure channel and the rest goes direct. Games and local sites stay fast, blocked services open.
How we use it: In the OshaVPN client local sites, games and anti-cheat go direct, everything else through the VPN. For gaming cafés we set up a private VPN with the same rules on every machine.
What it is: A modern way to disguise a VPN connection as ordinary HTTPS traffic to a well-known site, so it cannot be told apart and blocked. A protocol of the Xray core.
How we use it: On the studio's VPN routes the entry node accepts VLESS with Reality or WebSocket+TLS and the exit node is abroad. The client picks a live entry point itself.
What it is: The second engine of a VPN client, an alternative to Xray: the same protocols, a different implementation. Two engines let the client switch when one has problems.
How we use it: In OshaVPN both engines are connected through a thin layer, so an engine can be swapped without rewriting the app. On Windows 7 only sing-box works.
What it is: Programmatic access to a seller account: stock, prices, orders, delivery slots. Through it a bot or workflow does what a manager would do by hand in the dashboard.
How we use it: Wildberries delivery-slot monitoring with Telegram alerts, stock and price sync, order import. Runs around the clock on the client's server.
What it is: The two most widespread CRMs in Russia. Both have APIs and webhooks, so leads from a site or a bot land in them without manual copying, and a deal status change can trigger notifications.
How we use it: An n8n workflow takes a lead from a bot, creates a deal in the CRM and appends a row to Google Sheets; on a status change the CRM itself messages the manager in Telegram.
What it is: Control panels for a VPN service: users, subscriptions, traffic limits, entry nodes. The client gets one subscription link, and the panel serves it the current settings.
How we use it: Our VPN services run on them: the sales bot creates a user in the panel, and the OshaVPN client reads the subscription and picks a live entry point itself.
What it is: The most widespread accounting system in Russia: bookkeeping, warehouse, sales, payroll. Stock and orders usually live in it, so integrations often start there.
How we use it: In automation projects we connect 1C with marketplaces and a CRM in one chain: stock, orders, prices. In the IT help desk, the PC program also lists the 1C databases on every computer.
What it is: A free encrypted route to the internet through the Cloudflare network. For a server it is a way to send part of the traffic so the hosting provider sees only a connection to Cloudflare.
How we use it: On the VPN node in the Netherlands, torrents and 44 AI-service domains exit through WARP: the hosting provider sees only an encrypted connection to Cloudflare, while ordinary web traffic goes direct, with no captchas.
What it is: The European catalogue of standard corrugated-board box designs: each has its own code — 0201, 0203 and so on. A shared language between the packaging customer, the technologist and the program.
How we use it: For a cardboard packaging manufacturer we built a die-line library for styles 0200, 0201 and 0203 with blank nesting on a sheet, and restored a catalogue of 325 FEFCO designs with drawings, search and a filter on its website.
What it is: An online spreadsheet people work on together with nothing to install. In a small business it is often the main record, so automation writes there instead of forcing everyone into a CRM.
How we use it: In lead automation, n8n appends every lead from the Telegram bot as a row in the sheet alongside Bitrix24. The sheet remains a fallback record if the CRM is unavailable.
What it is: A relational database forked from MySQL — fully compatible, but more open and actively developed.
How we apply it: In projects with billing and financial records — where transactional integrity matters: a double charge must be impossible even when several admins work at once.
What it is: An inexpensive microcontroller with Wi-Fi and Bluetooth on board — the basis for smart devices, sensors and other "smart" electronics.
How we use it: Firmware for a client's specific task — for example, a device that counts hits in a game system by itself and keeps working even when the server connection drops.
What it is: A lightweight messaging protocol for devices with limited resources — designed for IoT, where low load on the communication channel matters.
How we apply it: For communication between devices and a central server in embedded projects — devices publish events, the server receives and processes them.
What it is: Video transport protocols: SRT delivers a stream to the server reliably over an unstable link; HLS and WHEP let viewers watch in the browser with low latency.
How we use it: We build our own streaming servers — a replacement for solutions that drop the broadcast on a poor link or let anyone in to watch.
What it is: An open-source software PBX (telephone exchange) — it turns an internet connection into full telephony: calls, queues, forwarding, call recording, with no landline.
How we apply it: For a company's internal communications and customer lines — with custom call-handling scenarios instead of the rigid settings of boxed PBX systems.
What it is: Download engines: yt-dlp fetches video and audio from hundreds of sites (YouTube, TikTok, VK Video), and streamrip fetches music from Qobuz, Deezer and Tidal. A bot hands them a link and gets a file back.
How we use it: The video downloader bot runs on yt-dlp: 12 platforms, quality up to 4K, and Vimeo and Coub were added with no platform-specific code. In ToshaMusic, streamrip downloads Hi-Res with a cap on parallel downloads, so the streaming account does not get banned.
What it is: A Python library for reading and writing audio tags: artist, album, cover art and, for FLAC, the real bit depth.
How we use it: In ToshaMusic it refines the FLAC bit depth when ffprobe reports the container's 32 bits instead of the real 24. The file name and tags are built from measured parameters only.
What it is: A streaming server: it receives the stream from the streamer's PC and hands it to viewers in different forms — to a browser, to VLC, with under a second of latency or in a way that survives a mobile network.
How we use it: In Peregovorka, MediaMTX takes the stream in over SRT and delivers it over HLS, WHEP and RTSP. The server does not re-encode video: the streamer's graphics card encodes both qualities, so a powerful machine is not needed.
What it is: A relay for browser calls: when two participants cannot connect directly because of a router or the network, the audio goes through a TURN server. It cannot decrypt the conversation.
How we use it: Peregovorka runs its own coturn next to the WebRTC voice: credentials are temporary and live for an hour, and the secret never leaves the server.
What it is: A regular automatic check that a service is alive and answering: not just that the process runs, but that the database reads and the page opens. It is what restarts a container and alerts the administrator.
How we use it: In Peregovorka the chat answers /healthz by reading from and writing to the database, and a watchdog restarts a stuck container at most three times an hour. The finance assistant is checked from outside every 5 minutes: containers, database, the "bot is alive" mark and the dashboard address.
What it is: Bot tokens, database passwords and API keys are kept apart from the code: in a .env file on the server or inside the service itself. The code can then be shown or handed over without exposing access.
How we use it: Gemini keys and bot tokens are set in .env, and in n8n workflows the keys live in n8n itself, not in the workflow file. Our apps mask subscription links, keys and tokens on the device before a log is sent to the developer.
What it is: A return to the previous working state when a new version or an operation goes wrong: an app update, a deploy, a payment, a database change.
How we use it: The OshaVPN updater on Windows rolls back the file replacement if it fails. In Tech Poly VPN, if the Marzban panel does not answer after a payment, the request goes back to pending and the discount is not burned. Where there are no migrations, as in the finance assistant, a version is rolled back from a database copy.
What it is: The process in which a search engine (Google, Bing, Yandex) finds a page, reads it and stores it in its database. Until a page is in that database, it appears neither in search nor in AI assistants' answers.
How we use it: After every deploy the site itself tells Bing and Yandex which pages changed (IndexNow), and we submit important addresses for recrawl in the webmaster tools by hand. Bing picks a page up in 1–3 days, Google in 1–3 weeks.
What it is: A file listing every address on the site that search engines read. It tells them which pages exist and in which languages, so nothing gets missed.
How we use it: The sitemap is built automatically from the site content: a new case study, article or glossary term lands in it by itself. Product screenshots go in too, for image search.
What it is: A small file at the site root that tells robots what they may and may not read. One wrong line in it can accidentally hide the whole site from search.
How we use it: Our robots.txt opens the site to all search engines and AI bots (GPTBot, ClaudeBot, Bingbot and others), closing only service addresses. In staging mode one variable hides the site from indexing.
What it is: A tag in the page code saying "the same page in another language lives over there". Thanks to it a search engine shows Russian users the Russian version and English speakers the English one, and does not treat them as duplicates.
How we use it: Every page on the studio's Russian and international sites knows its pair: /uslugi/boty ↔ /services/bots. The pairs are declared both in the page code and in the sitemap.
What it is: A block of data on the page invisible to visitors that spells out what the page is: a service with a price, an article with an author, a question with an answer, an organisation with an address. Search engines and AI read it directly, with no guessing.
How we use it: Every page of the site carries its own markup: Service and Offer with prices on services, Article on case studies and posts, FAQPage on questions, DefinedTerm on glossary terms, BreadcrumbList on breadcrumbs, Organization on the home page. This is what lets an assistant answer "a bot from $80" with a link.
What it is: A file for AI assistants: a short description of the site and a list of pages in plain text, so a model can read the gist in one request without parsing design and menus. A sitemap, but for AI.
How we use it: Both studio sites serve /llms.txt (a catalogue) and /llms-full.txt (all services with prices, case studies, articles and questions). Both are generated from content automatically; nothing to edit by hand.
What it is: A protocol by which a site itself tells search engines "these pages changed" without waiting for a crawl. Supported by Bing (which ChatGPT and Copilot search through), Yandex and others; Google does not support it.
How we use it: Submission is built into the deploy scripts: at the end of every deploy all sitemap addresses go to api.indexnow.org and to Yandex. Nothing to click separately.
What it is: A mode where a question is answered not by a list of links but by an assistant: ChatGPT with search, Gemini, Google AI Overview, Copilot, Perplexity. The assistant takes the answer from a regular search index, so the same pages get in as in search, only later.
How we use it: We prepare pages for such answers: questions and answers in the client's words, prices and timelines in structured data, llms.txt, an About page with facts. Showing up in answers takes 2–8 weeks after indexing, and nothing speeds that up.
What it is: Free search-engine dashboards where the owner verifies the site, submits the sitemap, asks for pages to be recrawled and sees which queries show the site and which pages dropped out.
How we use it: Both studio sites are verified in all three. After a major change we submit the changed addresses for recrawl; once a month we check queries and errors. The procedure is written down so the owner can do it alone.
What it is: A program that understands and writes text: ChatGPT, Gemini, Claude, DeepSeek. On its own it knows nothing about your site until it reads it through search or by link.
How we use it: We use them in bots through APIs: voice transcription, parsing bank statements and receipts, a site chat consultant with facts from the price list. The model answers only from what is in the prompt so it does not invent prices.
What it is: A Python library for Telegram bots. It handles incoming messages, buttons and flows; the bot itself, its database and integrations are written on top of it.
How we use it: The base of all our Telegram bots: subscription sales, the ticket system, the finance assistant. The bot runs in a container on the client's server.
What it is: A full web page that opens inside Telegram from a bot button: a catalogue, a cabinet, a form. The user is already signed in, nothing to install.
How we use it: We build cabinets inside Telegram: plans, client roles, invitation codes. Example: the web service with a Telegram cabinet from the UNLOCK case.
What it is: A way to sign in to a site or service with one "Log in with Telegram" button, no password or registration. The service receives a verified user account.
How we use it: We use it on service cabinets and on VPN access delivery: the user is recognised by Telegram, and the config and subscription are tied to them.
What it is: Payment by QR code or link from a phone through the bank, without a card and with a low merchant fee. Suited to subscriptions and one-off payments in bots.
How we use it: Our subscription-sales bot accepts SBP payments, extends access by itself and keeps the books, with no manual reconciliation.
What it is: The same bot, but in a VK community: it answers messages, takes orders, hands out files. Needed as the main channel for a VK audience and as a backup when Telegram is unavailable.
How we use it: We build VK bots on a shared database with Telegram: one dataset, two entrances. That is how access delivery in the VPN service and ordering in the "Dykhanie Povolzhya" showcase work.
What it is: The main language of Android apps. A native Kotlin app runs faster and more reliably than a "wrapper" around a website and has access to all the phone hardware.
How we use it: The OshaPlay audio player with USB DAC output and the OshaVPN client are written in Kotlin. Builds are signed and update over the air.
What it is: The app checks by itself whether a new version is out, downloads and installs it, so the user never hunts for a file. The version list is signed with a key so it cannot be spoofed.
How we use it: OshaVPN checks hourly: Android downloads an APK for its architecture, Windows downloads only changed files and rolls back on failure. There is a tester channel.
What it is: When an app crashes or cannot connect, it sends a log, its version and the network state to the developer's server. The developer sees the problem before the user writes in.
How we use it: Our own Python receiver in Docker on the client's server: secrets are masked on the device, and when the connection drops the report waits in a queue. No dependence on foreign services.
What it is: Android app stores. RuStore is Russian and free to publish in; Google Play is worldwide with a one-off $25 fee and developer verification. A first install can also be distributed directly as an APK file.
How we use it: We prepare signing, the build, the store page and moderation replies. For internal apps a direct APK link with over-the-air updates is often enough.
What it is: The modern way to build Android app interfaces in Kotlin: screens are described in code, and the layout and theme adapt to the phone and the system settings.
How we use it: The Android interfaces of OshaVPN and the OshaPlay audio player are built with Compose and Material 3: an adaptive layout and a theme that follows the system.
What it is: Google's library for playing audio and video in Android apps: background playback, a notification with buttons, lock-screen controls.
How we use it: The OshaPlay player is built on Media3: background playback and the playback service. Our own C++ output to a USB DAC plugs into Media3 as a custom AudioSink, which is why a track reaches the DAC bit for bit.
What it is: A library that embeds a full torrent client right into an Android app, with no separate program.
How we use it: In OshaPlay it is the built-in torrent client: whatever is found in the combined search across four sources downloads straight into the library.
What it is: Tools for writing part of an Android app in C++. They are needed where timing and precision matter: audio, video, work with hardware.
How we use it: In OshaPlay the audio stream to a USB DAC with a ring buffer and our own resampler with distortion below −130 dB are written in C++ through the NDK.
What it is: The install file of an Android app. It can be handed out as a link or from a bot, with no app store: a person downloads the file and installs the app themselves.
How we use it: OshaVPN and OshaPlay are first installed from an APK link and then update themselves. For the first install we hand out a universal APK, and self-updates then download the build for the specific phone's architecture.
What it is: Notifications that reach a phone or computer even when the app or tab is closed: a new message, a stream starting, an order.
How we use it: In Peregovorka pushes reach each device without duplicates: while a person reads a chat on one device, the others get nothing. Sound can be muted per conversation.
What it is: A link that opens not just an app or a bot but a specific screen with the right data: a client profile, a subscription, an order.
How we use it: A gaming-club client's QR card is a link that opens the bot with the client's number. An oshavpn:// link from the bot adds the subscription to the VPN client at once, and the «Дыхание Поволжья» cart opens the VKontakte community chat with the order code.
Hi! Tell me briefly what your task is — I'll ask for details along the way to suggest a solution and a price for you.
How it works An AI assistant trained on DevUnit's real services answers. For an exact quote or an urgent question, message us directly on Telegram. Don't type passwords or card details into the chat.