Picking an MQTT broker for startups is a different problem than picking one for an established enterprise: you need something free or nearly free today, quick to integrate, and easy to leave or scale if the business takes off. This guide gives early-stage IoT teams a practical decision process, a firmware design that keeps you portable, and a staged plan from a free ConnectMQ Serverless broker to dedicated capacity.
What Startups Actually Need from a Broker
A startup's constraints are time, money and uncertainty. You do not yet know whether you will have fifty devices or fifty thousand next year, which protocols your customers' IT teams will accept, or which features of your product will survive contact with the market. That leads to a short list of requirements:
- Zero operations. Every hour spent patching a broker VM is an hour not spent on the product. A fully managed MQTT service removes that work.
- Free or very cheap at small scale. Your MVP should not carry infrastructure costs designed for production fleets.
- Standard protocol, no proprietary SDK. Plain MQTT 3.1.1 and 5.0 means any library on any device works, and you can switch providers later.
- TLS and credentials from day one. Security retrofits are expensive; start with encrypted connections.
- A visible growth path. You want to know what happens at 25, 1,000 and 10,000 connections before you get there.
Options Compared
| Option | Upfront effort | Cost at MVP stage | Lock-in risk | Notes |
|---|---|---|---|---|
| Public test broker | None | Free | None | Great for demos, never for customer data |
| Self-hosted Mosquitto on a VM | Medium | Low VM cost plus your time | Low | You own patching, TLS, monitoring and outages |
| Cloud IoT platform with proprietary SDK | Medium | Varies | High | Device code tied to vendor APIs |
| Managed serverless MQTT broker | Low | Free tier available | Low with standard MQTT | Quotas define when to upgrade |
For most early teams, the right answer is a managed serverless broker for anything real and a public broker for throwaway experiments. The public MQTT test broker at broker.connectmq.com is ideal for a first spike: anonymous, any non-empty unique client ID, and topics under a unique prefix such as connectmq/demo/k29xq/.... Because everything there is readable by anyone, move to a private broker the moment a pilot customer's data is involved.
Stage-by-Stage Plan
Stage 1: Spike (Days)
Use the public broker to prove the device-to-dashboard loop. Use mosquitto_pub and mosquitto_sub to sanity-check topics:
mosquitto_sub -h broker.connectmq.com -p 1883 -i spike-sub-k29xq -t 'connectmq/demo/k29xq/#' -v
mosquitto_pub -h broker.connectmq.com -p 1883 -i spike-pub-k29xq \
-t 'connectmq/demo/k29xq/dev1/telemetry' -m '{"temp":22.4}'
Stage 2: MVP and Pilots (Weeks to Months)
Create a free ConnectMQ Serverless broker. It supports up to 25 connections, QoS up to 1 and 256 KB messages, which covers a handful of pilot units, a backend worker and a couple of dashboards. You get TLS on 8883, WebSocket on 8083 and 8084, an in-browser client, a topic explorer, a dashboard and threshold alert rules, which is often enough to demo to investors without building your own admin UI.
Stage 3: Early Revenue (Hundreds of Devices)
Move to Serverless (Paid): up to 1,000 connections, QoS 2, 1 MB messages and shared subscriptions, so you can run several backend workers splitting one stream with $share/workers/devices/+/telemetry. Read MQTT QoS levels explained before turning on QoS 2 everywhere; most telemetry is fine at QoS 1.
Stage 4: Scale and Enterprise Customers
When you need isolation, predictable headroom or answers for a security review, move to a dedicated MQTT broker. If a large customer insists the broker runs in their cloud account, BYOC covers that while ConnectMQ still operates it.
Design for Portability from Day One
Lock-in rarely comes from the broker itself. It comes from shortcuts in your firmware and backend. These habits keep you free to move.
Keep Connection Settings Out of Code
Never compile hostname and credentials into firmware as constants you cannot change. Provision them at manufacturing time or over a secure onboarding flow, and store them in non-volatile storage. Here is a minimal pattern for an ESP32 using the Preferences library:
#include <Preferences.h>
struct MqttConfig {
String host;
uint16_t port;
String user;
String pass;
String clientId;
};
MqttConfig loadMqttConfig() {
Preferences prefs;
prefs.begin("mqtt", true); // read-only
MqttConfig cfg;
cfg.host = prefs.getString("host", "broker.connectmq.com");
cfg.port = prefs.getUShort("port", 8883);
cfg.user = prefs.getString("user", "");
cfg.pass = prefs.getString("pass", "");
cfg.clientId = prefs.getString("cid", "");
prefs.end();
return cfg;
}
void saveMqttConfig(const MqttConfig& cfg) {
Preferences prefs;
prefs.begin("mqtt", false);
prefs.putString("host", cfg.host);
prefs.putUShort("port", cfg.port);
prefs.putString("user", cfg.user);
prefs.putString("pass", cfg.pass);
prefs.putString("cid", cfg.clientId);
prefs.end();
}
With this in place, moving from a serverless to a dedicated broker, or to another provider entirely, is a configuration push rather than a firmware release.
Use Plain MQTT, Not a Vendor SDK
Stick to widely used open libraries: PubSubClient or AsyncMqttClient on ESP32, paho-mqtt in Python, MQTT.js in Node.js and browsers. They work against any standards-compliant broker.
Own Your Topic Structure
Design topics around your domain, not your provider: acme/{customerId}/{siteId}/{deviceId}/telemetry. Our guide to how to choose an IoT MQTT broker covers more evaluation criteria, and a good topic structure survives any broker change.
Keep Integrations Outside the Broker
Write telemetry to your database with your own subscriber service, Node-RED flow or Telegraf. That logic moves with you. ConnectMQ deliberately keeps the broker a broker; integrations run as normal MQTT clients, which happens to be exactly the portable pattern you want anyway.
Mistakes Startups Commonly Make
- Shipping demo units pointed at a public broker. It works until a customer notices their data is world-readable.
- One shared username for every device. You cannot revoke a single compromised unit. Use distinct credentials or at least distinct client IDs per device.
- Duplicate client IDs. Two devices with the same ID disconnect each other in a loop.
- No reconnect backoff. After an outage, every device hammers the broker at once. Add exponential backoff with jitter.
- Treating QoS 2 as "more reliable, so always better". It adds round trips and state; make consumers idempotent and use QoS 1.
- Huge payloads. Send images or logs to object storage and publish a reference.
- No status topic. Use a Last Will message and a retained status topic so your dashboard knows which devices are offline.
A Simple Decision Checklist
Before committing, answer these with your team:
- Can we create a broker and connect a device over TLS in under an hour?
- Is the protocol plain MQTT 3.1.1 or 5.0 with no required SDK?
- Are the free-tier limits documented, and do we know which one we will hit first?
- Is there a clear upgrade to more connections, then to isolated capacity?
- Could we move to another broker by changing configuration only?
- Does the portal give us enough visibility (topic explorer, dashboard, alerts) to avoid building our own on day one?
If the answers are yes, you have a broker that fits a startup. For a broader view of hosting models, see our cloud MQTT broker guide.
Launch Your MVP on ConnectMQ
Create a free Serverless broker at app.connectmq.com with no credit card required. You will get credentials in minutes, TLS and WebSocket endpoints, and portal tools to demo your product. When the fleet grows, ConnectMQ offers Serverless (Paid), Dedicated and BYOC plans on the same standard protocol, so scaling is an upgrade, not a rewrite.
Frequently Asked Questions
What is the best MQTT broker for startups on a tight budget?
A managed broker with a genuinely free tier and standard MQTT support, so you pay nothing during the MVP and avoid operations work. A free Serverless plan, for example, supports up to 25 connections with TLS.
Should a startup self-host Mosquitto instead?
It can, but you then own patching, certificates, monitoring and outages. Most small teams get more value spending that time on the product.
How do we avoid vendor lock-in with an MQTT broker?
Use plain MQTT libraries, keep connection settings configurable, design your own topic structure and run integrations as external subscribers.
When should a startup move to a dedicated broker?
When you approach connection quotas, need predictable performance under steady load, or a customer's security review asks for isolated infrastructure.
