Capability

IoT Application Development

IoT app development is the software half of a connected product: the app in your customer's hand, the dashboard your team watches, and the cloud that takes readings from thousands of devices without losing any. We build that half and work alongside the people who built your hardware. Most first releases go live in about 30 days.

Get a free costed plan WhatsApp us

Price: Fixed upfront
Launch date: In writing
First release: About 30 days
You get: Source code & docs

Why own it

Your device is only half a product.

The hardware does the work and the software decides whether anybody enjoys owning it. A customer judges a connected product by how fast the app pairs, whether the reading is current, and what happens when the wifi drops. That part is ours.

Sell the whole thing
A device with a good app is a product. A device with a bad one is a returned parcel.
See your fleet
Every unit in the field, reporting in, with the failures visible before a customer calls.
Keep earning after the sale
Subscriptions, monitoring plans and paid features that run on the data the device already sends.
Own what it collects
The readings sit in your cloud, in your account, ready for whatever you build next.

Hiring a team yourself

Price: Open-ended, paid by the month
Launch date: Moves as the team learns
First release: After months of hiring and building
Your hardware team: Waiting on software to catch up
When a device misbehaves: Nobody can tell you why
After launch: Yours to maintain

Building with Appkodes

Price: Fixed before we start
Launch date: Agreed in writing
First release: Most go live in about 30 days
Your hardware team: Talking to one team that speaks their language
When a device misbehaves: Logs and telemetry that answer it
After launch: We keep it fixed and current

What you get

Four pieces, and they all have to agree.

A connected product is a phone, a browser, a cloud and a device, each with a different job. Pick one to see what goes into it.

App 01 of 03

Customer app

The app somebody opens within a minute of unboxing. Pairing is where most connected products lose their reviews, so it is where we spend the time.

Pairing that worksBluetooth or wifi setup that survives a weak signal and a confused customer.
Live readingsCurrent values with the time they arrived, so nobody wonders if the screen is stale.
ControlsSwitch it, set it, schedule it, with the app honest about whether the device heard.
AlertsA push when something crosses a threshold, not a push every time it reports.
HistoryYesterday, last week, last year, in charts a customer reads without a manual.
Works offlineLast known state shown and labelled, rather than a spinner over an empty screen.

App 02 of 03

Operations dashboard

The browser your team lives in. Every unit you have shipped, reporting in, with the ones in trouble at the top.

Fleet at a glanceOnline, offline, faulty and idle, counted and filterable.
One device, in detailIts readings, its firmware, its owner and everything it has done.
Alert rulesThresholds your team sets, routed to the people who act on them.
Firmware rolloutPush an update to ten units, watch it, then push it to ten thousand.
Maps and groupingBy site, customer or region, however your business is organised.
ReportsUptime, usage and failure rates, exportable for whoever asks.

App 03 of 03

The cloud behind it

Unglamorous and the part that decides whether the product works at ten thousand units. It takes every message, stores it and never silently drops one.

Device connectivityMQTT, HTTP or the protocol your hardware already speaks.
Telemetry pipelineMessages queued and written in order, so a spike is absorbed instead of lost.
Time-series storageBuilt for readings: fast to write, fast to chart, cheap to keep.
ProvisioningEach unit gets its identity and its keys at manufacture, not by hand.
Rules and automationIf this reading does that, do this. Configured rather than coded.
Scales with the fleetThe same design at a hundred units and at a hundred thousand.

Open slot · built to order

Talking to your hardware

Your engineers built the device. We build everything it talks to, and we do the work of making the two agree rather than sending diagrams back and forth.

Firmware and hardware integrationWe work to your firmware team's protocol, or help define one if it is not fixed yet.
A written contractWhat the device sends, how often, in what shape, agreed before either side builds.
Simulated fleetThousands of fake devices reporting in, so the software is tested without waiting on hardware.
Over-the-air updatesThe delivery side of firmware updates, staged and reversible.
Edge decisionsWork that happens near the device when the round trip is too slow or too expensive.
Certification supportLogs and evidence the software side has to produce for an audit.

How it works

From a device on a bench to a product in the field.

Six steps, and the first two are the ones that stop this going wrong.

01
Both
We meet your hardware team
What the device sends, how it connects and what it already does. In a room, not a document.
02
Both
The protocol is agreed
What goes over the wire, in what shape, how often. Written down before either side builds against it.
03
Us
The cloud goes up first
The pipeline that receives readings, tested against a simulated fleet rather than a real one.
04
Us
The app and dashboard follow
Pairing, live readings, controls and the fleet view, built on data that is already flowing.
05
Both
Real devices, small numbers
A pilot batch in the field. This is where you find what the bench never showed you.
06
Both
Open the gate
The fleet grows, and we watch the pipeline and the failure rates with you as it does.

Features

What internet of things app development actually involves.

Your costed plan names which of these are in the first release and which follow it.

Device connectivity and provisioningEach unit gets an identity and keys at manufacture, then connects on first power-up without anybody typing anything.
MQTT and telemetry pipelinesReadings arrive over MQTT or HTTP, queue, and land in storage in order. A spike gets absorbed rather than dropped.
IoT dashboard developmentThe fleet view your team works in, with the units in trouble surfaced rather than searched for.
Firmware and hardware integrationWe build to your firmware team's protocol and help define it when it is not settled. Your engineers own the device. We own everything it talks to.
Edge computingDecisions taken near the device when a round trip to the cloud is too slow, too expensive or unavailable.
IoT securityPer-device keys, encrypted transport, signed firmware and an audit trail. A fleet is only as private as its worst-secured unit.
Over-the-air updatesFirmware delivered in stages, watched as it goes, and reversible when a batch behaves badly.
Alerting that people trustRules, thresholds and quiet hours, tuned so the team still reads the alerts in month six.
Time-series storageReadings kept at full detail while they matter and rolled up after, so the bill does not grow forever.
Public API and webhooksA documented way for your customers' own systems to read the data their devices produce.
AI on your telemetryWhere the data supports it: spotting a failing unit before it fails, or a reading that does not belong.
Customer accountsWho owns which device, who may see it, and what happens when a unit is sold on.

Ways to earn

Ways a connected product earns.

The device is sold once. These are the ways it keeps earning afterwards, and the software is what makes them possible.

Monitoring subscriptionsA monthly fee for alerts, history and remote control.
Tiered plansBasic readings free, detailed history and reports paid.
Per-device feesA price for each unit a business customer connects.
Consumables and refillsThe app reorders what the device uses before it runs out.
Service contractsMaintenance priced on real usage rather than a guess.
Data accessAn API your customers' own systems pay to read.

Example month, 1,400 devices in the field

What the fleet earns after the sale

120 monitoring plans × $9 a month: $1,080
40 business plans × $19 a month: $760
18 service contracts × $240: $4,320
Consumables reordered in the app: $310

Recurring, this month$6,470

That month you also sold 40 devices at $149, which is $5,960. The recurring column overtook the hardware column, and it does that on units you had already sold. Figures are an example: you set every rate.

Who it is for

Custom IoT app development, whatever you have built.

Tell us what the device does and who watches it, and the software is designed around that rather than around a platform we happen to like.

Hardware makers going connected
A product that has sold well offline, and now needs an app before the next retailer will stock it.
Built to fit
- Pairing and control for a device that was never designed for it
- A cloud sized for the fleet you expect, not the one you have
- Store listings and support material for a first app
Industrial and facilities
Machines, meters or sensors across sites, watched by people who are not at those sites.
Built to fit
- A fleet dashboard organised by site and by customer
- Alert rules that reach the right engineer at the right hour
- Reports an operations manager sends upward without editing
Smart home and consumer
A product bought by ordinary people, judged on how the app feels in the first ten minutes.
Built to fit
- Setup that survives a bad router and an impatient owner
- Schedules, scenes and sharing with a household
- Notifications tuned so nobody switches them off
Fleet and asset tracking
Things that move, and somebody who needs to know where they are.
Built to fit
- Live position and route history without draining the battery
- Geofences and arrival alerts
- Reports on utilisation and idle time
Agriculture and environment
Sensors in places with no mains power and no reliable signal.
Built to fit
- Low-power reporting and store-and-forward when the link drops
- Readings by field, zone or site
- Thresholds that account for the season
Retrofitting an existing fleet
Devices already in the field that were never designed to report anything.
Built to fit
- A gateway or bridge for hardware that cannot be changed
- Identity and keys for units that shipped without them
- A migration that brings old units into the new platform

How it works

A price and a date you can plan around.

01 · Before we start
Free costed plan
Tell us what the device does and who needs to watch it. You get the scope, a fixed price and a launch date in writing, free, whether you go ahead or not.
02 · Week 1
The protocol
A session with your hardware team to settle what the device sends and how. This is the cheapest hour on the project and the one that saves the most.
03 · Weeks 2 to 4
Cloud, then screens
The pipeline is built and tested against a simulated fleet, then the app and the dashboard are built on data that is already flowing.
04 · From about day 30
Pilot, then launch
A small batch of real devices in real places first. We fix what the field shows, then open the gate and watch it with you.

Most first releases go live in about 30 days. A fleet with certification requirements or unusual hardware takes longer, and your costed plan fixes the scope and the exact date.

What goes live first, and what follows.

Your costed plan splits the build into releases with their own fixed prices and dates. The first one is what a pilot batch needs.

About 30 days
First release
- Device connectivity and provisioning
- Readings stored and charted
- Customer app: pairing, live values, control
- Fleet dashboard with alerts
After the pilot
Second release
- Over-the-air firmware rollout
- Rules and automation your team configures
- Customer accounts and device transfer
- Reports and data export
When you need it
As the fleet grows
- Public API and webhooks
- Edge processing where the round trip costs too much
- Anomaly detection on the telemetry
- Storage tiering as the history builds up

Store launch

We publish your apps. It is in the price.

Every build ends with your apps live on the App Store and Google Play. Submission is part of the job, never an extra: we prepare everything, handle the review and fix whatever the stores ask for.

Included in every build

Store listings. Name, description, keywords, screenshots and preview images.
Privacy and compliance. Privacy details, data forms and content ratings each store requires.
Signed release builds. Built, signed and uploaded for iOS and Android.
Review and approval. We answer the reviewers and resubmit if anything is flagged.
Updates after launch. Every new version goes through the same process.

The one cost that is yours

Apple and Google charge for a developer account. It is opened in your company's name, so the apps and their listings always belong to you.

Apple App StoreUS$99 a yearApple Developer Program
Google PlayUS$25 onceGoogle Play Console

Submission, listings and reviewIncluded

Store fees are set by Apple and Google and may change.

Tech

What it runs on.

Chosen for what your device does and what your team can maintain. Your costed plan names exactly what your first release uses.

Device link

MQTT
HTTP
Bluetooth LE
LoRaWAN
Cellular

Platforms

AWS IoT
Google Cloud IoT
Azure IoT
Your own broker

Built with

Python
FastAPI
PostgreSQL
Redis
Flutter
React

Runs on

Docker
Kubernetes
Grafana
Your own cloud account

Price

What sets the price.

There is no price list, because no two devices report the same way. Your fixed price comes from the scope in your costed plan, and these are the things that move it.

Get your fixed price

How the device talks
A documented protocol is quick. One still being decided is not.
How many readings
A reading an hour and a reading a second are different systems.
App and dashboard depth
Live values and a chart, or scheduling, sharing and automation.
Firmware updates
Delivering them over the air, staged and reversible, is its own piece of work.
Security and certification
What your market, your insurer or your customer's auditor requires.
Fleet size at launch
A hundred pilot units and a hundred thousand shipped units need different plumbing.

Why the date holds

The protocol is agreed before either side builds.

Your platform is designed and built new for your device. What we bring is the order the work goes in. The thing that wrecks connected products is two teams building against an assumption instead of a written contract, and discovering it when real units are already in boxes. So the message format is settled first, the cloud is tested against a simulated fleet before hardware is ready, and a pilot batch goes out before the gate opens. None of that is learned on your budget, which is why the scope, the price and the date can be fixed.

See the apps we build

After launch

After launch, we stay.

A device you sold today will still be reporting in five years. Somebody has to keep the other end of that connection working.

Watching the pipeline
We watch the message rate, the queue depth and the error rate around the clock. A fleet tells you it is unhappy long before a customer does, and the early sign is usually a small rise in retries rather than anything dramatic.
Fixes
You tell us once and we take it from there. Every issue is logged, fixed, tested and released, and you know where it stands. Anything that stops devices reporting or customers pairing jumps the queue.
Store and platform updates
Apple and Google change their Bluetooth and background rules most years, and those changes break pairing in apps that were fine the week before. We test yours against each new version before your customers get it.
Firmware rollouts
When your hardware team ships a new build we stage the rollout, watch the first batch and stop it if the numbers turn. A bad firmware update pushed to a whole fleet at once is the most expensive mistake in this business.
Security
Per-device keys, encrypted transport and signed firmware, reviewed as the fleet grows and as your customers start asking. Devices outlive the assumptions they shipped with, so this is revisited rather than set once.
Handover
The platform is yours and so is everything needed to run it. Your team gets the code, the cloud accounts, the deployment process and written documentation, including the protocol contract your hardware team will still be reading in three years.

Clients

What our clients say.

Questions

Asked before most builds.

Not here? The costed plan answers the rest, for your app.

Your idea stays yours. We can sign an NDA before you share the details, and you hear from us within 24 hours.

How much does IoT app development cost?

It depends on how the device talks, how often it reports and how deep the app and dashboard go. A documented protocol and an hourly reading is a very different build from an undecided protocol and a reading every second. You get a fixed price in a free costed plan before any work starts, and it does not move unless you change the scope.

How do you connect devices to a mobile app?

Two ways, usually both. Bluetooth for setup and for close-range control, so the phone talks to the device directly. And the cloud for everything else: the device sends readings over MQTT or HTTP, and the app reads them from there, so it works whether the owner is in the room or on another continent.

Do you make the hardware?

No. We build the software half: the apps, the dashboards, the cloud and the connection between them. Your engineers own the device and its firmware, and we work to the protocol they define, or help define it with them when it is not settled yet. Most of the connected products we work on are built exactly this way.

Which IoT platform should we use?

Usually whichever your team can operate. AWS IoT, Google Cloud and Azure all do the job, and the deciding factor is normally what your cloud account is already on and who will maintain it. A plain MQTT broker you run yourself is also a reasonable answer for a smaller fleet, and we will say so rather than sell you a platform.

Do you build the iOS app for our IoT device?

Yes, and the Android one, usually from a single codebase so you are not paying twice. Pairing is the part that differs most between the two platforms and it is the part we spend the most time on, because a product that pairs badly gets returned no matter how good the device is.

What happens when the connection drops?

The device holds its readings and sends them when the link comes back, so the history has no holes in it. The app shows the last known state with the time it arrived rather than a blank screen, which is the difference between a customer waiting and a customer phoning you.

Can you handle firmware updates over the air?

Yes, the delivery side of them. Your hardware team builds the firmware. We stage the rollout, watch how the first batch behaves and stop it if the numbers turn. Pushing a bad build to an entire fleet in one go is the most expensive mistake in this field, so it is built to be reversible.

Will it cope as the fleet grows?

Yes. The pipeline is built for the fleet you expect rather than the pilot you are running, and we test it against a simulated fleet long before that many real devices exist. As the numbers climb we tune it and move older readings into cheaper storage so the bill does not grow forever.

Who owns the platform and the data?

You do. It is deployed into your own cloud account, the code is handed over with documentation, and every reading your devices produce sits somewhere you control. That includes the protocol document, which is the thing your hardware team will still be reading in three years.

Related services

Next step

Your first release could be live
next month.

Tell us about the app you want to build. We send back a costed plan with a fixed price and a launch date, free and yours to keep.

Get a free costed plan See case studies