Custom Software Solutions
XTELL builds web applications and backends for companies whose product contains hardware: device dashboards, remote control interfaces, IoT platforms and WebRTC real-time video. One team writes the firmware, the app and the server, so a misbehaving device can be diagnosed by opening its firmware.
XTELL builds custom web applications for companies whose product contains hardware. Device status, alarms, video and remote control, delivered in the browser.
If you are comparing suppliers of web application development services and your product has sensors, controllers, cameras or instruments in it, this page is written for you. What you need is not a marketing site - it is a system people log into, watch live data on, and send commands from. As a custom web application development company we build that system, and the device-side layer it depends on, together.
Hardware and IoT manufacturers who need a cloud console, a monitoring dashboard or a remote control interface for the devices they ship.
Companies who have already been quoted by a mobile app development company or a cross platform app development company, and realised the app is only a third of the work - the backend and the device firmware still have to come from somewhere.
Industrial and field operations teams who need device state, command dispatch and fault alerts in a browser rather than on site.
Software teams without a hardware background who can build the application layer but need someone to handle the device-to-web protocol work.
We also take on pure software projects with no hardware involved. The cases and advantages described below simply concentrate on device-related work, because that is where our experience is.
IoT device management platforms - device onboarding, online state, alarm events and remote operations.
Remote device management software and remote monitoring and management platforms - one console covering a fleet spread across sites, with state, alerts and command dispatch in the same place.
Data acquisition and visualisation - sensor readings into the backend, stored, queried and charted.
Video in the browser - RTSP and HLS streams relayed through to a web client.
Real-time audio and video over WebRTC - multi-party conferencing, one-to-one video calls, and browser-to-Android sessions, with the signalling and media server built rather than rented.
Voice and audio processing - Speex and Opus coding, noise reduction, keyword spotting, and low-latency IP intercom, implemented down to the embedded layer where the product needs it.
Any endpoint pairing - web to web, web to mobile, mobile to mobile, mobile to device, device to device and web to device, all of them delivered rather than theoretical.
Real-time control - commands issued from a web page, through the backend and the message channel, to the device.
Progressive web app development services - installable to the home screen, working offline and receiving push, when a light function does not justify making customers download a native app. Flutter PWA is supported as well.
Custom web applications and REST APIs for whatever else has to connect to the system.
Devices report over MQTT through an EMQX broker, or over CoAP. A NestJS or Node.js service handles ingestion and business logic, with data in PostgreSQL and hot state in Redis. The browser gets live updates over WebSocket and everything else over HTTP.
Video runs on its own path: RTSP into ZLMediaKit, converted to HLS for the web client.
Where the product needs two-way audio and video rather than one-way viewing, WebRTC replaces that path - peer connections for the media, a signalling service of our own, and a backend handling rooms, participants and recording.
That structure is what IoT platform development means in practice here - not a product we resell, but an architecture assembled per project. Every case below has run on it in production.
Six endpoint combinations, all of them shipped: web to web, web to mobile, mobile to mobile, mobile to device, device to device, and web to device. Most suppliers in this space cover the first two. The ones with a device at either end are where it gets hard, because a browser and an embedded board do not negotiate media the same way, and the endpoint with 200KB of RAM sets the terms.
The online interview platform runs WebRTC video between candidate and interviewer, with Node.js and PHP services behind it, SQL Server for data, a native Android client and a web management console - web to web and web to mobile in one product.
A cloud video chat system was built server-side in C++, with configuration-driven deployment and automated release scripting. An IP intercom system takes it down to the embedded layer - audio capture and encoding on the device, real-time transmission over IP, tuned for low latency.
Below the transport sits the codec work, and that is its own discipline. A smart helmet intercom runs Speex for voice coding over a 4G link, with a TCP relay server and UDP heartbeat holding a group session together - device to device, with no phone in the path. We also work in Opus where bandwidth and quality have to be traded dynamically, and have built noise reduction and keyword spotting into an audio path on a posture sensing device. An IP intercom system took it down to the embedded layer entirely: capture and encoding on the device, real-time transport over IP, tuned for latency rather than fidelity.
One-way viewing is a different problem and we build that too: the 433MHz security system relays RTSP camera streams through ZLMediaKit to the phone app - mobile to device - while the R528 control board takes commands straight from a browser over WebSocket, which is web to device. Which of the three - two-way conferencing, low-latency voice, or one-way viewing - a product needs is worth settling early, because the architectures diverge completely.
The same team writes the firmware, the app and the backend. When a device misbehaves, a software-only supplier can relay the symptom - the device stopped reporting. We can open the firmware and see what the device actually sent, and whether the server received it.
It also removes the round trips. Protocol changes and serial formats get settled inside one team rather than negotiated between two suppliers.
XTELL (Shenzhen XTELL Future Technology) was founded in Shenzhen in 2016. Over the decade since we have delivered more than 100 projects, with clients predominantly western B2B companies.
Firmware: STC32G128K on FreeRTOS managing the 433MHz terminals, TXW82x SDK driving the IPC camera. Mobile: Flutter for iOS and Android with QR provisioning, WiFi scanning, RTSP/HLS playback, alarm push and arming control. Backend: NestJS with TypeORM over PostgreSQL, Redis, EMQX as the MQTT broker and ZLMediaKit for stream relay, under Docker Compose.
Embedded Linux (Tina-Linux) offering two channels upward: HTTP for file transfer and WebSocket for real-time control, receiving and dispatching GCODE. Five UART channels plus GPIO and USB drivers on the peripheral side.
WebRTC video between interviewer and candidate, with Node.js and PHP backend services, SQL Server for data, a native Android client and a web management console.
Speex voice coding over a 4G link, with a TCP real-time audio relay server, a UDP heartbeat signalling server holding group sessions, MySQL group management and a PHP web backend.
ESP8266 sensor nodes reporting to a Node.js backend, with multi-channel analog switching and battery current monitoring on the node, and a local LCD display.
You send the device list, the communication protocol and the functional requirements. We confirm feasibility, including whether anything has to change on the device side.
Architecture recommendation and scope of work. Whether source and design files transfer is written into the contract at this step, per project, rather than promised page-wide.
Iterative delivery, with device and software debugged together rather than across companies.
Deployment, acceptance testing and ongoing maintenance under the agreed terms.
There are two models, open and closed. Whether source and design files fall inside the delivery scope is agreed item by item in the contract and settled before signing. We do not make a blanket promise on this page.
Yes, backend and frontend both - we work as a web application development company on projects with no hardware in them at all. To be clear about it though: our strongest position is a web application with real devices behind it. Pure software projects are delivered the same way, you just do not get the cross-hardware debugging advantage.
Yes. We build the backend and the web layer and integrate with your firmware team. The cost is that device-side diagnosis has to go through you, which is slower than when the firmware is in our hands. If that matters on your project, consider giving us the device side too.
Yes, on a standard web stack with a service worker - installable to the home screen, usable offline and able to receive push, without going through an app store. Where a product needs full native behaviour we build the iOS and Android app instead and say so.
A cross platform app development company crosses one boundary - one codebase running on iOS and Android. We cross that one and the hardware boundary as well: the same team writes the app, the backend it calls and the firmware on the device it controls. On a product that is purely software we are not the cheaper option. On a product with a device in it, the integration work an app-only supplier hands back to you is work we absorb.
Yes, and across every endpoint pairing: web to web, web to mobile, mobile to mobile, mobile to device, device to device, and web to device. Most suppliers here cover the first two; the ones with a device at either end are the hard ones, because the endpoint with 200KB of RAM sets the terms. Signalling and backend are built rather than rented from a platform. Delivered work includes an online interview platform on WebRTC, a C++ cloud video chat server, and an embedded IP intercom. Codec-level work comes with it: Speex over 4G on a helmet intercom, Opus where bandwidth and quality trade dynamically, plus noise reduction and keyword spotting on an embedded audio path. If your product only needs one-way viewing, RTSP relay is the cheaper architecture and we will say so.
Assessed per project against the scope of work. The more specific you are about device models, protocols and the function list, the more accurate the assessment. We do not publish figures here - published figures would not mean anything for your project.
Contact us for customized solutions and quotes