The pitch looks good on paper. You grab an open-source gateway app from GitHub, put it on a spare Android phone with an unlimited-text plan, and point your CRM at its local API. Or you buy a USB GSM modem, or a box that holds eight SIM cards, and wire it into a script. You get a few hundred texts out for the cost of a phone plan and no registration paperwork.
This setup breaks once you use it for real business texting. The failures are predictable: carriers filter the traffic or cut off the line, the hardware is slow, and every compliance job a messaging platform normally handles becomes your code or your liability. This post covers each limit with numbers, says when a DIY gateway is actually fine, and shows what the registered alternative costs.
How DIY SMS gateways work
There are two common builds:
- Android phone gateway. An app turns the phone into a small HTTP server. Your software sends a request, and the app hands the message to Android's SMS system, which sends it over the SIM like any personal text. Replies come back through the same app as webhooks.
- GSM modem or SIM bank. A USB modem or a multi-SIM box takes AT commands from a server. You load consumer or prepaid SIMs and rotate between them to spread the volume.
Both send application-to-person (A2P) traffic over person-to-person (P2P) lines. Nearly every risk below comes from that mismatch. For the general mechanics of gateways, see our post on how SMS gateways work and why not to build your own.
Carrier blocking: your SIM is a person's phone line
US carriers split business texting from personal texting. Business texts from ordinary 10-digit numbers are expected to run on registered A2P 10DLC routes, where a brand and a campaign are on file with the carriers. (Our 10DLC explainer covers the basics.) A consumer SIM has no registration. As far as the network can tell, it belongs to one person texting friends.
Carriers watch for traffic that doesn't match that profile:
- Hundreds of distinct recipients a day from one line
- The same or near-identical message body sent repeatedly
- A steady, machine-like send rate
- Few replies compared with sends
When a line looks like this, the usual results are silent filtering (the API says "sent," but nothing arrives), delivery failures, or suspension of the SIM. Consumer plan terms generally prohibit automated or commercial bulk messaging, so the carrier doesn't need much reason to shut a line down. SIM banks that rotate cards are what carrier SIM-farm detection is built to catch, so rotation tends to make you more visible.
Silent filtering hurts most. Your gateway app reports success, your CRM marks the message delivered, and you only find out from customers who never got the appointment reminder. For the bigger picture on unregistered sending, see 10DLC enforcement, fines and blocking.
Throughput: the math rarely works
A phone was never designed to be a message server. Android has a built-in check on apps sending SMS, and by default it prompts the user after roughly 30 messages in 30 minutes. Gateway apps get around it with root access or settings changes. Battery, heat, sleep modes and OS updates all interrupt sending.
Here is an example with stated assumptions. Say you have a 5,000-contact list of opted-in customers and the phone manages one text every 3 seconds, which is generous for a phone that also has to avoid looking automated:
- 5,000 texts × 3 seconds = 15,000 seconds, a bit over 4 hours
- That only holds if the carrier doesn't flag the line partway through, which at that volume is likely
On a registered route, a fresh standard campaign with no vetting typically gets about 1 to 4 segments per second. These are carrier figures, not a published rate card. At an assumed 2 segments per second, the same 5,000 single-segment texts take about 42 minutes. On T-Mobile, daily brand caps also apply by trust score (roughly ~2,000 to ~200,000 messages a day, lowest trust first). Those caps are known in advance and can be planned around. A suspended SIM can't.
Consent, STOP and quiet hours become your code
A DIY gateway sends whatever you give it, whenever you give it. That means you have to build or manage all of the following yourself:
- Opt-out handling. When someone replies STOP, every future send to that number has to be blocked, across every list and script. If one cron job misses it, you've texted someone who opted out.
- Quiet hours. The gateway sends at 3 AM if your script runs at 3 AM. You need logic based on each recipient's local time.
- Litigator and DNC screening. No list hygiene is done unless you add it.
- Consent records. You need proof that each recipient agreed, and you need it before you send.
These protections matter because the TCPA allows $500 to $1,500 per text in statutory damages. One bad send to a few hundred people can cost more than years of messaging fees. No platform makes you immune either, because compliance is always the sender's responsibility. Still, a gateway that has no guardrails at all puts every mistake on you. For the records side, see how to document SMS consent so it holds up.
DIY vs registered: side by side
| Android phone gateway | GSM modem / SIM bank | Registered 10DLC platform | |
|---|---|---|---|
| Carrier registration | None | None | Brand + campaign on file |
| Filtering / suspension risk | High at business volume | High, rotation is a red flag | Low on registered routes |
| Practical throughput | A few texts per minute | Somewhat more, per SIM | ~1 to 4 seg/sec fresh, more with higher tiers |
| STOP handling | You build it | You build it | Built in |
| Quiet hours | You build it | You build it | Built in |
| Delivery visibility | "Sent" often means nothing | Same | Carrier delivery status |
| Upfront cost | Phone + plan | Hardware + SIMs | Registration + per segment |
What the compliant path costs
We make Ready, so here are our own numbers. For a platform or small team, Standard is $0.0075 per segment plus a $0.0045 carrier fee, at the same rate for sent and received segments. That rate doesn't include the optional compliance surcharge: TCPA/DNC scrubbing and landline validation are $0.003 extra per segment each when you switch them on, and both are off by default.
Registration has no setup fee. You pay the first month, $25, when you submit. After that the monthly cost is $25/mo for registration + $2/mo per number. Most approvals take 2 to 7 days.
Back to the 5,000-contact example, with a 140-character plain-text message (one GSM-7 segment, so no emoji):
- 5,000 × $0.0075 = $38, plus 5,000 × $0.0045 in carrier fees
- Plus the $25 first registration month and $2 for the number
If you add an emoji, the segment limit drops to 70 characters and that same message becomes 3 segments, which triples the cost. Write in plain text unless the emoji is worth paying for.
To be honest about price: raw CPaaS APIs like Twilio (around $0.0083 per segment) and GoHighLevel's LeadConnector cost less per message. If you have engineers who can build registration, opt-outs, quiet hours and an inbox, those are reasonable choices. Ready's value is that self-serve registration, STOP handling, quiet-hours holds, scrubbing and webhooks are already built. Our post on open-source gateways vs a managed API goes through the build-vs-buy decision in more detail.
When a DIY phone gateway is actually fine
Some uses don't need a registered route:
- Internal alerts to your own team. A server pinging three engineers' phones is low-volume, consented, and not marketing.
- Personal automation. Texting yourself reminders.
- Prototyping. Testing a flow before you commit to a provider.
The deciding factor is who receives the texts. Once you're sending to customers, leads or patients, especially more than a few dozen a day, you're in A2P territory and the risks above apply.
Moving off the phone
If you already have a gateway running, switching is mostly a change in where your code sends requests. On Ready, one text looks like this:
curl -X POST https://api.tryready.com/v1/messages \
-H "X-API-Key: $READY_API_KEY" \
-H "Idempotency-Key: 7d3e2f4a-1b9c-4e8f-a2d1-5c6b7e8f9a01" \
-H "Content-Type: application/json" \
-d '{"to": "+12125550199", "body": "Your appointment is tomorrow at 10 AM. Reply STOP to opt out.", "consent_attested": true}'consent_attested is your statement that this recipient agreed to texts. Ready records that attestation per send (who sent, to how many, when) as an audit trail. It does not store the recipient's opt-in wording, time or page URL, so your form or store has to keep those records. Numbers that have opted out are refused before sending and you aren't charged. An API text sent during the recipient's quiet hours is held only if the window opens within 6 hours; otherwise it is refused and your system has to resend it. A held text is charged only when it actually goes out. Lists go through POST /v1/messages/bulk, with up to 100 recipients per call. Details are in the messages API docs and the quickstart.
You can start before your registration is approved. The first 20 texts are free one-to-one sends, so use them before you register, because they end once a registration is paid for. An account can send up to 500 texts a month before registering, at its normal rate. To send, you add a card and get a number, which is $2 a month with the first month charged when you get it.
The practical takeaway
An Android phone or GSM modem works for texting yourself or your team. For business messaging it means sending A2P traffic over P2P lines that carriers are built to filter, at a few texts per minute, with no STOP handling, quiet hours or consent trail unless you write them yourself. The cheapest per-message setup can end up being the most expensive once you count filtered sends and TCPA exposure.
If you're sending to customers, register a brand and campaign, send through an API that enforces opt-outs and quiet hours, and keep your consent records. Check the pricing against your own volume, and sign up when you're ready to test a few real sends.