rona.bestCase studies

Case studies.

Real systems we built and support. We don't name clients without permission — but we show the mechanics honestly, down to what it looks like in a terminal.

case 01 / e-commerce

Orders processed without a human.

cosmetics manufacturer · online store

Every paid order used to be entered by hand: CRM, invoice, delivery note, coordination with production in chats. We wired it into one pipeline: an online payment starts the chain, and the team just presses buttons in Telegram.

0 manual stepsfrom payment to delivery note
6 deal stagesdriven by Telegram buttons
  • Payment → account in EspoCRM (matched by phone or auto-created), a deal with delivery details and promo code
  • PDF invoice and delivery note are generated automatically and attached to the deal
  • Telegram chain: manager → production (Accept/Decline) → logistics (tracking number in one message) — every click moves the CRM stage, stock is written off by SKU
n8nEspoCRMPDF generationTelegram BotNova Poshta
order-pipeline · n8n
case 02 / manufacturing

Mini-MRP: recipes and raw materials.

the same manufacturer — next level

Raw material needs were calculated in spreadsheets: errors, surprise shortages, manual write-offs. Now the CRM knows whether there is enough material — and keeps the stock itself.

10 secondsfrom status to calculation
+10% wastagebuilt into every calculation
  • An order set to "In progress" is picked up automatically: the recipe (BOM) and per-ingredient needs with a technological loss factor
  • Stock and minimum checks: a shortage → "Waiting" status with an exact purchasing list
  • Enough material → ingredients written off, finished goods received, and a report inside the order
n8nEspoCRMBOM / recipesinventory
mrp · production
case 03 / POS

A mobile cash register for events.

pop-up retail · food courts and events

At offsite events the cash register is a phone: the POS page is served by the automation platform itself, with products from the database. Cash with a change calculator or QR payment — and every sale lands in the books instantly.

2 payment methodsQR + cash
~3 secondsto payment confirmation on screen
  • A cart with discounts and SKU search, built for a cashier's phone
  • QR payments: signed invoices, callback signature verification, duplicate-payment protection
  • Every sale → an account (from payer data), a deal and an invoice in the CRM — automatically
n8npayment gatewayPostgreSQLEspoCRM
pos · payments
case 04 / telegram

A subscription club in Telegram.

a private professional community

A paid club with tiers, a private group and a content library — without a full-time administrator. The bot sells subscriptions, controls access and maintains the content catalog itself.

3 tiers1 / 6 / 12 months
24/7access managed automatically
  • Payments via a gateway with signed invoices; the payment webhook opens group access
  • Channel posts are auto-indexed by hashtags into a paginated catalog with menus
  • A web admin console: stats, revenue chart, subscription management, one-click group removal
Telegram Botpayment gatewayPostgreSQLn8n
club-bot · telegram
case 05 / self-hosted

Self-hosted back office: email, CRM, cloud.

our own infrastructure — we run on what we sell

RONA's entire back office lives on our own servers: email with SPF/DKIM/DMARC (p=reject), EspoCRM with Telegram integration, Nextcloud instead of Google, n8n lead automation and monitoring with alerts. No third-party SaaS subscriptions — and this is exactly the stack we deploy for clients.

0 SaaS subscriptionsthe whole back office on our own hardware
100% passSPF/DKIM/DMARC authentication per DMARC reports
  • Own email: DKIM 4096, DMARC p=reject — messages pass Gmail/Outlook checks, reports are monitored
  • EspoCRM + n8n: a website enquiry becomes a lead automatically, Telegram-bot conversations live right in the lead card
  • Nextcloud (files, calendars, shared documents) and monitoring every 5 minutes with Telegram alerts
MailcowEspoCRMNextcloudn8nmonitoring
self-hosted · rona
case 06 / networks

Resilient access network for 2,000 routers.

a distributed organization · 23 regional branches

A new access-network architecture: around 2,000 routers across districts, each district with redundant uplinks. Before touching the live network, we built a lab and measured two failover designs — the decision was made on numbers, not assumptions.

1.0 soutage on uplink failure (BFD)
40 s → 1 svs. default protocol timers
  • Two designs on the bench: an L2 bridge with link aggregation and an anycast gateway vs. L3 with eBGP + BFD — measured outage 1.1 s and 1.0 s respectively
  • The L3 design won: a district keeps working even with both uplinks lost, and failure domains stay smaller
  • Deliverables: an executive summary, a full technical design and ready-to-apply configs for every node — now heading into a pilot
RouterOSeBGP + BFDOSPFEoIPProxmox lab
lab · failover-test
/contact

Let's discuss your task.

Describe the problem in your own words — we'll translate it into a technical scope, estimate the effort and propose options. First consultation is free.

telegram: @Rona_Best
base: Kyiv, Ukraine
response: < 24h