Short answer: choose the least complicated SMS API that leaves a verifiable trail from sender registration to delivery receipt, then keep the report-generation decision in your property-management app. Per-message price matters, but a missing receipt at 3am costs more than a small rate difference.
The page that wakes me is rarely “send failed.” It is usually “the weekly rent report was generated, but nobody can prove the tenant alert went out.” A dashboard can show green while an on-call engineer is staring at an empty delivery record. The useful question is: what evidence would let us reconstruct this alert without guessing?
What should a startup app record before sending a US/EU SMS alert?
Start before the API call. For a property manager's generated report, create an immutable notification record with the report ID, recipient account, normalized phone number, destination country, consent or operational reason, template revision, and a unique alert ID. Store the intended channel and fallback policy too. If the report is delivered as an email attachment, the SMS should point to an authenticated report page; an SMS body is not an attachment channel.
That record is the join key for every later event. A timeout is not proof that the carrier did nothing, so a retry must reuse the alert ID and preserve the first attempt's timestamp. The worker can then distinguish a new notification from a repeated request. Keep the provider message ID, when returned, in the same row.
Keep it boring.
Sender registration belongs in this preflight path. US long-code campaigns, toll-free numbers, short codes, and EU sender identities have different review and branding rules; the exact requirement depends on country and traffic type. Treat registration state as data with an owner and an expiry check. Do not discover it by trial-sending a tenant's real report.
I once investigated a “late report” page that turned out to be a registration mismatch. The app had stored a phone number and a successful HTTP response, but not the sender identity or country decision. The receipt poller kept asking about a message that the incident record could not connect to the report. We reconstructed it by matching a provider ID in a log line, then changed the schema so a send is impossible without the alert ID, sender profile, policy version, and report checksum. The fix was paperwork in the database, not a faster retry loop. That change also forced us to preserve the original report checksum when a manager regenerated a PDF, because otherwise a valid receipt could be attached to the wrong document. During the next review we compared the generated timestamp, the signed-link subject, and the carrier message ID in one query; the extra columns looked fussy until an auditor asked why two tenants had received the same filename. I still distrust a green dashboard when those three values cannot be joined.
How should a startup app choose an SMS alert service alternative for US/EU delivery?
Polling is a control loop, not a sleep statement. After send, persist pending and a next-poll time. Use bounded backoff, a maximum age, and a terminal-state map. “Unknown after deadline” should page a review queue; it should not be silently converted to delivered.
package delivery
import (
"context"
"time"
)
type State string
const (
Pending State = "pending"
Delivered State = "delivered"
Failed State = "failed"
Unknown State = "unknown"
)
type Receipt struct {
State State
Observed time.Time
MessageID string
}
func NextPoll(now, created time.Time, attempts int, last Receipt) (time.Time, State) {
if last.State == Delivered || last.State == Failed {
return now, last.State
}
if now.Sub(created) >= 30*time.Minute {
return now, Unknown
}
delay := time.Duration(1<<min(attempts, 5)) * time.Minute
return now.Add(delay), Pending
}
func min(a, b int) int {
if a < b {
return a
}
return b
}
func Poll(ctx context.Context, next time.Time, get func(context.Context) (Receipt, error)) (Receipt, error) {
timer := time.NewTimer(time.Until(next))
defer timer.Stop()
select {
case <-ctx.Done():
return Receipt{}, ctx.Err()
case <-timer.C:
return get(ctx)
}
}
The thirty-minute bound is an example policy, not a carrier promise. Set it from your report's business deadline and measure the result. Your mileage may vary across destination countries and contracts. The important invariant is that every poll writes an observation, including an unchanged one, so an incident review can tell whether the worker ran.
Add two alerts before production: a rise in unknown receipts and a gap between generated reports and attempted notifications. A provider “accepted” response is an intermediate fact. It should never close the incident by itself.
That is the whole test.
What does a fair SMS service comparison include besides per-message cost?
Use a test ledger with the same cases for every candidate: an unregistered sender, a suppressed number, a valid US destination, a valid EU destination, a transient client timeout, and a receipt that stays pending. Record the API response, message ID, receipt transition, poll count, and operator action. This is an incident rehearsal disguised as procurement, which is exactly why it is useful.
| Evidence to compare | Why it matters | Failure to watch |
|---|---|---|
| Sender registration workflow | Determines whether traffic can start legally and predictably | Approval state is kept in a ticket, not linked to code or country |
| Per-message billing record | Reconciles report volume with attempted sends | Segments turn one long message into multiple billable units |
| Delivery receipts | Separates accepted, delivered, and failed states | A dashboard hides pending or expired records |
| Polling interface and limits | Defines worker load and time-to-detection | Polls continue after a report deadline |
| US/EU policy controls | Prevents accidental cross-border or unconsented sends | Country normalization happens after the send |
SMS length is part of that cost and reliability test. GSM-7 and UCS-2 encoding change segment limits, and a single non-GSM character can turn a message into more segments; the character and segmentation rules are documented by Twilio's glossary. Keep the alert short and put the report details behind a signed link. Never assume “one message” means one segment.
The cheapest quote is therefore incomplete. Count registration labor, polling requests, retries, number rental, audit storage, and the engineer-hours needed to explain a disputed alert. I would not promise a savings percentage without your traffic and country mix; any such number would be guesswork. A service that charges less per message can be the wrong choice if it gives you no durable receipt ID or makes country-level sender policy impossible to audit.
When is a simple polling design the wrong choice?
A pull-only receipt model is fine for a startup that sends a few report alerts and can tolerate minute-level detection. The catch is that it is not suitable when a delivery event must fan out immediately to voice, chat, or a second SMS provider. Choose a service with webhooks or an event stream when that timing is a hard requirement, and budget for signature validation, replay handling, and another operational surface. Stick with a specialist messaging service when those event semantics or sender-registration controls are the product requirement; choose the simpler polling boundary only when your report deadline and staffing can absorb it.
Likewise, do not use SMS as the report transport. Keep the generated attachment in an email or authenticated document system, then make SMS a narrowly scoped pointer and escalation channel. If a tenant cannot access the link, the incident is an access-control problem, not evidence that another SMS retry will help.
The conclusion I trust is a decision rule, not a brand: select the service whose registration records, per-message accounting, receipt states, and polling limits you can join to one alert ID and review after an incident. Price is one column in that ledger. Delivery evidence is the part that lets you sleep.
References
- https://docs.aws.amazon.com/ses/latest/dg/Welcome.html
- https://www.twilio.com/docs/glossary/what-sms-character-limit
- https://www.rfc-editor.org/rfc/rfc5322
- https://pages.nist.gov/800-63-3/sp800-63b.html
Top comments (0)