Skip to main content
LIOMO
Request a demo

Technology · Software Engineering

Software that holds up under real data

We build the gateways, platforms and dashboards that turn device data into daily work, and we design them to keep running when that data is late, noisy or incomplete.

Talk to an engineerExplore our solutions

Overview

From raw packets to a screen people trust

Software for connected systems serves two audiences. Devices send a steady stream of messages that must be received, checked and stored without loss. People need screens, reports and alerts that are fast, accurate and easy to read. Most of the engineering sits between the two.

We build that path end to end. On LIOMO Fleet, our own platform, a TCP gateway decodes tracker packets, validates them and stores positions in PostgreSQL, then raises alerts, geofence events and fault-code events. A Next.js and React web platform sits on top, with role-based access, activity logs and features switched on per client and per vehicle.

Custom projects follow the same approach: clear data models, interfaces other systems can use, automated tests, and the operational routines, such as backups and data clean-up, that keep a system healthy after launch.

Illustrative architecture · example. A layered software architecture: interfaces at the top, then services for ingestion, rules, reporting and integrations, then data stores, then edge gateways and protocol decoders. A side panel shows an example API request.

Principles

How we build software

  • 01

    Data you can trust

    Every message is validated before it is stored, and the system says plainly when a value is missing or stale instead of guessing.

  • 02

    Built around daily tasks

    Screens are designed around what people need to do, such as finding a vehicle or acting on an alert, not around the database.

  • 03

    Open interfaces

    Data is reachable through documented APIs and exports, so it can flow into other systems and stays under your control.

  • 04

    Operations from day one

    Backups, data retention, logging and access control are part of the first release, not added after something goes wrong.

Building blocks

The software stack

The layers we typically build, from device message to finished report. Specific technologies are chosen per project; the examples below come from our own platform and common open standards.
  1. 01

    Ingestion

    Services that receive device messages, decode them and check them before anything is stored.

    • TCP and MQTT listeners
    • Protocol decoders
    • Message validation
    • Acknowledgements to devices
  2. 02

    Data

    Storage designed for large volumes of time-stamped readings alongside ordinary business records.

    • PostgreSQL
    • Time-series data models
    • Indexing by time range
    • Retention rules
  3. 03

    Application and APIs

    The business logic, rules and interfaces used by the web front end and by other systems.

    • REST APIs
    • Webhooks
    • Role-based access
    • Activity logs
    • Background jobs
  4. 04

    Interfaces

    The web screens, maps, charts and reports that people use every day.

    • Next.js and React
    • Live maps
    • Charts and dashboards
    • Spreadsheet and PDF exports
  5. 05

    Quality and operations

    The checks and routines that keep a system correct and running after launch.

    • Automated tests
    • Long-running soak tests
    • Daily data clean-up
    • Backup and restore scripts

Engineering practices

Engineering practices

Tested before release
Decoders, rules and calculations are covered by automated tests, and long soak-test runs check that services stay stable when they run without a break.
No false spikes
When a sensor reports "no signal", the value is marked as missing rather than drawn as a spike, and readings older than 15 minutes are flagged as stale.
Security as a design input
Access is granted by role, every input from a device or a user is validated, and connections are encrypted wherever the devices and networks allow it.
A record of every action
Activity logs and command logs show who did what and when, which helps with support questions, reviews and disputes.
Data kept in proportion
Old position data is cleaned up daily under a set retention rule, so the database stays responsive and storage stays predictable.
Recoverable by design
Backup and restore scripts are part of the system, so recovering data follows a script rather than improvisation.

Applied in

Solutions

FAQ

Questions buyers ask

Do you only work on your own platform?

No. LIOMO Fleet is our own platform, and we also build custom platforms, dashboards and integrations as projects, using the same engineering practices.

Which technologies do you use?

We choose per project. Our own platform uses a TCP gateway, PostgreSQL for storage and a Next.js and React web front end. For other projects we start from your requirements and existing systems, and prefer widely used, well-supported technologies that another team could maintain.

How do you handle large volumes of sensor data?

By treating it as time-series data from the start: storage organised by time, queries that work on time ranges, summaries for long periods, and a retention rule so old raw data is removed on schedule. On LIOMO Fleet, old position data is cleaned up daily.

How do you test before release?

Core logic such as decoders, rules and calculations is covered by automated tests. For services that run continuously, long soak-test runs check stability over time, not just correctness on a single request.

Technology areas

Discuss the technical side of your project

Bring your engineers. We are happy to go into protocols, data models, security and integration details.

Request a demoContact us