Most connected-device projects fall apart after the device works. The readings arrive, and then nobody owns what happens next: the data lands somewhere nobody can query, the dashboard is a spreadsheet someone rebuilds every Monday, and the numbers do not agree with the rest of the business. CodeFish builds that layer. We take the data your devices already produce and turn it into a platform your team runs on — ingestion, device management, alerting, dashboards, and the integrations into the systems you already use. We have built asset tracking, environmental monitoring, and industrial operations software on top of devices other people made.
What does IoT software cover?
Device integration
Getting readings off the devices you already have and into something usable. We work with the devices and protocols in front of us, then own everything from the data layer up.
Data pipelines
Device data arrives constantly, out of order, and sometimes not at all. We build the ingestion and storage that copes with that, so the numbers your team reads are current and complete.
Connected systems
The platform that ties devices to the rest of your business. Device management, real-time dashboards, alerting, and APIs that connect device data to the software your team already uses.
How do we build connected-device software?
Prove it against real devices
We build a working proof of concept before committing to a full build, running against your actual devices in the actual environment. You validate the idea and catch the edge cases before they get expensive.
Build the platform
Ingestion, device management, storage, and the dashboards your team will use daily. Built to keep working when devices drop offline, send duplicates, or come back with a week of backlogged readings.
Connect it to your business
Device data is only worth what it changes. We integrate it with the systems that run your operation, so the readings show up where decisions are actually made, then hand it over fully documented.
The gap is rarely the device. It is everything after it — the data, the dashboards and the integrations.
How did we connect the software to Foildrive's foil drives?
Foildrive makes foil drives. CodeFish connected the software to them. The device maker owns the device and its code; we own the apps, cloud services, dashboards and integrations it talks to.
We start with what the device already sends, then design for the people using it and for real conditions: dropped connections, devices off for weeks, readings that arrive late or twice. If your devices work and the software is the missing piece, that is the work we do.
Connected systems we have shipped
Device platforms and operations software across industrial, agricultural, and commercial environments.
Connected-device software questions we get asked
Yes, and it is the usual case. We come into projects where the devices are already specified or already in the field. We do a technical review to understand what they produce and how they communicate, then own everything from the data layer up. We do not build or change the devices themselves. That work stays with the people who make them, and we work alongside them on how the data leaves the device.
We start with a scoping engagement to define what the devices already produce, what the data needs to enable, and which systems it has to reach. From that we produce a technical specification and a fixed-price quote before any build work begins.
That is the most common reason people call us. The devices report fine and the problem is everything after: data landing in a store nobody can query, no single dashboard, and figures that do not reconcile with the rest of the business. We rebuild that layer without touching the devices.
Monitoring is built in, so connectivity gaps and platform faults surface before your team or your clients notice them. Devices drop offline, send duplicates, and return with backlogged readings — the platform is built to expect all three rather than treat them as failures.
If the value is all in the device and the data barely leaves it, this is not worth paying for. Same if an off-the-shelf platform from your device vendor already does the job — we will say so rather than rebuild it. Custom earns its place when the data has to meet your other systems, when the vendor tool cannot answer the questions you need, or when the readings must be trusted rather than indicative.
Ignite is the right starting point if you need to validate the idea with a working prototype before committing to a production build. Amplify is for production systems with a defined spec and budget, quoted at a fixed price. If you are not sure, a scoping conversation will usually settle it in thirty minutes.
We treat dropping offline as normal behaviour, not a fault, and design for it from the start. Readings carry the time they were taken, not the time they arrived, so data that comes in late lands in the right place on the chart. When a device reconnects with a backlog, the platform takes it in without double-counting, because duplicates are detected and discarded. Silence is tracked too: if a device that normally reports every few minutes goes quiet for longer than expected, the right person gets an alert. Your dashboards show which devices are current and which are stale, so nobody mistakes an old reading for a live one.
You do. The data your devices produce, the platform that stores it and the code we write are yours, and they sit in a cloud account you own and control. We set it up that way from the first day rather than hosting it under our name and handing it over later. That means you can give another developer access, move providers or bring the work in house without asking us for permission. If your device vendor also keeps a copy of the data, we check what their terms allow before we build on it, so you know which parts of the data path you control.
Running costs grow with the number of devices, how often they report and how long you keep the data, so we model them before the build starts. Every connected product pays for cloud ingestion, storage and processing, and the bill can climb quietly as devices are added. We estimate the monthly cost at today's fleet size and at the size you are planning for, then design to keep the cost per device flat: sending only the readings that matter, summarising old data instead of storing every raw reading forever, and choosing services priced for the load. You see those numbers before you commit to the build.
We connect to whatever your devices already speak, most often MQTT or HTTPS, and to the cloud platform that suits your business, such as AWS or Azure. Where devices report through a vendor's own cloud or gateway, we connect to its API rather than asking you to change the devices. The technical review at the start of a project confirms what each device sends, in what format and how reliably, before we commit to an approach. On the other side, the platform connects to the systems your team already uses, so device data shows up in the places decisions are made, not in another separate tool.
Data nobody uses is the most common way connected-device projects fail, so we start with the decisions the data needs to support, not the readings the device can send. Before we build a dashboard we ask who will look at it, what they will do differently because of it and what should trigger an alert instead of waiting to be noticed. Readings that do not feed a decision, an alert or a report are stored cheaply or not at all. Once the platform is live, we look at which dashboards and alerts are actually used and cut or change the ones that are not.