Bulk SMS software vs GSM modem hardware vs phone apps

A USB GSM modem costs less than a nice dinner. An unlimited-text SIM plan costs less than most SaaS seats. Free open-source gateways can drive both. If you do the math the obvious way, a modem pool looks like the cheapest bulk SMS sender you could possibly build, and on a per-message basis it often is.

The problem is that the per-message line is the only one that looks good. Throughput, carrier bans, A2P 10DLC registration and TCPA exposure all count against the hardware route, and the costs show up as blocked numbers, dead SIMs and legal risk rather than on an invoice. This post compares the three device-based approaches with a registered cloud API. We make Ready, which is one of those APIs, so we'll also say where a raw CPaaS is the better fit.

The four options, defined

Before comparing them, here is what each option actually is.

• GSM modem pools. USB or rack-mounted modems, each holding a consumer or business SIM, driven by AT commands or a gateway like Gammu, Kannel or playSMS. Scaling means adding more modems and more SIMs.
• Phone apps (device-based senders). An Android app that sends bulk texts through the phone's own SIM, sometimes controlled from a web dashboard. It is a modem pool with one modem and a touchscreen.
• Open-source gateways on top of either. This is software, not a sending route. It handles queuing and retries, but the messages still leave through a SIM on the person-to-person network.
• Cloud API on registered routes. You call a REST endpoint. The provider sends over carrier infrastructure on an A2P 10DLC campaign registered to your brand. Examples are raw CPaaS APIs like Twilio and Telnyx, and platforms like Ready.

The real dividing line is not hardware versus software. It is person-to-person (P2P) traffic versus application-to-person (A2P) traffic. The first three options all send business messages over consumer P2P routes. Carriers built 10DLC to stop exactly that. If the distinction is new to you, our explainer on A2P vs P2P texting covers the rules.

Throughput: what each setup can actually push

Modems and phones

Carriers don't publish limits for consumer SIMs, and they change them, so treat any figure as an assumption. Here is a worked example. Assume one modem sends 10 messages a minute before the SIM starts looking abnormal:

• 5,000 messages ÷ 10 per minute = 500 minutes, about 8.3 hours on one modem
• An 8-modem pool brings that down to about an hour

That math works. The trouble is that a SIM sending a steady stream of near-identical texts to thousands of numbers that never text back is the exact pattern carrier spam detection looks for. Adding modems spreads out the volume, but it also gives carriers more SIMs with the same suspicious pattern to flag.

Registered cloud routes

On 10DLC, throughput is set per campaign, in segments per second. A fresh standard campaign without vetting gets roughly 1 to 4 segments per second, and higher use-case tiers reach tens. At an assumed 3 segments per second:

• 5,000 single-segment messages ÷ 3 = about 1,670 seconds, roughly 28 minutes

T-Mobile also caps daily volume per brand by trust score. The tiers run roughly ~2,000, ~10,000, ~40,000, ~100,000 and ~200,000 messages a day. If about a third of that 5,000-contact list is on T-Mobile, that's around 1,700 messages, which fits under even the lowest tier. AT&T throttles per second and per minute rather than with a hard daily cap. Brand vetting ($79 Standard / $179 Enhanced, one-time) can raise your trust score, but it only moves the daily cap when it pushes you into a new tier. Our post on whether brand vetting is worth $79 works through when it pays off.

A registered route at the lowest tier is slower per second than a large modem pool. The difference is that its limits are known in advance and the traffic is permitted.

Ban risk: where the hardware route breaks

Consumer SIM plans prohibit automated or commercial bulk messaging in their terms of service. When carriers detect a SIM doing it, they can:

1. Filter silently. Your gateway logs "sent," but the messages never arrive and you get no error.
2. Suspend the SIM. That number is gone, along with every conversation and reply history attached to it.
3. Block content patterns. Links, shorteners and repeated wording get filtered across every SIM sending them, so swapping SIMs doesn't help.

Unregistered business traffic gets carrier-filtered on long codes as a matter of policy. That's the reason registration exists, and it's covered in 10DLC enforcement, fines and blocking. A modem pool has no way to register. A SIM on a consumer plan can't sit on a 10DLC campaign, so there is no compliant path to scale it.

The losses are hard to plan around. A suspended SIM means losing a number customers recognize, plus the time to rebuild your sending capacity. Neither shows up on a per-message cost sheet.

Compliance: what you would have to build yourself

Every bulk sender carries the same TCPA obligations no matter what hardware they use. Statutory damages commonly cited run $500 to $1,500 per text. With a modem pool, you build all of the following yourself:

Two caveats. First, Ready's attestation log records who sent, to how many people and when. It does not store each recipient's opt-in time, wording or source page, so your own store still needs to keep that. Second, these tools reduce risk. They don't make you immune. Compliance remains the sender's responsibility, and SMS should go to people who consented or replied to you first. Cold outreach belongs on phone and mail.

What sending actually looks like on an API

With a modem setup, you maintain AT-command scripts, modem health checks and SIM rotation. With an API, a bulk send to up to 100 recipients is a single request:

POST https://api.tryready.com/v1/messages/bulk
X-API-Key: <key>
Idempotency-Key: 6f1c2a9e-3b7d-4e1a-9c55-2d8f0b7e4a11

{
  "to": ["+12125550199", "+15559876543"],
  "body": "Your appointment is tomorrow at 9 AM. Reply C to confirm or STOP to opt out.",
  "consent_attested": true
}

Lists larger than 100 get split into batches. The idempotency key means a retried request after a network timeout won't double-send, which is a common source of duplicates in homemade gateways. Opted-out and numbers on your Ban list are refused up front and not charged. A text that lands in a recipient's quiet hours is held only if the window opens within 6 hours, and is charged only when it sends; otherwise the call is refused with 409 QUIET_HOURS_BLOCK and you send it again once the window opens. Full reference: bulk messages docs and the quickstart.

For platforms that text on behalf of their own customers, each customer gets a sub-account with its own numbers and its own 10DLC registration. A modem pool can't offer that kind of per-customer isolation at all. The 10DLC registration API post covers how that works.

Cost, done honestly

Ready's Standard rate is $0.0075 per segment, plus a $0.0045 carrier fee per segment. That all-in figure excludes the optional compliance surcharge: scrubbing and landline validation each add $0.003 per segment when switched on. Registration costs $25/mo and $2/mo per number, and the first month ($25) is charged when you submit.

Worked example: 5,000 contacts, a 175-character appointment notice with one emoji. The emoji forces unicode encoding, so the message splits into 67-character segments: 175 ÷ 67 rounds up to 3 segments.

• 5,000 × 3 = 15,000 segments
• 15,000 × $0.0075 = $113, plus 15,000 × $0.0045 in carrier fees
• Remove the emoji and the message drops to 2 GSM segments (153 characters each): 10,000 segments, or $75 plus 10,000 × $0.0045

Editing the message saves more than any hardware hack would. For a full breakdown, see bulk SMS cost per message.

On price comparisons: a modem pool's marginal cost per text is close to zero until the SIM is banned. Raw CPaaS APIs also come in under our rate. Twilio lists about $0.0083 per segment, and GoHighLevel/LeadConnector runs about $0.0083 per message (around $0.0128 all-in). If you have engineers to build registration flows, STOP handling, quiet hours and scrubbing yourself, Twilio or Telnyx is a reasonable choice. What we sell is having those pieces already built: self-serve registration, compliance controls, an inbox, campaigns and a GoHighLevel integration in one product.

Which one fits

• Modem pool or phone app: only for genuine one-to-one texting at personal volumes. Using one for bulk business messaging violates SIM terms and can't be registered.
• Open-source gateway: useful as a queueing layer in front of a registered API. Running it in front of SIMs leaves you with the same P2P route and the same risks.
• Raw CPaaS: lowest per-segment price. The right pick if you'd rather build compliance yourself.
• Ready: the right pick if you want registered routes plus the compliance stack included, and you're paying for that time saved, not for a lower rate.

The practical takeaway

The hardware route doesn't fail because modems are slow. It fails because consumer SIMs can't legally carry A2P traffic, so a growing modem pool means growing ban risk with no option to register. If you're sending to thousands of opted-in people, a registered route is the only setup that holds up over time, and it costs you an API call instead of a rack of modems.

If you want to try Ready, sign up, add a card and use your first 20 free one-to-one texts to check delivery before you register. Most approvals take 2 to 7 days. For more on how high-volume sending works, see how bulk SMS works for US businesses.