Every SaaS product reaches the same inflection point. Messaging starts as a line item inside a provider invoice, then becomes a line item inside your gross margin, and then becomes a board question. The moment your customers send more messages than you forecast is the moment a per-message price stops being convenient and starts being a constraint on your pricing model.
Owning the messaging layer changes that equation, but it also moves a set of responsibilities onto your platform team: tenant isolation, quota enforcement, metering, and the operational burden of hardware that must keep working. This guide covers those four responsibilities in the order they appear in a build, using the published SK-SMS Gateway configurations as the capacity ladder.
At what volume does an SMS gateway for SaaS platforms beat per-message pricing?
When your per-message spend exceeds the hardware cost.
The comparison is a fixed capital cost against a variable rate, so the crossover depends on the rate quoted to you and the volume your tenants actually send.
The arithmetic is deliberately simple, which is why it is worth doing before any architecture discussion. Take the list price of the gateway you would need, divide it by your blended quoted rate per message, and you have the number of messages after which the hardware has paid for itself. Add the ongoing costs you would not have paid before — rack space or hosting, power, SIM inventory, and engineering time — and the real crossover moves later.
Two structural details matter more than the crossover point itself. First, the hardware cost is one-off while the message cost recurs, so the comparison improves with volume and deteriorates with churn; a platform whose tenants send in bursts will not amortise the hardware as smoothly as the arithmetic suggests. Second, a self-hosted gateway gives you a fixed cost per message that you control, which is what makes per-seat or unlimited pricing models defensible to a finance team.
| Model | Ports | SIM slots | List price (USD) | Messages to recover cost |
|---|---|---|---|---|
| SK-SMS Gateway 4-4 | 4 | 4 | $238.00 | List price ÷ your blended rate |
| SK-SMS Gateway 8-8 | 8 | 8 | $355.00 | List price ÷ your blended rate |
| SK-SMS Gateway 16-16 | 16 | 16 | $645.00 | List price ÷ your blended rate |
| SK-SMS Gateway 16-512 | 16 | 512 | $1,160.00 | List price ÷ your blended rate |
| SK-SMS Gateway 64-512 | 64 | 512 | $2,480.00 | List price ÷ your blended rate |
Worked example, using a rate you must substitute with your own quote: at a blended rate of USD 0.01 per message, the SK-SMS Gateway 4-4 at $238.00 recovers its purchase price after 23,800 messages, and the SK-SMS Gateway 16-16 at $645.00 after 64,500. Change the rate and the volumes change proportionally; the tables above therefore state the formula rather than a result, because your negotiated rate is the only input that matters.
Before you accept the crossover, subtract the costs you are about to inherit. Rack or hosting space, power, SIM acquisition, spare units, and the engineering time to build metering and routing are all real, and none of them appear on a provider invoice.
How do you isolate SIM resources between tenants?
Partition by hardware only where the contract demands it.
Three models cover most SaaS deployments, and the right one follows from what you promise customers rather than from what is cheapest per port.
Shared pool with logical partitioning. All tenants draw from one SIM estate, and the platform assigns channels by policy at send time. It is the most efficient use of hardware and the easiest to operate, and it is appropriate when tenants buy a service rather than a dedicated resource. Its weakness is that isolation is a software property: a bug in the assignment logic becomes a cross-tenant incident.
Dedicated slots per tenant. A defined subset of SIM slots is bound to a tenant and never shared. This suits contracts that specify dedicated numbers, and it makes capacity conversations concrete because the tenant’s ceiling is visible in the console. The cost is stranded capacity when a tenant underuses its allocation.
Dedicated hardware per tenant. Separate devices for separate customers. This is the strongest isolation and the simplest to explain in a security review, and it is justified when a tenant’s traffic must be physically separated or when their volume supports an entire unit.
Whichever model you choose, decide early where the tenant boundary is enforced. Enforcing it in the application is flexible and fast to change; enforcing it in the console is verifiable and survives application bugs. Most mature deployments do both, because the cost of redundancy here is far lower than the cost of a cross-tenant message.
How do you stop one tenant from saturating a shared channel?
Enforce a quota at the channel, not at the API.
A rate limit in your application protects against a runaway job; it does not stop a tenant whose legitimate traffic fills the queue while another waits.
Both requests in that scenario are perfectly valid, which is why the problem has to be solved where the channels are rather than where the requests enter.
Three mechanisms work together. Per-tenant concurrency caps limit how many channels a tenant may occupy simultaneously, which bounds the worst case without capping total volume. Weighted queuing gives each tenant a share of the outbound queue rather than first-come-first-served access, so a large tenant cannot monopolise capacity by sending more. Backpressure signalling tells the application when the queue is saturated so it can defer or shed work deliberately rather than discovering the problem through timeouts.
The design question to settle in writing is what happens at the limit. Options are queuing with a delivery-time guarantee, rejection with a clear error the application can surface, or degradation to a slower path. What you must avoid is silent waiting, because a message that sits in a queue for longer than your published delivery window is a support ticket that looks like an outage.
Where messages carry authentication codes, timing is not a preference but a correctness requirement. The authentication guidance in NIST SP 800-63B treats out-of-band delivery as time-bounded, which means a code that arrives after the window has expired is a failed authentication rather than a delayed message; your queue policy should reflect that difference explicitly.
How do gateway logs become a tenant invoice?
One immutable event per message, keyed at submission.
Metering fails for a predictable reason: tenant attribution happens at the end of the pipeline, where the information needed to attribute the message has already been discarded.
Fixing attribution at submission is far cheaper than reconstructing it during a billing dispute.
Design the record so it can serve three purposes at once. For billing, it needs the tenant identifier, the message count, and the direction, since many pricing models charge differently for inbound and outbound. For operations, it needs the delivery state, the carrier latency and the retry count that the device log already carries for each message. For support, it needs enough identity to answer a customer question without exposing another tenant’s traffic.
The export path deserves as much attention as the record itself. A device that exports a flat log on demand turns billing into a manual process; a device whose log exports in a machine-readable form on a schedule lets you treat metering as a data pipeline. Keep the reconciliation step explicit: the count you bill against should be derived from the same event stream you use for delivery reporting, so that a discrepancy has one place to be investigated rather than two.
Retention follows from the same decision. Billing typically needs a longer window than operations, and both need longer than the device can hold, so the platform’s storage — not the gateway’s console — is the system of record for anything that has to survive a hardware replacement.
What does white-label messaging require beyond hardware?
Sender identity, consent records and an audit trail.
White-label messaging is often framed as a branding exercise, but the branding is the easy part. The durable requirements are the ones a customer or a regulator can ask you to demonstrate after the fact.
Sender identity has to be coherent from the recipient’s point of view: the name that appears on a message should match the brand the recipient recognises, in every market you serve. Where sender registration applies, it applies to the entity sending the traffic, which is a commercial and legal decision rather than a device setting.
Consent records are the obligation most often underestimated. A SaaS platform typically sits between a business customer and that customer’s end users, so the platform needs both the customer’s attestation that consent exists and a way to honour an opt-out without delay. Industry practice guidance from M3AAWG and the market rules published by bodies such as the CTIA are the practical reference points for how those obligations are normally expressed.
Audit trail is what turns the previous two from promises into evidence. Being able to answer “who sent this, on whose behalf, with what consent, and when” from a single record is the capability that survives a customer audit, a carrier investigation, or an enterprise security review. If your gateway log exports cleanly, most of that trail already exists.
One boundary is worth drawing explicitly: your platform’s contractual position with its own customers does not transfer the end user’s consent to you. The attestation chain has to be documented, because the party that will be asked to explain it is the one operating the infrastructure.
How should a SaaS platform plan for messaging availability?
Match redundancy to the delivery window you publish.
Messaging availability is a delivery commitment rather than an uptime figure, so the relevant failure is messages accumulating while the gateway is down.
Single unit with a spare covers hardware failure with a manual, minutes-long intervention. It is appropriate when a short queueing window is acceptable and the spare is genuinely on site with a current configuration backup.
Dual units in one location removes the intervention step, at the cost of running two estates and keeping the SIM inventory synchronised. This is the common shape for platforms with a published delivery window measured in minutes.
Two locations adds resilience against a site-level failure such as a network outage or a power event. It also multiplies the operating complexity, because SIM registration, carrier coverage and message routing now vary by site.
The decisive question is what happens to a message submitted during a failure. If the application can hold it, a single unit plus a spare may be sufficient. If it cannot, the platform needs at least two live paths, because the queue has to exist somewhere even when the primary device does not.
Whichever model you choose, define the failure behaviour rather than leaving it implicit. Deciding whether the platform queues, rejects or reroutes under failure is the difference between a documented degradation and an incident that surprises your support team.
What is the scaling path from 4 ports to 64?
Buy the SIM ratio before the port count.
Ports set how many channels transmit at once; slots set how many numbers you can distribute traffic across. A strict per-number policy exhausts slots first.
| Stage | Model | Ports | SIM slots | List price (USD) |
|---|---|---|---|---|
| Validate the stack | SK-SMS Gateway 4-4 | 4 | 4 | $238.00 |
| First tenants | SK-SMS Gateway 8-32 | 8 | 32 | $450.00 |
| Growth | SK-SMS Gateway 16-64 | 16 | 64 | $800.00 |
| Scale | SK-SMS Gateway 32-256 | 32 | 256 | $1,490.00 |
| Density | SK-SMS Gateway 64-512 | 64 | 512 | $2,480.00 |
| Density, eSIM | SK-SMS Gateway-64E-SIM | 64 | 64, eSIM | $4,080.00 |
The eSIM variants deserve a separate look because they change the operational model rather than the capacity. Removing physical SIM handling is particularly relevant to a SaaS platform expanding across markets, where the cost of obtaining, shipping and swapping physical cards can exceed the hardware cost of the additional slots. For platforms that expect to operate in several countries, the SK-SMS Gateway 16-512 and the eSIM models are worth comparing against the same deployment plan, since the trade is not only price but the amount of logistics your team absorbs.
Whichever path you take, keep the application insulated from the model. If the platform addresses a logical pool and your configuration maps that pool onto physical slots, adding a second device is a configuration change rather than a code change — and that insulation is what makes the scaling path above optional rather than mandatory.
When is a cloud API still the right answer?
When volume is spiky or your team cannot operate hardware.
Self-hosting is a commitment, and it is the wrong one in three recognisable situations: genuinely spiky demand, broad reach at low volume, and a team with no operational owner.
The first case leaves a fixed estate idle for most of the year while still requiring maintenance. The second is broad geographic reach at low volume, where the administrative cost of SIM inventory in many markets exceeds any per-message saving. The third is a small team with no operational owner for infrastructure, where a device that nobody monitors is worse than a provider that somebody else does.
The NIST SP 800-145 definition of cloud computing is a useful vocabulary here, because it makes the trade explicit: measured service and rapid elasticity are the provider’s responsibilities, and on-premise infrastructure trades those properties for control and a predictable unit cost. If your pricing model depends on the latter, the trade is worth making. If your product roadmap depends on the former, it is not.
Market data is worth consulting before committing to a build, because the picture differs sharply by region and the difference affects where local infrastructure pays off. The ITU-D statistics programme publishes international connectivity and mobile data that are relevant to those decisions, and the MEF publishes material on the service side of the same industry. Neither substitutes for your own measurements, but both are more useful inputs than a vendor comparison table.
What the two models share is the delivery window. Whether you send through a provider or through your own hardware, the commitment that matters to your customers is how long a message may wait, and that commitment should be documented before the architecture is chosen rather than after.
Conclusion
Moving from per-message pricing to owned hardware is a fixed-versus-variable trade, and the crossover is arithmetic you can do today with the published list prices and the blended rate in your current provider contract. What changes with the choice is not only cost but risk: tenant isolation, quota enforcement, metering and consent evidence all move onto your platform team, and each of them is cheaper to design at the start than to retrofit.
Three decisions carry most of the outcome. Decide where the tenant boundary is enforced, because that is what makes a shared estate safe. Decide that attribution happens at submission, because that is what makes metering survivable. Decide which redundancy model matches the delivery window you publish, because that determines whether a device failure is a queue or an outage. With those settled, the hardware selection is straightforward: choose the SIM-to-port ratio your traffic policy requires, and let the published ladder from the SK-SMS Gateway 4-4 at $238.00 to the SK-SMS Gateway-64E-SIM at $4,080.00 define the capacity steps.
Model the crossover against your own quoted rate. Send your monthly message volume, tenant count and the blended rate you pay today to service@telarvo.com, or review the published capacity steps on the SMS gateway solution pages.
FAQ
How much does an SMS gateway cost compared with a cloud API?
The hardware is a known one-off cost and the API is a recurring one, so the honest comparison is break-even volume rather than headline price. Divide the list price of the model you need by your blended rate per message to get the volume at which the gateway is paid for. Then add the costs you inherit, including hosting, power, SIM inventory, spares and engineering time, and check whether the crossover still falls inside your planning horizon.
Can several SaaS tenants share one gateway safely?
They can, provided the tenant boundary is enforced in two places rather than one. Enforce it in the application so that assignment logic can evolve quickly, and in the device console so that an application defect cannot produce a cross-tenant message. Deployments that enforce the boundary only in software tend to discover the gap during an incident rather than during a review.
Do we need a separate gateway for each tenant?
Usually not. Dedicated hardware is justified when a contract requires physical separation, when a tenant’s security review demands it, or when their volume fills a unit on its own. Otherwise dedicated SIM slots per tenant deliver most of the practical isolation at a fraction of the cost, as long as the slot allocation is visible and enforceable rather than implicit.
Is there a free SMS API that a SaaS platform can build on?
Free tiers exist for development and low-volume testing, but they carry conditions that matter in production, including throughput limits, sender identity restrictions, and terms that change without notice. Treat any no-cost option as a prototyping path. Before launch you need a sender identity you control, documented consent from the end user, and a delivery path whose capacity you can state to your own customers.