askcust develops agricultural IT systems that bring data from machinery, sensors, weighbridges and satellites into one database, process it and show it to agronomists and managers. For agricultural enterprises that already have the equipment, but each vendor keeps the data in its own portal.
Agricultural IT systems development is building software that collects data from machinery, sensors, controllers, weighbridges and satellite imagery, stores it in a shared model linked to fields and machines, and turns it into indicators and events for people and accounting systems. Unlike developing record-keeping software in general, the core here is reliable collection and processing of data from devices and external services.
The system pulls data from telematics, sensors, weighbridges and satellite services through their APIs and protocols into one database. Machinery tracks, fuel levels, soil moisture and lot weights appear side by side, linked to the field and the operation.
Gaps, duplicates and reading spikes are filtered out by rules, and raw records are stored separately from processed ones. Any calculation, such as worked area, fuel use or stock, can be traced back to its source or recalculated after a settings change.
Terminals, gateways and mobile apps buffer records and send them once a network is available. The server orders data by measurement time rather than arrival time, so a daily report is complete even after hours without a connection.
Each source is connected to the shared data model through its own adapter. A new brand of trackers or sensors means a new adapter, not a new system: history, reports and accounting integrations stay in place.
Event rules check the data continuously: a pump stops, a machine leaves the field boundary, the fuel level drops sharply. The responsible person gets a Telegram message or a push notification in the app, with a link to the event on the map.
The architecture is always collection, storage, processing and interfaces; the modules are chosen to match the farm's equipment.
Integration with Wialon and machinery manufacturers' telematics APIs: position, speed, engine hours, fuel level and CAN bus (J1939) data sent by terminals. Tracks are split into operations per field.
Sensors send readings over MQTT, while controllers of pump stations, dryers and weather stations are polled over Modbus RTU/TCP through a gateway. The system tracks whether every device is online and records when it went silent.
Sentinel-2 imagery through Copernicus or Sentinel Hub, cloud masking, vegetation indices within field boundaries and history across seasons, shown as a separate map layer next to machinery data.
Exchange with weighbridge terminals and weighing software, import of lab analysis results, and linking weight and quality to the consignment note, the lot and the field the grain came from.
Normalisation of units and time, outlier filtering, calculation of worked area, fuel use and idle time; event rules and alerts routed by role to Telegram and push notifications.
A web dashboard for agronomists and managers, a mobile app for field work, an API for accounting systems, and CSV and ISOXML export for other systems and machinery terminals.
Roles with rights to fields, machinery and actions, a change log, encrypted connections. Controllers running Modbus, which has no authentication in its classic form, are never exposed directly to the internet: data goes through a gateway or VPN.
askcust writes the software and the adapters to data sources; trackers, sensors, controllers and service subscriptions are supplied and maintained by their vendors.
| criterion | Vendor portals | Custom system by askcust |
|---|---|---|
| Data | Each vendor shows only its own equipment, in its own interface. | Machinery, sensor, weighbridge and satellite data in one model linked to the fields. |
| Link to the field | Tracks, fuel and weights are matched to fields and operations by hand, in spreadsheets. | Events are linked to the field, machine and operation automatically as the data arrives. |
| Changing equipment | A new vendor means a new portal, and the history stays in the old one. | A new vendor means a new adapter; history, reports and integrations are kept. |
| Reports | The vendor defines the set of reports and the export format. | Reports follow the farm's processes, and the data is exported to accounting. |
| Storage | History is stored on the vendor's servers within its pricing plan. | Raw and processed data is stored on the owner's server or cloud account. |
| When to choose | One type of equipment, and the vendor's standard reports are enough. | Several data sources, shared reports, custom event rules or an accounting integration. |
A list of equipment, services, protocols and APIs, and data quality checks on real samples. The result is a source map: what can be connected right away and what needs vendor access.
A diagram of collection, storage and processing, a data model (field, machine, device, event) and a prototype of the key screens, agreed before development starts.
One group of machines, one pump station or one field with sensors: checking connectivity, buffering and calculation accuracy on live data.
Connecting the rest of the equipment and clusters using the scheme proven in the pilot, event rules and alerts, data exchange with accounting.
Monitoring data arrival from every source, updating adapters when vendors change their APIs, and extending the system to new equipment.
examples of askcust's work →not agriculture, but the same kind of task: records, CRM, automation
No. askcust develops software and integrates equipment that is supplied and installed by its manufacturer or an integrator. During the audit askcust helps define the hardware requirements: which data a device must provide, how often and over which protocol, so that the system can use it. This way the choice of vendor does not limit the system.
Yes, if it provides data through an API, a standard protocol or files. Telematics with API access, MQTT sensors, Modbus controllers and weighbridge terminals with data export are connected through adapters without replacing the equipment. If a device provides no data at all, the audit shows it before development starts.
On the client's server or in a cloud account the client owns. Raw device data is stored separately from processed data, so any indicator can be checked or recalculated. The code of the system and its adapters is handed over to the client's repository, and askcust's access is limited to development and support by agreement.
Data is not lost, it arrives later. Telematics terminals and gateways buffer records, the mobile app works offline and syncs its queue of changes, and the server orders records by measurement time and drops duplicates. Reports for a period are recalculated once all the data for it has arrived.
By the data and support requirements: how much data arrives and how often, where the system runs and who will maintain it. askcust typically uses Node.js and TypeScript for collection services and APIs, PostgreSQL for data, Python for satellite imagery processing, Next.js for the web dashboard, and Swift and Kotlin for mobile apps.
The development cost depends on the number of data sources and protocols, the amount of processing and the interfaces, not on the number of machines or hectares. The best start is a pilot on one site: after the audit askcust estimates it with a fixed scope, and scaling to the rest of the equipment is estimated separately once the pilot has confirmed that the data arrives and is calculated correctly.
A reply within one business day; a call only if we agree on one.