IoTSoftwareDevelopment:WhythePilotWorked,WhytheFleetStalls,andWhichPartHastoChange

The short version

The pilot worked. Forty devices at one site reported for six months, the dashboard looked the way the board wanted it to, and the order for the next batch went in. Now every new device needs a technician with a laptop, a firmware push took a batch offline, the cloud bill is climbing faster than the device count, and a customer has asked for a security statement the build cannot produce. Somewhere in that list is a thing the pilot was never built to do, and the first quote you got for fixing it was a rebuild of the platform.

Here is the short version. IoT software development is ordinary software development plus six gates that a pilot never meets: every device needs an identity of its own, every device needs an update path that cannot brick it, the cloud is metered per message and per minute rather than per user, the link drops and the device has to cope, the vendor whose cloud your pilot ran on can switch it off, and from this Friday, 11 September 2026, the EU starts a reporting clock on any connected product sold there. Most fleets that stall are stuck at one or two of those gates. Most of the pilot survives.

Read the rest before you sign the rebuild. What each gate asks for and who enforces it. Why forty devices hide every one of them and four thousand expose them at once. Who does not need any of this. How provisioning, certificates, staged rollouts and metering actually work, with the mechanics taken from the platform documentation rather than from a slide. What Google did to the fleets on its IoT service in 2023 and what a group of Insteon customers had to do in 2022. Which regulations now apply to the thing you are shipping. And the three conditions under which a rebuild is honestly the right answer, because sometimes it is, and a page that pretended otherwise would just be selling you something else.

What does IoT software development involve that ordinary software development does not?

Six gates, each enforced by something that is not your customer and cannot be talked round: a piece of hardware in a cabinet you cannot reach, a network you do not own, a meter, a vendor, and a regulator.

IoT software development is the building of software that runs on, talks to and manages hardware you cannot physically reach, over links you do not control, for years. Server code is ordinary. So is the device code, most of the time. What separates the whole thing from a normal product build is not the framework or the protocol. It is that the software has to survive being installed somewhere, left alone, and expected to work in year four with the same team gone and the vendor's pricing changed twice.

Almost every page that ranks for this phrase describes the same linear build: requirements, architecture layers, protocol choice, cloud, dashboard, deploy. That is fine for a reader who has not started. You have started. Read the table instead. That is the list you are actually up against, written from the side of a pilot that already exists.

Two things fall out of that table. First, only two of the six gates are about code in the usual sense, and even those two (updates and the data path) are really about a process the device follows on its own. The other four are about ownership and evidence: who holds the keys, who owns the endpoint, what you can show a customer, what you can show a regulator. A pilot scoped as a demo produces none of that by default, which is why a pilot that works perfectly can be nowhere near a fleet. Second, the gates are independent. Failing the cost gate says nothing about the identity gate, and a vendor who looks at one failure and quotes you six is not reading the table.

If you want the architecture underneath this page, the protocols, the ingestion pipeline, edge computing and multi-tenant isolation, that is the job of our IoT platform development guide. This page deliberately skips it. You have a platform. Which part of it has to change is the question.

Why does an IoT pilot work and the fleet stall?

Because a pilot runs on six things that do not scale, and none of them is visible until you try.

Think about what actually happened during the pilot. An engineer flashed each device on a bench, typed a serial number into a console, copied a certificate onto it, and drove it to site. That is a technician per device. It took twenty minutes and nobody wrote it down, because it was twenty minutes. When a firmware fix was needed, someone ran a script that pushed the new image to all forty devices, watched the dashboard, and went for lunch. Every device sat on one building's Wi-Fi, which the pilot's sponsor controlled. Nobody built a dashboard, because building one would have delayed the demo, so the vendor's did the job. And the cloud plan was whatever the free tier or the starter tier allowed, which at forty devices reporting every few seconds is nothing.

Now multiply by a hundred. Enrolment becomes a job with a headcount. The certificate that was copied onto the batch expires on one date, for the whole batch, in a week nobody planned for, because a certificate cut in 2025 with a two-year life expires in 2027 whether anyone remembers or not. The firmware script that pushed to forty devices pushes to four thousand, and the one image that fails to boot on one hardware revision takes a few hundred units offline in the same hour, and the units it took offline are the ones that can no longer receive the fix. The fleet is now on forty different networks, some of them cellular, some of them behind a corporate firewall that drops idle connections after five minutes, and the reconnect logic written for one building's Wi-Fi reconnects all at once when the link returns, which is a stampede the broker throttles. Then the cloud bill arrives, and it has not gone up a hundred times. It has gone up more, because the message metering counted every oversized JSON payload as several messages and every idle connection as connected minutes.

Then the outside world turns up. A customer's procurement team sends a security questionnaire that asks how device credentials are issued and rotated, how updates are signed, and what the vulnerability disclosure process is. A distributor in Europe asks whether the product will meet the Cyber Resilience Act. A carrier asks for the module certification. And the vendor whose dashboard the pilot runs on emails a new price list, or a retirement date.

This is the difference between pilot-complete and fleet-complete, and it is the gap most rebuild quotes live in. Pilot-complete means the devices report and the dashboard draws. Fleet-complete means a device can be manufactured, shipped, installed by someone who has never seen a terminal, and then identified, updated, metered, reconnected and reported on for five years without a person touching it, while the cloud it points at can be replaced. One is a product. The other is a product plus a set of processes the devices run on their own, and processes can be added to a product that exists. What cannot be added is a unique identity to a device that shipped without one, or an atomic update to hardware that cannot hold two images, which is the one place the rebuild question is real, and the rebuild section below is where it gets answered.

Now the stakes, plainly. Your next batch is on order, and every unit you ship before provisioning is fixed is a unit a technician has to visit. Every unit in the field with a hand-copied certificate has an expiry date you probably cannot name. Every unit that took a bad image is a truck roll, and the truck rolls are the cost that turns a hardware business unprofitable. That customer questionnaire is the sale, and the sale is waiting on evidence. And if your devices point at a vendor's endpoint, the vendor's calendar is your calendar. We have run the platform side of this at real scale: Pixytan, the GPS platform this team built and runs, tracks 30,000+ vehicles, and the part of that work that consumed the most engineering was never the dashboard. It was keeping the devices addressable, updatable and correctly attributed over years. That is the work described on our custom IoT development page, and it is the work this page is about.

Who does not need a fleet platform, or us, at all?

More companies than the vendors on this page would like. If your devices stay at one site, or the module vendor's cloud is genuinely the product, or nobody outside your own building depends on the data, you do not need a fleet platform and you do not need a development partner. You need the pilot you have and three small habits.

Single-site deployments come first. A few hundred sensors in one plant, one warehouse, one campus, on a network you control, monitored by your own people. Enrolment by technician is fine, because the technician works there. Updates can go out in a scheduled maintenance window, because the site has one. Buy the vendor's dashboard, keep the devices on a private network, and write down the certificate expiry date somewhere a human will read it in two years. That is the whole job.

Then the consumer product whose cloud is the module vendor's business. If you ship a device built on a connectivity module whose vendor runs the cloud, sells the data plan and updates the firmware, you are a customer of a platform, not the builder of one. Your risk is the vendor, and the section on vendor shutdowns below is the one you should read. Everything else is theirs to run. Read their support period and put it in your own product documentation, because under the UK rules it now has to be published anyway.

Internal monitoring is the third group. Devices that watch your own equipment and report to your own operations team, with no customer, no distributor and no sale depending on the data. The gates still exist, but nobody outside enforces them, so you get to fix them in the order that hurts. Start with certificate expiry, because it is the one that takes the whole fleet down on a single day.

And the pilots that have not yet proved the business. If nobody has paid for the data, do not build a fleet platform for a fleet that may never be ordered. Do three things instead, while the pilot is cheap to change: give every device a unique credential even if you issue it by hand, put the device's own timestamp in every message, and make sure the broker endpoint the device connects to is a hostname you own rather than the vendor's. Those three decisions are the difference between a pilot that can become a fleet and one that has to be rebuilt to become one.

How do you enrol four thousand devices without a technician and a laptop?

By letting the device enrol itself the first time it connects, using a credential that can do nothing else.

Every serious broker has a name for this pattern. AWS calls it fleet provisioning, and its developer documentation describes the two shapes any platform ends up with, so they are worth reading in the platform's own terms even if you run a different broker. In provisioning by claim, devices are manufactured with a provisioning claim certificate and private key embedded in them. The claim is registered with the broker under a policy that lets it do one thing: connect and ask for a real certificate. On first power-up in the field, the device connects with the claim, asks for a unique certificate and private key (or sends a signing request so the private key never leaves the device), and then calls a registration step that runs a provisioning template. The template is what creates the device's cloud identity: its name, its attributes, the groups it belongs to, the policy that says which topics it may publish to. Then the device disconnects and reconnects as itself, and the claim has done its job.

AWS puts a clock on that dance, and the clock is the point. The ownership token that comes back with the new certificate expires after one hour, and if the device has not finished registering by then, the certificate is deleted. A device that half-enrols does not leave a half-identity lying around. The same page carries the warning that matters most: provisioning claim private keys should be secured at all times, including on the device, and if you detect misuse, turn off the provisioning claim certificate so it cannot be used for device provisioning. That claim is the one secret shared across your production run. Treat it like the master key it is, watch the metrics for a claim being used more times than you shipped devices, and be ready to revoke it and issue a new one for the next batch.

Provisioning by trusted user is the second shape, and it is the one for installers. A technician, or the customer's own electrician, signs into your installer app. That app asks the broker for a temporary claim, which expires after five minutes, and hands it to the device over Bluetooth or a local hotspot along with the site's Wi-Fi credentials. The device uses the temporary claim to fetch its permanent certificate inside those five minutes, registers, and reconnects. Nobody typed a serial number. Nobody copied a file. Your installer's account becomes the audit trail of who enrolled which device where.

What most pilots miss is the hook. AWS lets you attach a pre-provisioning hook, a function of yours that runs before the template does and answers with a single decision, allow or refuse, plus any parameters you want to override. That function is where your manufacturing manifest lives. A device presenting a serial number you never shipped is refused. A device from a batch you have recalled is refused. A device enrolling in a country you do not sell in is refused. Without the hook, anyone who extracts the claim from one unit can enrol as many phantom devices as they like, and you will pay for every one of them at the meter.

None of this is specific to one cloud. Azure's Device Provisioning Service, a self-hosted broker with a registration API, or a certificate authority you run yourself all end up implementing the same three ideas: a bootstrap credential that can only ask, a per-device credential issued on first contact, and a decision point that is yours. If your pilot's enrolment is a person with a laptop, this is the first thing to build, and it does not require touching the devices already in the field. It requires the next batch to ship with a claim.

Why do device certificates become a problem in year two?

Because every certificate has an expiry date, the pilot chose it without thinking, and a fleet provisioned in one batch expires in one batch.

A device certificate is a promise with a date on it. When the pilot team generated certificates, they took whatever lifetime the tooling defaulted to, one year or two or ten, and moved on. That was the right call for a pilot. It becomes the fleet's biggest single point of failure the moment the batch ships, because a thousand devices provisioned in the same week from the same script expire in the same week, and on that day the broker refuses every one of them. Nothing is wrong with the devices, or the firmware. They simply cannot prove who they are any more, and the platform that would push them a new certificate is the platform they can no longer reach.

Three decisions fix this, and all three belong in the provisioning template rather than in a calendar reminder. Stagger the expiry at issue time, so that devices provisioned together expire across months rather than on a Tuesday. Rotate before expiry, from the platform side, as a routine job: the same jobs machinery that carries firmware can carry a new certificate, and AWS lists certificate rotation alongside firmware updates and reboots as exactly the kind of remote operation a job is for. And keep the private key on the device, generated there, so rotation is a new signed certificate for a key the device already holds rather than a new secret in transit.

Then decide who your certificate authority is. A pilot usually let the broker's own authority sign everything, which is convenient right up to the section on vendor shutdowns. If the authority belongs to the vendor, so does the trust anchor on every device, and moving the fleet to another broker means re-issuing every identity from a new root, which you cannot do to a device that no longer trusts you. A fleet that intends to outlive its first cloud provider signs its devices from an authority it controls and installs that root at manufacture. That decision is close to free on the next batch and close to impossible on the batch already in the field, which is why it appears again in the rebuild section.

And revocation. A device is stolen, a customer churns, a unit is returned and resold. A pilot handles this by deleting the row in the dashboard. A fleet needs the broker to refuse the credential itself, and needs the decision to be reversible when the returned unit is refurbished and shipped again. If your platform cannot answer the question 'which credential does device 2,417 currently hold, when does it expire, and can I revoke it from here', that is the gap, and it is a platform gap, not a hardware one.

How do you push firmware to a fleet without bricking a batch?

Slowly, in stages, with a rule that stops the rollout on its own, and a device that can undo the update without you.

Start with what the pilot did, which was to send the new image to every device at once and watch. That works until the day the image has a defect that only shows on one hardware revision, or one carrier's network, or one region's power supply, and by the time the dashboard shows the first units dropping, the image is already on the rest. The fix that would recover them has to travel over the same path the broken image just closed. None of that means the firmware was bad. Firmware will be bad sometimes. It means the pilot had no rollout policy, and a rollout policy is software.

The AWS IoT Jobs API is a good place to read what a rollout policy contains, because it names the controls in plain fields, and every serious fleet ends up with the same fields whatever it runs on. A job is a set of remote operations sent to one or more devices, and the documentation lists the operations it is for: download and install applications, run firmware updates, reboot, rotate certificates, perform remote troubleshooting. The rollout configuration carries a maximum number of things that will be notified of a pending job, per minute, and an exponential rate, which starts at a base rate and multiplies it each time a set number of devices have been notified or have succeeded. So the first minute reaches a handful of devices. If they succeed, the next minute reaches more. A defect surfaces on the handful, not on the fleet.

The abort configuration is the part that makes the rollout safe when nobody is watching. It carries a threshold percentage, defined as the minimum percentage of job execution failures that must occur to initiate the job abort, a minimum number of executed things, defined as the minimum number of things which must receive job execution notifications before the job can be aborted, and a failure type, which can be failed, rejected, timed out, or all of them. Read those three together and you have a sentence a product owner can sign off: once at least fifty devices have been tried, if more than two percent of them fail, reject the image or go silent, cancel the rollout. Add a timeout for executions that never report back, so a device that went dark during the update counts as a failure rather than as pending forever. That sentence is the difference between losing a handful of devices and losing a batch.

Your device has to hold up its end. Three things, none of them optional at fleet scale. The image is signed and the device checks the signature before it writes a byte, so a compromised update server cannot brick the fleet either. The device holds two firmware partitions and writes the new image to the inactive one, so a failed download leaves the running image untouched. And the bootloader treats the new image as provisional: if the device does not check in with the platform within a set time after rebooting, it boots the previous partition on its own. That last rule is what turns a bricked unit into a unit that called home on the old firmware and reported a failed update, which the abort rule then counts.

If your devices in the field have one partition and no signature check, that is a hardware constraint on the fleet you have, and it moves the conversation to the rebuild section. If they have two partitions and the pilot simply never wrote the rollout policy, that is a platform feature, and it is added to the pilot rather than replacing it.

Why does the cloud bill grow faster than the device count?

Because the cloud does not meter devices. It meters messages, message size, connected minutes and operations, and a pilot's device is expensive in every one of those units.

Read the units before you read the number. AWS publishes the metering rules for its IoT Core service, and the shape is what matters here, not the price, so the prices are deliberately not on this page. Messages can be up to 128 KB in size and are metered in 5 KB increments, so an 8 KB message is metered as two messages. Connectivity is metered in one-minute increments, based on the total time devices are connected. Device shadow and registry operations are metered in 1 KB increments of the record size, so an update to a 1.5 KB shadow record is metered as two operations. Rules and actions are metered in 5 KB increments of the message size, so a rule that processes an 8 KB message and applies two actions is metered as two rules and four actions. Every other cloud has its own units. What matters is that the units are size and time, and the pilot never looked at either.

Now look at what the pilot's device does. It reports every reading, every second, in a human-readable JSON document with the field names spelled out, a timestamp string, and the device's own metadata repeated in every message. That document crosses a 5 KB boundary more often than anyone expects, and each crossing doubles the count. It stays connected around the clock, because the pilot never had a reason to disconnect, so every device contributes every minute of every day to the connectivity meter. And every message fires a rule that writes to a database and a stream, which is two actions per increment. Multiply by four thousand devices and the bill did not grow with the fleet. It grew with the fleet times the message rate times the increments times the actions, and only the first of those is the number you thought you were buying.

Fixing this is ordinary engineering, and it is the second cheapest gate to close, after provisioning. Report by exception: send a reading when it changes by more than a threshold, and a heartbeat otherwise. Batch: hold readings on the device for a minute and send one message, under the increment boundary, instead of sixty. Encode: a compact binary payload with numeric field identifiers is a fraction of the size of the same data as JSON, and the device already knows the schema. Disconnect when idle where the use case allows it, or hold the connection open where the use case needs sub-second commands, but decide, rather than inheriting the pilot's default. Aggregate at the edge for anything that produces raw waveforms, so the cloud sees the summary and the device keeps the detail until asked. And tier the storage, because the query a customer runs on a year of history should not walk the same table that took the ingest.

One warning, because it catches people who fix everything above. A reconnect stampede is also a meter event. When a site's link comes back after an outage and four hundred devices reconnect in the same second, each one re-sends its buffered readings, and if the buffer was sized in messages rather than in increments, the burst is metered at the worst possible rate at the worst possible time. Jitter the reconnect, cap the replay rate, and let the platform pull the backlog rather than the devices push it.

None of this changes the device hardware. All of it changes firmware and the data path, which is why it belongs in a slice of work rather than a rebuild, and why the cost gate is almost never the reason a rebuild is justified.

What happens to your fleet when the vendor's cloud goes away?

Every device that has the vendor's endpoint burned into it stops working on the vendor's date, and the two examples below are the ones to keep in mind when someone tells you it will not happen to a company that size.

On 19 August 2022 Google told customers of Cloud IoT Core, its managed device connection service, that the service would be discontinued on 16 August 2023. The notice, as reported at the time, said that on that date access to the IoT Core Device Manager APIs would no longer be available, that devices would be unable to connect to the Cloud IoT Core MQTT and HTTP bridges, and that existing connections would be shut down. One year of notice, from one of the three largest cloud providers in the world, and a partner announcing a migration path because Google itself had not published one. Every fleet built on it had twelve months to change what its devices pointed at, and any device whose endpoint could not be changed remotely had twelve months to be visited.

Insteon is the other one, and it is worse, because there was no notice. In mid-April 2022 the smart home company's cloud servers went offline without warning, and the app and every remote feature stopped with them. Customers' devices still worked locally, which is the only reason the story has an ending: in June 2022 a group of Insteon users bought the company and its assets, and in October 2022 the new owners brought the service back. That fleet survived because its owners happened to be technical, organised, and willing to buy a company. That is not a plan.

So here is the test, and it is the one to run on your pilot this week. Can you point every device in the field at a broker you control, without touching the device? If the answer is yes, the vendor is a supplier and the fleet is yours. If the answer is no, the vendor owns your fleet and you are renting it back. Your answer depends on three things the pilot decided without noticing. Whether the broker hostname in the firmware is a name you own, which can be re-pointed in DNS, or the vendor's name, which cannot. Whether the trust root on the device is an authority you control, so a new broker can present a certificate the device will accept, or the vendor's authority, so it cannot. And whether the data the vendor's dashboard shows you is also being written somewhere you can query without the vendor, so that the day the dashboard goes dark is an inconvenience rather than the end of your history.

This is also the honest place to say which parts of an IoT platform you should rent and which you should own. Rent the broker, the message transport, the time-series database, the dashboard framework, the connectivity. All of them are commodities and all of them can be swapped if the three things above are yours. Own device identity, the update path, and the data. Those are the parts a vendor cannot give back to you once it has them, and the parts a buyer of your company will ask about first. Our comparison of AWS IoT Core, Azure IoT Hub and a plain MQTT broker goes through the transport decision in detail. Whichever one you pick, pick it as a supplier.

Which regulatory gates does a connected product hit in 2026?

Three that most pilot teams have never read, and the first one starts its clock four days after this page was published.

Your pilot was a project. Your fleet is a product, and products with radios and software in them are now regulated in the largest markets your distributor sells into. None of the rules below is about code quality. They are about processes and published facts, which is why a build that works perfectly can fail every one of them, and why the fix is mostly documents and a platform feature rather than a rewrite.

Take the Cyber Resilience Act first, because of the date. Regulation (EU) 2024/2847 entered into force on 10 December 2024 and its reporting obligations apply from 11 September 2026. Under Article 14, a manufacturer that becomes aware of an actively exploited vulnerability in its product must send an early warning within 24 hours, a vulnerability notification within 72 hours, and a final report no later than 14 days after a corrective or mitigating measure is available. Severe incidents run on the same 24 and 72 hour clock with a final report within a month. Article 16 makes ENISA the operator of the single reporting platform those go to. Article 13(8) sets the support period, the time during which you must keep handling vulnerabilities, at a minimum of five years unless the product is expected to be used for less. The main obligations, including conformity assessment before a product is placed on the market, apply from 11 December 2027, and Article 64 allows fines of up to EUR 15 million or 2.5 percent of worldwide annual turnover, whichever is higher. Read that against the update section above. A 24-hour early warning and a 14-day fix presuppose that you can find out a device is exploited and push a signed fix to the fleet on a staged rollout. A pilot with a shared password and a push-to-everything script cannot meet the clock, however good the code is.

Britain's regime is older, simpler and already enforced. The PSTI Regulations 2023 came into force on 29 April 2024 and Schedule 1 sets three requirements for consumer connectable products. Passwords must be unique per product or defined by the user, and must not be based on incremental counters, publicly available information or unique product identifiers, or be otherwise easily guessable. The manufacturer must publish at least one point of contact for reporting security issues, and the timescales for acknowledgement and status updates until resolution. And the minimum length of time for which security updates will be provided must be published clearly and accessibly. Three sentences, and the first one is failed by every pilot that baked a password into the firmware image.

PTCRB is the one your carrier will raise. It has certified wireless devices since 1997, covers modules, IoT chipsets and devices incorporating certified chipsets, and is accepted by network operators around the world. For a fleet, the practical point is the module. A device built on a module that is already certified can go through the IoT Network Certified path rather than full certification, which is the difference between weeks and a project, and a change to the radio hardware or its firmware reopens the question. If your pilot's device was built on an uncertified module because the module was cheaper, that is a hardware decision the fleet will pay for at the carrier, and it is the one regulatory gate on this page that a platform change cannot close.

Connectivity is the engineering half of the regulatory half. That 24-hour clock assumes your devices can be reached. Field devices lose the link: a cellular cell goes down, a site changes its firewall, a gateway loses power. So the device has to buffer readings with its own timestamps while offline, reconnect with a random delay rather than in a stampede, and where the product can justify it, fall back to a second bearer. A pilot on one building's Wi-Fi tested none of that, and the first winter the fleet spends in the field will.

When is a rebuild of the platform honestly the right answer?

In three cases, and all three are about the devices in the field, not about the code on the server.

The first is identity that was never unique. If the batch already installed shares one certificate, or authenticates with a password compiled into the image, and the device has no way to generate or receive a new credential of its own, then there is no path from the fleet you have to a fleet that can pass a customer's security review or the UK's password rule. Each device would have to be visited to be re-keyed, which is a rebuild of the fleet, not the platform. Your platform can be fixed for the next batch. Units already installed are a truck roll each, and the honest quote says so.

The second is an update path that cannot be made atomic on the hardware in the field. A device with a single firmware partition and no signature check can be updated, but it cannot be updated safely, and no rollout policy on the platform side changes that. Every push is a bet on the image. If the product's support period under the Cyber Resilience Act is five years, that is five years of bets. Often the right answer is a hardware revision for the next batch and a decision about how much risk to carry on the installed base, and that is a conversation about the fleet, not a platform rebuild.

The third is data that was never timestamped at the device. If readings were stamped on arrival at the cloud, then every outage, every reconnect stampede and every buffered replay has already corrupted the record: readings from Tuesday are filed under Thursday because that is when the link came back. Data already stored cannot be repaired. Firmware has to change, and if the device has no clock or no way to sync one, the hardware has to change.

Everything else on this page is a slice. Provisioning is a template and a claim on the next batch. Rotation is a job. A rollout policy is configuration plus a bootloader rule. Metering is firmware and a data path. Vendor independence is a hostname, a trust root and a second copy of the data. Regulatory documents are documents. Each of those can be added to a working pilot in the order that hurts most, while the devices keep reporting, which is the same argument we make about any working system on our page on legacy system modernization without the rewrite. What you have is the system that runs your business. Slice it.

One confession, because this page would be dishonest without it. Geminate Solutions makes money from IoT platform builds too, and a rebuild bills more than a slice. Our difference is not that we have no interest. It is that the read comes before the quote, on your firmware and your platform, and it names which of the three cases above applies, if any, before anyone at Geminate Solutions says the word rebuild.

What should you ask an IoT development partner before you sign?

Six questions, and the last one is the test. Ask them of us too.

First, which of the six gates is my fleet actually stuck at, and which ones does it already pass? A partner who has read your pilot can answer in one meeting. A partner who answers 'all of them' has not read it.

Second, what changes on the next batch of devices and what changes on the ones already in the field? Those are two different answers, and the second one is where the truck rolls are. If the partner's plan does not distinguish between them, the plan is a platform plan for a fleet problem.

Third, show me the rollout policy you would ship with. Not a promise of staged updates. The actual thresholds: how many devices in the first wave, what failure rate cancels the job, how long a device has to check in before it counts as failed, and what the device does on its own if the new image does not boot.

Fourth, who owns the trust root, the broker hostname and the raw data at the end of the engagement? Only one answer is acceptable: you, in writing, with the credentials in your accounts. Anything else is a vendor lock-in with a different vendor.

Fifth, what is the Cyber Resilience Act reporting process for this product, and who is on call for the 24-hour early warning? If the partner has not heard of Article 14, they are about to learn it on your product.

Sixth, and this is the test: tell me the one thing in my pilot that you would not change. A vendor who wants the rebuild cannot answer it. A partner who has read the pilot will name something, because there is always something, and it is usually most of it.

How does Geminate Solutions run an IoT engagement?

Read first, then a fixed-scope first slice, then the fleet work in the order that hurts, with you owning every credential from the first day.

It starts with the fleet read, which is free and written. Send us the repository, the firmware build, the provisioning steps as they actually happen today and the broker configuration, and a senior engineer reads them against the six gates in this page. You get back a document that says which gate is blocking, what already passes, what changes on the next batch and what changes in the field, whether any of the three rebuild cases applies, and what the first slice should be. No pitch. If the honest answer is that you are a single-site deployment that needs a certificate expiry reminder and nothing else, the read says that.

Then a paid pilot sprint on the first slice, scoped in writing before it starts. For most stalled fleets that slice is provisioning, because it stops the technician-per-device bleeding on the batch that is about to ship. For a fleet with an expiry date approaching it is rotation. For a fleet that just lost a batch to an update it is the rollout policy and the bootloader rule. One slice, one outcome, and you decide whether to continue after seeing it work on real devices.

After that, the fleet work runs as slices too, against the platform you have. Geminate Solutions is a software and product development partner, not a staffing agency: we do not place engineers on your payroll and we do not hand you a bench. Our team owns delivery of each slice and you own the result. Your broker runs in your cloud account. Your certificate authority stays yours. Data lands in your storage, and the repositories are yours from the first commit. When the engagement ends, nothing has to be migrated away from us, because nothing was ever ours.

Our proof is the one that is real. Pixytan, the GPS platform this team built and runs, tracks 30,000+ vehicles in the field, and the platform side of that work, keeping devices addressable, updatable and correctly attributed over years, is the same work described on this page. The case study has the detail. If you are still deciding between a builder and a custom platform, read our IoT app builder or custom build decision first. If you want to know what moves the effort on a build like this, the IoT app development cost drivers page is the honest version. And if the pilot is already stalling, the fleet read is the next step, and it is on our custom IoT development page as well as at the foot of this one.