For a solo IoT freelancer, the outdated advice is to pick a connectivity protocol, get a demo online, and leave the delivery questions for later. Since late 2024, regulatory deadlines and stronger interoperability expectations have made that sequence harder to defend. My position: sell a narrow, testable device-to-service contract first, then choose the transport. I would not build a broker merely to make a prototype look scalable.
A working connection no longer proves that a device is deliverable
The most consequential change of the past two years is not a new wireless protocol. It is the growing gap between “the device connects” and “the client can responsibly ship it.” The EU Cyber Resilience Act entered into force in December 2024, while cybersecurity requirements under the EU Radio Equipment Directive began applying to covered radio products in August 2025. Neither date means every freelancer’s prototype is automatically subject to the same obligations: product category, market, and the freelancer’s contractual role matter. Both dates do make an old recommendation—sort out device identity and updates after the pilot—riskier for products intended for that market, because those decisions affect the evidence a client may need before release.
That does not mean a one-person shop should become a compliance department. It means the proposal should distinguish a demonstration from a releasable product. Write down who provisions credentials, who can revoke a lost device, where software updates come from, and what happens when the service closes. If the client cannot name an owner for those decisions, a successful radio test has not resolved the delivery problem. I would not promise “compliance-ready” based on TLS alone, because transport encryption does not establish a vulnerability-handling process or a safe update path.
The practical specification can be short. Define a device identifier that survives a reboot, a server endpoint controlled by the client, and a documented way to rotate credentials without recalling hardware. Choose a maximum message size—64 KB is a starting limit to tune, not a measured requirement—so a malformed payload cannot silently become an unlimited storage or billing event. State how long the server retains accepted readings and who can export them. These choices constrain the system more usefully than a diagram with an unspecified “cloud” box, because each can be checked at handoff.
Be equally precise about scope. A USB-connected bench unit can demonstrate payloads and update behavior without proving cellular coverage or unattended recovery. A field pilot can test recovery without proving that the final enclosure meets a product standard. Naming that boundary protects the client as much as the freelancer: neither has to mistake a successful demo for evidence it never collected.
Matter’s progress does not make a custom device Matter-ready
The Connectivity Standards Alliance released Matter 1.4 in November 2024, adding work aimed at better multi-admin and home-network behavior. That vendor-published release matters when a client expects a device to join an existing smart-home ecosystem, because interoperability is then part of what the buyer thinks they are purchasing. It does not make Matter the sensible default for a custom sensor that only reports to one private service. The latter still needs a product definition, commissioning flow, and implementation budget before the word “Matter” saves anyone work.
Older advice often treated local interoperability as something to add after a cloud-connected pilot. I would reverse that order when local control is a stated acceptance criterion. Ask the client to demonstrate the intended controller, commissioning method, and behavior during an internet outage before quoting firmware. Otherwise, “works locally” may mean anything from a dashboard on the same Wi-Fi network to standards-based control by another vendor’s application. Those outcomes require different software and different tests.
For a private device, Wi-Fi plus HTTPS may be enough if the site provides credentials and the device can buffer readings while offline. For a product expected to join a Matter fabric, Matter over Wi-Fi or Thread can win because the client is buying participation in that ecosystem; its cost is more implementation and commissioning work. Thread itself also needs a suitable border router to reach other IP networks. Neither choice removes the need to decide who owns the device’s credentials, because joining a network and being authorized to submit a reading are separate events.
Resist using a standards logo as a substitute for a handoff test. Put one physical device through first-time setup, factory reset, credential replacement, and loss of internet access with the client watching. Record which steps require your laptop. If any do, the client has discovered a dependency before paying for an enclosure or a batch of boards. That is a much cheaper disagreement than discovering after delivery that “self-service setup” meant “email the freelancer.”
HTTPS wins for sparse reports; MQTT wins when subscriptions are real
The protocol comparison should start with message flow, not with a claim that one protocol is modern. HTTPS POST wins for a device that wakes, sends a small report, receives an acknowledgement, and sleeps; its cost is repeated connection setup and a server endpoint that must handle retries. MQTT 5.0 wins when devices need persistent subscriptions, prompt commands, or topic-based fan-out; its cost is a broker, connection-state decisions, access-control rules, and a plan for sessions that outlive a device reboot. Those costs exist even when a hosted service operates the broker.
Stop using MQTT by default if you are a solo IoT dev makes a useful challenge to reflexive broker deployments, but I would not turn that challenge into “never use MQTT,” because an existing client-run broker can make subscriptions cheaper than inventing a command-polling API. Conversely, I would not deploy Eclipse Mosquitto on a freelancer-owned virtual machine just to deliver occasional sensor readings. That would make the freelancer the default operator of a service the contract did not ask the client to own.
For HTTPS, Python’s urllib.request or a device-appropriate HTTP library can submit a report, while TLS 1.2 or 1.3 protects it in transit. A server should authenticate the device separately from merely accepting a valid TLS connection. Use an HTTP success response only after the reading is durably accepted; otherwise a device can discard its copy just before the server loses power. Start with three retry attempts as a value to tune, then test against the actual network and battery budget rather than treating three as a universal rule.
For MQTT, decide what QoS 1 means in the application before selecting it. QoS 1 permits duplicate delivery, so the consumer still needs an idempotency key. MQTT 5.0 session expiry and message expiry can be useful for intermittent devices, but their configured values should follow the lifetime of the data: yesterday’s door command and yesterday’s temperature reading do not necessarily deserve the same treatment. A broker does not answer that product question for you.
I treat IoT Connectivity Mistakes That Blow Up Your Roadmap Cost as a useful warning about premature commitments, not a reason to keep every transport option open indefinitely. Pick the cheaper option for the agreed message flow, document the condition that would trigger a change, and stop designing for hypothetical subscribers.
A durable acknowledgement beats an impressive dashboard
The simplest handoff test is deliberately unglamorous: send the same reading twice and prove the server stores it once. Give each device a stable identifier and each reading a sequence number that survives a reboot. On the receiving side, make the pair unique in SQLite or PostgreSQL, then acknowledge only after the insert transaction completes. This does not make an unreliable network reliable; it makes retrying safe when a device cannot tell whether its previous request arrived.
The following Python 3 example is a runnable local check of that receiving rule. Save it as inbox.py and run it twice with the same arguments, such as python3 inbox.py node-a 42 18.5. It creates inbox.sqlite3 and prints “accepted,” then “duplicate.” It is not an internet-facing server: authentication and request-size checks must happen before an incoming request reaches this operation.
import json
import sqlite3
import sys
db = sqlite3.connect("inbox.sqlite3")
db.execute("CREATE TABLE IF NOT EXISTS readings "
"(device TEXT, seq INTEGER, body TEXT, "
"PRIMARY KEY (device, seq))")
device, seq, value = sys.argv[1], int(sys.argv[2]), float(sys.argv[3])
body = json.dumps({"value": value})
with db:
result = db.execute("INSERT OR IGNORE INTO readings VALUES (?, ?, ?)",
(device, seq, body))
print("accepted" if result.rowcount else "duplicate")
That tiny test exposes a question dashboards hide: what if the same device and sequence number arrive with different values? Silently keeping the first reading may be acceptable for one product and evidence of a device fault in another. Decide that rule with the client and test it. Also test an interrupted upload, a reboot before acknowledgement, and a sequence number near its chosen limit. An HTTP 200 response or an MQTT acknowledgement is useful only when both parties agree what it confirms.
Put the resulting behavior in the acceptance sheet rather than in an informal promise. Set a reporting interval—15 minutes is an example to adjust for the use case—and specify how long a device may buffer while disconnected. Record the test date, firmware build, server revision, and observed result. These are inexpensive artifacts a solo freelancer can produce, and they let a client repeat the test without guessing which version of the demo they saw.
The first deliverable should be one repeatable failure test
Before choosing a broker, board, or cloud plan, ask the client for one device and one failure they cannot afford to lose data through. Write a test that reproduces it, including the reboot or outage and the expected server record. Price that test as the first deliverable. If the client will not fund even this boundary check, keep the engagement explicitly at prototype scope rather than implying that a successful connection proves a shippable product.
