Smppcube vs single-tenant gateways (NowSMS / Ozeki class)

This is a comparison we lose regularly, and we are at peace with that. Single-tenant gateways like NowSMS and Ozeki are good software. They install in an afternoon, they hold binds, they have an interface a human can actually use, and their vendors answer email. For the job they were designed for they are frequently a better buy than we are, and we will name that job precisely: one organisation sending its own messages. The ground shifts the moment a second company’s money starts moving through your server, and it shifts in a way a feature checklist tends to hide rather than reveal, because the checkbox that matters says “multi-user” and you read it as “multi-tenant”. Below: what this class genuinely does well, the exact place its design stops, a side-by-side grid, honest numbers, and the four cases where you should buy one of them instead of us.

What single-tenant gateways are genuinely good at

Start with the credit, because it is real. Compared with a raw bearer, this class already solved the two problems that make open source expensive to run as a business: there is a graphical interface, and there is a vendor with a support address. That is not a small thing. It is the difference between a project and a product, and it is why these companies have been in business for twenty years while a hundred gateway startups have not.

NowSMS. Now Wireless’s gateway has a long track record and an unusual specialism: it is genuinely strong on MMS and MM7, not just SMS, which is a corner of the market most modern platforms quietly abandoned. It speaks SMPP as a client and as a server, drives GSM modems, has a web configuration interface, and is documented properly by people who clearly know the protocols. If your requirement contains the letters MMS, it belongs on your shortlist and probably at the top of it.

Ozeki. Ozeki’s SMS Gateway is the browser-GUI end of this class: a long list of connections on the network side (SMPP, HTTP, modems) and, more distinctively, a long list of connectors on the application side, into databases, files, email and line-of-business systems. Routing rules, users, applications. For an enterprise that wants “our ERP sends SMS and IT owns the box”, it is a tidy answer and it installs on Windows without an argument, which for a lot of IT departments settles the matter before the feature grid opens.

The class in general. Diafaan, appliance vendors, and a handful of others sit in the same shape: buy a licence per server, install, configure routes, send. Their design centre is an enterprise IT department or a single carrier department, and inside that centre they are efficient, well supported and hard to beat on time-to-first-message. Nothing below is a criticism of the engineering. It is a statement about where the product boundary was drawn, deliberately, twenty years ago.

The word “tenant” is doing all the work here

Every product in this class supports more than one user, and every evaluation runs aground on that sentence. So let us be exact about the difference, because it is the whole article.

A user is a seat. A login, a permission, maybe a throughput cap and a route it is allowed to touch. It exists so that four departments in one company do not share a password. Everything a user does is ultimately your organisation’s activity, on your organisation’s account, paid for by your organisation, reported in your organisation’s numbers.

A tenant is a business you do not own. It has a balance you have to defend, a rate card that differs by route and destination from every other tenant’s, sub-users it creates itself without ever seeing yours, a portal on its own domain with its own logo, a delivery report it reads without calling you, an invoice at the end of the month, and a suspension switch you can pull without touching anyone else. Its data must be isolated so completely that a bug cannot leak its contact list into a neighbour’s export, because that phone call ends a client relationship permanently.

Here is the practical test, and it takes ninety seconds with any vendor’s documentation. Ask, in this order: can a user hold a credit balance that is enforced before send? Can that user have a different price than the user next to them, per route and per destination? Can that user create their own sub-users? Does the login page carry their logo, on their domain? Does the system produce an invoice? Can I suspend one and only one of them? If any answer is no, you have a multi-user gateway. That is not a defect. It is simply not a platform you can run a reseller business on, and the sooner that is on the table the cheaper the evaluation gets.

The comparison, side by side

	NowSMS / Ozeki class	Smppcube v9
Time to first message	Hours	Hours, guided install
Admin GUI	Yes, good	Full web GUI
SMPP binds to SMSCs	Yes	Kannel, inside the stack
SMPP server, clients bind to you	Yes, on most	Yes, on port 2775
GSM modems, MMS, MM7	Strong, a real advantage	Not our focus
Users	Seats and applications, one organisation	Admin, staff, reseller, client
Reseller tree, clients under clients	No	Yes, with isolation
Rate card per client, route and destination	No	Yes
Credit enforcement before send	No	Credit, wallet and auto routes
Invoicing	No	Prepaid, postpaid, recurring, multi-currency
White-label portal per client	No	Per tenant, own logo and domain
Client-readable reports	Admin level	Per tenant dashboards and exports
WhatsApp, RCS, voice	Varies, mostly no	In the same platform
Licence shape	Per server, per capacity tier, often with annual maintenance	6,400 USD once, perpetual
Second node, DR or second country	Another licence	Same licence
Source code	No	Delivered
Support	Vendor	Vendor, with an SLA

Read the grid in two halves. The top half, the telecom half, is a tie, and on the modem and MMS rows they beat us outright. Then look at the row where the word client first appears, and notice that everything below it changes character at once. That is not a coincidence and it is not a to-do list the vendors forgot. It is the product boundary, drawn where the design centre sits: an IT department that has no clients, so it needs no rate cards, no portals and no invoices.

What you end up building beside it, with a price on each

Here is the difference that matters most, and it is not on any feature grid. With open source you can extend the thing itself. With a closed-source single-tenant gateway you cannot. So the business layer does not get built on top of the gateway, it gets built beside it: a second application that owns clients, balances, rates, portals and invoices, and drives the gateway through its HTTP API. Same project, minus the bearer work, plus a seam.

Tenancy and isolation. About 1 to 2 developer-months. Accounts, a reseller tree, permission groups, isolation of contacts, campaigns and sender IDs, a suspension switch with a blast radius of exactly one client. It reads like a fortnight of CRUD until the export bug, which you get to make one phone call about, once.

Billing and the ledger. About 3 to 6 developer-months, and this is where the project dies. Reserve credit before the send, price by the route actually taken, refund on a hard failure and not on a soft one, make every operation idempotent so a retry never double-charges, run prepaid and postpaid side by side, handle currencies, and produce an invoice a finance department accepts. Our billing models guide walks the ledger discipline. The first version takes a month and looks finished. The version that survives a client disputing a 50.00 USD line takes six.

White-label portals and client reports. About 2 to 3 developer-months. A branded panel per tenant: compose, upload a list, check a balance, pull a delivery report, download an invoice. Plus turning raw delivery receipts into something a client filters and understands without ringing you. This is the surface your clients touch daily, so it cannot look like an internal tool, and internal tools are exactly what a fast build produces.

The seam. Small to write, permanent to own. Your ledger lives in your application; the messages live in a gateway that has never heard of your clients. So you carry a mapping between your message IDs and its message IDs, forever. You reconcile its delivery receipts against your charges, forever. You decide what happens when your application charged and the API call timed out, and you get that right, forever. Every one of those is cheap to write on a Tuesday and expensive the first quarter-end that does not balance. Budget 20 to 30 percent of the build, every year, for this and the ordinary feeding: patches, a carrier’s new error code, a vendor upgrade that changed a response shape.

Add it up: 6 to 12 developer-months to a first version you would put a paying client on, plus a permanent maintenance line, plus the gateway licence you already paid. The licence bought you the bearer and the GUI. It did not buy you the business.

Three years of cash, honestly laid out

Same business in both columns: a reseller with clients to bill, on their own server. The developer range spans a competent contractor in an emerging market at roughly 3,000 USD per month up to a European or North American hire at roughly 8,000 USD per month, which is a huge spread and the main reason this decision looks different in Lagos than in Frankfurt. Gateway licence pricing changes by tier and by year, so we are not going to quote a competitor’s number at you: get it from their price list, and read carefully what it is priced per.

Line item, 3 years	Single-tenant gateway, plus your own business layer	Smppcube v9
Software licence	Per server, per tier, check current price list	6,400 USD, once
Annual maintenance or upgrades	Typically recurring	Included, perpetual licence
Server, 40 to 80 USD per month	1,440 to 2,880 USD	1,440 to 2,880 USD
Build the tenancy, billing and portal layer, 6 to 12 dev-months	18,000 to 96,000 USD	0 USD
Maintain that layer, years 2 and 3	7,200 to 38,400 USD	Your own ops time
Second node, DR or a second country	Another licence	Same licence
Three-year cash, excluding gateway licences	26,640 to 137,280 USD	7,840 to 9,280 USD

Two shapes, not just two totals. One column is a small fixed number that is fully known on day one. The other is a range with a factor-of-five spread, an unknown end date, a licence that reprices when you grow, and a tail that never stops. In a business built on thin per-message spreads, the predictable column is worth something before you even compare the totals.

And notice the second-node row, because it is the one that ambushes people. Per-server licensing is perfectly reasonable pricing for an IT department that has one server. For an operator who wins a client in a second country, or who finally builds the active-active pair the availability conversation demanded, the same growth that makes you money makes your software bill grow with it. A perpetual licence you own does not do that.

The line nobody puts in the spreadsheet

Take the napkin math from the reselling playbook: ten mid-sized clients averaging 300,000 messages a month is 3,000,000 messages, and at a 0.0030 USD spread that is 9,000 USD of gross margin a month. Delay client number one by six months while you build a billing engine beside your gateway and that is 54,000 USD of margin that never existed, on the optimistic assumption that the clients wait. They do not. They sign with whoever was ready in March.

Then there is the branding line, which is specific to this class and rarely priced at all. Your client logs in somewhere. If that somewhere is an admin interface with someone else’s product name at the top, you are a person with a gateway, and your client now knows the name of the software they could buy themselves. If it is a portal on their own domain with their own logo, you are their platform, and switching away from you means migrating their systems, retraining their staff and explaining a new URL to their customers. That is not vanity. That is the entire difference between a supplier who is repriced every renewal and one who is not, and it is decided by which login page they see.

The counterpoint, honestly stated: none of this bites if you have no clients. If you are one company sending your own traffic, time-to-revenue is zero either way and the branding argument is meaningless, because the only person looking at that login page is you.

When a single-tenant gateway is still the right call

Four cases. We would rather lose the sale than sell you 6,400 USD of software you do not need.

One organisation, nobody to bill. Your systems, your messages, your carrier. No tenants, no balances, no invoices, no portal. Buy the gateway, configure it, get on with your actual job. This is the most common case where we tell people not to buy from us, and it is not a consolation prize: for that job, they are the better product.

MMS, MM7 or a modem farm is the real requirement. If the brief involves picture messaging, carrier MMS interfaces or a rack of SIMs, NowSMS is better at that than we are, and no amount of multi-tenancy compensates for a protocol you need and we do not lead with. Buy the tool that does the actual job.

You are a Windows shop and intend to stay one. Our stack is Linux: NGINX, PHP, Node.js, Redis, MySQL, Kannel. If your operations team lives in Windows Server and that is not changing, a gateway that installs natively into their world will be run better by them than ours will, and a well-run adequate system beats a badly-run excellent one every single time.

The use case is fixed and internal. Alerts from a monitoring system. OTP for one application. Appointment reminders from one clinic’s booking software. It will not grow into a reseller tree, you know it will not, and installing a multi-tenant platform to do it is bringing a lorry to collect a letter.

Notice that three of the four are the same test wearing different clothes: how many balances do you have to keep? If the answer is one, this article is telling you to close the tab and buy from them.

Deciding this in an afternoon

Four questions, written down where you cannot fudge them later.

First, how many balances must you defend? One, and the whole multi-tenant argument evaporates. More than one, and every gap in this article is now a project with a start date, and the only open question is who writes it and when.

Second, whose logo is on the login page? If the honest answer is “the vendor’s, and my clients have noticed”, you are not building a moat, you are renting one. Price what that costs at renewal, because your client is pricing it too.

Third, what happens when you win the second country? Walk the licence forward: a second node, a second tier, a DR pair, an active-active pair. If the software bill grows with the good news, that is a structural fact about the pricing model and it does not improve with negotiation.

Fourth, when their spec sheet does not match your need, what do you do? With closed source: raise a feature request and wait, or build beside it. With source code in your hands: change it, or pay someone to. That is not a licence detail, it is the ceiling on how far your product can diverge from the box it came in.

Then decide, and be at peace with it. If the answers point at a single-tenant gateway, you have our respect and our honest recommendation, and you should go and buy the one that fits the protocol you actually need. If they point the other way, what you are buying is not a bearer, because you already have three good ones to choose from. It is the layer that turns messages into invoices: a one-time licence on your own server, with multi-tenancy, billing and white-label portals already written, and the telecom underneath doing the job that class of software has always done well.