CRM, ERP and SaaS in Kropyvnytskyi: ops for agribusiness

CRM, ERP and SaaS in Kropyvnytskyi: systems for an agri economy

Kropyvnytskyi is a city whose economy rests on agribusiness, food processing and dealer networks for machinery. ERP, CRM and SaaS projects here are not «boutique CRMs for a beauty salon» but serious systems with multi-currency accounting, complex VAT-act logic, integrations with 1C, banks and state services (e-Dozvil, tax). I work with teams on Velyka Perspektyvna, around Chervona Zirka and in coworkings near Universytetskyi avenue, and I know what a real process looks like from seed procurement to shipping the finished product to a client.

Typical implementation scenarios

The most common request in Kropyvnytskyi is a custom ERP for an agriholding or dealer network. The business reaches a point where Excel and Telegram chats stop coping: 200+ contracts a month, 5-15 legal entities, multi-currency accounting (UAH/EUR/USD), complex seasonal discount logic and dealer credit limits. Then a system is needed. The second frequent scenario is a dispatch and dealer cabinet for an 8-15 outlet machinery network: real-time stock, order routing, an owner KPI dashboard. The third is a SaaS for a seed or agrochemistry supplier who wants to give farmer clients a cabinet with orders, contract storage and analytics.

Why custom rather than Bitrix or 1C

Bitrix24, KeyCRM and MyCRM are decent platforms and I often recommend staying on them if the business is not ripe. But as soon as you need specific logic (seed batches with traceability, lots, quality certificates, multi-warehouse stock, e-Dozvil integration), ready platforms become tight. Customising Bitrix through its REST API and your own developers ends up more expensive than building a new system from scratch. 1C is a powerful accounting tool but as an operational interface it is dated and slow. A custom solution on a modern stack (Next.js + NestJS + PostgreSQL) gives speed, flexibility and control.

The technology stack I use in Kropyvnytskyi

Front-end is Next.js (React) with SSR and CSR areas for the admin, back-end is NestJS (Node.js, TypeScript) or Laravel (PHP) depending on the client's support team, database is PostgreSQL with pgcrypto for sensitive field encryption, cache is Redis, queues are RabbitMQ or Bull, file storage is S3-compatible, monitoring is Sentry + UptimeRobot, logs are Loki or Datadog. Hosting is a European VPS (Hetzner, Contabo) or AWS/GCP for heavier loads. CI/CD via GitHub Actions, infrastructure as code through Terraform for big projects.

Integrations — the heart of an ERP

30-40% of a typical Kropyvnytskyi ERP project is integrations. Two-way exchange with 1C/BAS (products, counterparties, documents) through REST API or direct DB sync. PrivatBank API and monobank Business for auto-loading statements and matching payments. Nova Poshta for waybill generation and tracking. e-Dozvil for export declarations. The tax service for e-invoices. Integrations with mail (IMAP/SMTP), telephony (Binotel, Asterisk), messengers (Telegram Bot API, WhatsApp Business). Each integration is tested with real data on staging.

Security and compliance

ERP security is not a checkbox but daily work. HTTPS on TLS 1.3, encryption at rest (PostgreSQL pgcrypto), JWT tokens with rotation, row-level security, audit log of every change in critical tables, backups every 6 hours to a separate European server, 2FA mandatory for all admins. Plus network isolation (VPN for DB access), penetration tests before release and regular security audits. For working with personal customer data — alignment with GDPR and the Ukrainian personal data law.

Multi-tenant SaaS architecture

If you are building a SaaS to sell to other businesses (for instance a seed supplier giving farmers a cabinet), the architecture is fundamentally different: a single database, isolated client data through tenant_id on every request, separate subdomains (client1.yoursaas.com, client2.yoursaas.com), billing via Stripe Subscriptions or LiqPay, roles and permissions with a «platform super-admin» level. I have built such systems for agri suppliers — it is a separate genre, more complex than an internal ERP.

How the process runs: from chaos to a system

Step one is a free 30-minute call or meeting in a coworking near KNTU where I listen to your real pains: what is being lost, how many hours go into manual tasks, which reports you cannot get. Then comes paid discovery (3-4 weeks, 1500-3500 USD) where I run 8-15 interviews with different roles, draw the as-is processes, find the leaks, propose to-be processes, shape the modular structure and estimate ROI. The output is a 60-100 page document with a roadmap. With that document you can walk into any contractor.

Phased development

If we continue, development goes in phases of 2-3 modules. First 1-2 key modules in production (contracts and warehouse, for example) over 16-20 weeks. Then we gradually add finance, HR, marketing, analytics. This lets investment start paying back from month five rather than waiting 1-1.5 years for a full release. Each module reaches staging in 2 weeks, then training, then production. Parallel running of the old and new system for 4-8 weeks, without halting the business.

Most common requests from Kropyvnytskyi

Top requests over the past year: a custom ERP for a 5-20 entity agriholding with multi-currency accounting; a dispatch and dealer cabinet for an 8-15 outlet machinery network; a SaaS for a seed or agrochemistry supplier; a CRM with custom contract and VAT-act logic; an integration bus between 1C, banks and Nova Poshta; a mobile app for field managers (PWA or React Native). If your request is something else — write to me and I will say honestly whether it is my zone.

Agri-supplier contract tracking: the ERP core

A typical Kropyvnytskyi agriholding runs about 80-150 active contracts at any moment: seed procurement from suppliers (Bayer, Syngenta, Pioneer, local nurseries), crop-protection contracts, land lease agreements with rural shareholders, harvest delivery contracts to traders, export contracts with buyers in Poland, Turkey, Egypt. Each contract is 5-15 stages from signing to closing: prepayment, delivery, acts, quality testing, export documents, final payment, completed-work act. Holding this in Excel in 2026 is impossible. Holding it in Bitrix24 is possible but lots and batches do not fit without custom logic.

How I model the contract cycle

In the ERP I build a separate «Contract» entity with fields: type (procurement/sale/lease/export), parties, currency, amount, signing date, completion date, status, attached batch (if material), list of stages. Each stage is a separate record with checkboxes, deadlines, owners, attached files (scans, waybills, acts). The system automatically reminds the manager 7-3-1 days before each deadline. Separate logic for payments: if the contract has a 30/70 prepay-postpay split, the system knows and reminds the accountant when each tranche should clear.

Batch traceability

A separate complex genre is traceability. A sunflower batch from field №42 of a farm near Oleksandriia goes to processing into oil, the oil is bottled into 1500 bottles, packed into 250 boxes, delivered to 18 customers in Poland and Germany. If one customer reports a quality issue, you have to answer in 5 minutes: which field, which harvest, which press, which day was bottled. This is done through a chain of batches with unique IDs linked to one another. Off-the-shelf ERPs do not do this — it is custom logic that I build per client.

Dispatch for dealer service centres

A separate strong niche is dispatch for machinery dealers. A Kropyvnytskyi dealer runs not only a shop but also a service centre that repairs tractors, combines, sprayers. In peak season 15-25 machines arrive per day, each with its own history, repair, parts. Without a system the dispatcher loses orders, forgets to call back the customer, cannot tell which machine has which status. I build the system around a digital «order ticket»: the machine is checked in, photographed, faults described, a mechanic assigned, parts ordered from stock, every working hour logged, the final act generated.

Integration with the parts warehouse

The service system does not exist on its own — it is tied to the warehouse. When the mechanic checks a machine in, they see which parts are in stock, which need ordering, the expected delivery time. If the part is in Kropyvnytskyi — 1 hour, if at the central Kyiv warehouse — 2-3 days. That feeds into the repair ETA the customer sees immediately. New parts orders to the supplier are generated automatically on a min-max rule (if stock drops below threshold the system raises a request). This removes 60-70% of warehouse-manager manual work.

Mobile app for field service

In season 30-50% of orders are field service: a mechanic drives to a farmer because a combine «died» mid-harvest. Without a mobile app the mechanic works «by phone» with the dispatcher. With the app they see the order, machine photos, prior repair history, parts available in stock, generate the act right from the field with «before and after» photos, the customer signs on screen. I build this as a PWA (Progressive Web App) — the app behaves natively but lives outside AppStore, updates instantly, works offline (stores data locally and syncs when network returns). Ideal for central Ukraine with patchy 4G.

Integrations with 1C, BAS, SAP Business One

30-40% of any Kropyvnytskyi ERP project is integrations. The Ukrainian reality: 90% of businesses keep accounting in 1C, BAS or their clones. SAP Business One is rare but appears in larger agriholdings with foreign capital. I build the integration through REST API (for fresh 1C versions), or direct DB sync (for old 1C 7.7/8.2 without API), or a middleware bus (for SAP B1 via DI Server / Service Layer). All three formats work, each has its own architecture.

What actually syncs

Two-way synchronisation is not just «a CSV upload at night». It is: products (article, description, prices in several lists, VAT group) — from 1C to the site; warehouse stock — from 1C to the site every 15 minutes; counterparties (new clients and dealers) — two-way; documents (invoices, dispatch notes, acts) — generated in the new system, passed to 1C for accounting; payments (bank statements) — from the bank into 1C and the new system at once for status updates; currency rates — from NBU to both systems.

Integration testing

An integration without testing is a delayed bomb. I run a separate staging 1C/BAS server with a copy of the client's real data (with masked personal fields) and run every scenario through it: create an order, move it through statuses, cancel, return, settle a payment. Each scenario is a separate test case with the expected result on both sides. Before release — 2-3 weeks of «idle running» in production where the new system writes to 1C but data is not yet active. Only after that we flip to live mode.

SaaS for agri suppliers: a separate genre

Over the past two years a new client category appeared in Kropyvnytskyi and the oblast for whom I build a real SaaS: seed and agrochemistry suppliers who want to give their farmer customers a convenient cabinet. The logic: the farmer logs into «My Agri Company», sees their purchase history, recommendations from the supplier tailored to their region and crop, orders a new batch in a few clicks, gets analytics on fields (when integrated with tractor telemetry). This is a separate architecture — not «internal ERP» but an external product that is monetised.

Multi-tenant architecture

The principal SaaS-versus-ERP difference is multi-tenant. One codebase, one infrastructure, but each client's data is fully isolated. I do this through tenant_id on every database query, separate subdomains (client1.yoursaas.com, client2.yoursaas.com), Row Level Security at the PostgreSQL layer — even if someone breaks the back-end code, access to other tenants is blocked at the database. A separate «super-admin» panel for the platform owner: they see usage per client, issue invoices, manage subscriptions.

Billing and pricing

SaaS lives off billing. I build several models: per-seat (per user, the typical CRM logic at 15-30 USD per user/month), per-transaction (per document or order, useful for accounting SaaS), feature-based (base plan plus paid modules), unlimited with annual discount. Integration via Stripe Subscriptions (for global clients) or LiqPay recurrent (for Ukraine). Separate logic for trial period (14 days free, then auto-charge), subscription cancellation, plan upgrade/downgrade.

Mobile-first for field reps

Agribusiness is largely mobile. The manager visits farms, the agronomist inspects fields, the sales rep drives to a dealer, the driver hauls the harvest. In 2026 all of them must have a mobile tool. I build mobile apps in two formats: PWA (Progressive Web App — a web app behaving like native, with offline support, push notifications, home-screen icon) and native (React Native for iOS/Android when deep camera, GPS or NFC access is needed).

What a mobile tool delivers

A manager in the field near Znamianka sees on the phone: their list of dealers, every dealer's order history, current central-warehouse stock, the ability to place an order from the car cabin. An agronomist photographs a field, adds GPS coordinates, describes a problem — everything is auto-linked to a specific contract and client. A driver scans a QR code on the package at loading and at delivery, the GPS tracker logs the route, the ETA auto-refreshes for the customer. All of that removes 50-70% of «phone work» in the office.

Offline mode as a must-have

Central Ukraine is 4G in cities and patchy 3G/2G in fields. A mobile app without offline mode is useless — a manager in a field near Oleksandriia ends up in a no-signal zone and the app falls over. I build offline-first architecture: data is cached locally (IndexedDB for PWA, SQLite for React Native), every change is written to a local queue, and when the network returns it auto-syncs with the server with conflict resolution. This is a separate technical task that adds 30-40% to a basic mobile project, but without it the product is dead on arrival.

ROI and ERP implementation metrics

A Kropyvnytskyi business owner who invests 25-50 thousand USD in a custom ERP has a right to know when the investment will pay back. I always set the metrics before the project starts so that 6-12 months later there is an objective measurement. Typical metrics: order processing time (before — 12 minutes, after — 2 minutes); «lost» documents per month (before — 8-12, after — 0-1); month-close time for the accountant (before — 3 working days, after — 4 hours); number of phone calls between office and dealers (before — 60-80 daily, after — 15-20). These translate into money — and within 8-14 months the ERP pays back.

Start

If you are still reading — write to contacts, browse cases, or jump into adjacent development or ecommerce if you need not just ERP but a website or shop too. ERP is a long-term investment, so the right place to start is honest discovery, not a one-week sale of a «big system».