When hardware is sold it usually comes with its own software. The problem is that this software does not know how you work: who may pass through which door, who should be called in which situation, what shape your reports need to be in. The device runs, but nobody gets any value out of it.
We do not sell hardware. We program devices to your requirements — either on top of equipment already installed on site, or in parallel with the installation team. Fixing and modernising old software is part of this too.
Which devices we program
- Access and entry — face recognition terminals, turnstiles, fingerprint terminals, card readers and access control panels, electronic locks, intercom panels, detector gates
- Traffic and parking — barriers, licence plate recognition (ALPR) cameras, vacancy displays, entry and exit counters
- Video — IP and PTZ cameras, recorders (NVR/DVR), thermal cameras
- Alarms and sensors — alarm panels, motion, door, glass break, smoke, gas, water leak, temperature and humidity sensors
- Building and energy — lighting and climate controllers, blind motors, water valves, electricity and water meters, UPS and power supplies
- Information and audio — queue kiosks and call displays, digital signage screens, public address and announcement systems
- Retail and warehouse — barcode and QR scanners, receipt and label printers, electronic scales, till hardware, RFID readers
- Network — switches and routers, PoE power, local servers and storage
What "to your requirements" means
A device's own software usually offers one generic rule. We write the rule you actually describe. Real examples:
- "Only staff from this department may use this door, and only during working hours"
- "The face recognition terminal should not keep attendance in its own software — it should write to our reporting system"
- "Open the barrier automatically for a subscriber vehicle; notify the operator for an unrecognised plate"
- "If the cold store temperature goes past the limit, send a WhatsApp message immediately"
- "When a queue number appears on screen, announce it by voice and add the waiting time to the report"
- "When a receipt is printed at the till, reduce the warehouse stock at the same moment"
- "If a door stays open for more than two minutes, alert security"
How we "talk" to a device
Every device opens up a different way. During the site review we state in writing which route is available:
- API or SDK — the easiest route, where the manufacturer provides an official interface
- The device's own database — we read the events directly
- File exchange — CSV/XML files over FTP or a network share, on older devices
- Industrial protocols — ONVIF on cameras, Modbus on meters and industrial equipment, MQTT on sensors, SNMP on network devices
- Electrical level — dry contact, relay, Wiegand, RS-485: the only route on simple devices that cannot be programmed at all
How we work
- Site review. We study the device models, the wiring and the current software.
- Compatibility check. We state in writing which devices the software can talk to directly and which would need replacing.
- Writing the rules. Your rules go into a document first — we code them once it is agreed.
- Pilot. A trial on one door, one floor or one zone.
- Rollout, training and support. Operator training, documentation, and later additions of new rules and devices.
Stated plainly
Not every device can be programmed. Closed systems — devices that only work with their own cloud or their own software and expose no interface — cannot be driven from outside. In those cases either the device is replaced, or only limited control at the electrical level is possible. We say this in writing during the site review, before work starts, so that nobody hears "it did not work out" afterwards.
Face recognition, fingerprint and access logs are personal data. What is stored, for how long and who may view it must be agreed in writing before setup. Also: the software does NOT replace fire safety and security systems — those must operate independently under their own standards.
Frequently asked questions
Do you sell the hardware?
No, we do the software side. If hardware is needed it is supplied together with the installation team; but our main work is writing software on top of devices already on site — which is usually the cheaper route.
Will we have to replace our existing devices?
Usually not. If the device offers an API, an SDK, an open database, a protocol such as ONVIF or Modbus, or at least a dry contact, we build on top of it. Only fully closed devices need replacing — and we state that in writing during the site review.
Can a face control system be connected to our own reporting software?
Yes, this is the most requested job. We read the access and attendance events from the terminal and pass them to your reporting system, ERP or CRM, so you are no longer tied to the terminal vendor software.
Is it better to fix the old software or write a new one?
We answer after the site review. If the old source code or the device interface is available, fixing it is faster and cheaper. If there is no source but the device exposes an interface, writing a new one turns out more reliable.
How is face and fingerprint data stored?
This is personal data. What is stored, for how long and who may view it is agreed in writing before setup. Keeping the data on site, on your own server, is also an option.