Smppcube vs open source (Kannel · Jasmin · PlaySMS)

Let us get the awkward part out of the way first: Smppcube ships with Kannel inside it. We are not here to tell you that open source is bad software, because we run it in production and we would make the same choice again. Kannel is twenty-odd years of hardened C that holds SMSC binds better than anything we would write ourselves. This comparison is not about the quality of free software. It is about a much narrower and much more expensive question: what does it cost to turn a free bearer into a business you can invoice from, and is that project your product or a detour? Below are the honest numbers, a side-by-side grid, and the cases where the free option is genuinely the right call and you should close this tab and go build.

What “free” actually means in this market

Free-as-in-licence and free-as-in-total-cost are different currencies, and the messaging industry is unusually good at confusing them. The reason is that the free thing does the visible, impressive part. It talks SMPP. It moves thousands of messages a second. It survives a carrier doing something rude at 3 a.m. Watching it work for the first time, it is very easy to conclude that the hard part is done.

The hard part is not done. The hard part is the boring part. A bearer moves messages; a business decides which client’s balance a message came out of, at which rate for which route, whether that client was allowed to send it, what happens to the money when the message hard-fails four hours later, what the client sees when they log in to check, and what you show a regulator or a disputing customer six months later. None of that is in scope for a bearer, and none of it is optional if you are charging people.

So the real choice was never “pay or do not pay”. It is: pay a licence once, or pay a developer for six to twelve months and then keep paying them forever to maintain what they built. Both are legitimate. They just cost wildly different amounts, and only one of them puts the bill somewhere you can see it.

What each open-source option actually covers

Three projects come up in every one of these conversations. Each is good, each is honest about its scope, and each stops in a different place.

Kannel. The classic open-source WAP and SMS gateway, written in C, split into BearerBox (the connections), SMSBOX (the HTTP interface) and SQLBOX (the queue tables). It is a bearer in the truest sense: it holds your SMPP binds, it moves messages, and it does both extremely well at volumes that embarrass a lot of commercial software. Configuration is a file edited over SSH. There is no GUI, no concept of a client, no balance, no invoice, no portal, and no support line. That is not a gap in the project, it is the project’s boundary, deliberately drawn.

Jasmin. A modern Python SMS gateway and router, with a genuinely nice architecture: a message router, a jCli command-line management interface, an HTTP API, and, unlike Kannel, a rudimentary billing concept where a user has credits that a submit decrements at a configured rate. That last part matters, and it is why Jasmin often gets shortlisted. But be precise about what it is: per-user credits, not a billing system. There is no invoice, no multi-currency, no prepaid-versus-postpaid distinction, no per-client rate card by route and destination, no reseller tree, no client portal. It is a much better starting point than a raw bearer, and it is still a starting point.

PlaySMS. The one that looks closest to a product, because it is a PHP web application: a browser UI, user accounts with levels including a reseller tier, a simple credit balance, contact groups, and gateway modules that let it drive Kannel or a modem underneath. For a small operation with a handful of users it can genuinely be enough, and we would rather you knew that than found out later. Where operators outgrow it is depth and cadence: rate cards per route, prepaid and postpaid running side by side, multi-currency invoicing, real tenant isolation, per-tenant white-labelling, the newer channels, and a development pace that keeps up with WhatsApp and RCS changing their rules every quarter.

The pattern across all three is the same. The telecom layer is solved and free. The commercial layer is unsolved and yours.

The comparison, side by side

	Kannel	Jasmin	PlaySMS	Smppcube v9
Licence cost	Free	Free	Free	6,400 USD once
SMPP binds to SMSCs	Excellent	Excellent	Via a gateway module	Kannel, inside the stack
Admin GUI	None	CLI (jCli)	Yes, basic	Full web GUI
Client accounts	None	Users with credits	Yes, basic levels	Multi-tenant with a reseller tree
Credit enforcement	None	Per-user credits	Simple balance	Credit, wallet and auto routes
Rate cards per route	None	Basic rating	Limited	Per client, route and destination
Invoicing	None	None	None	Prepaid, postpaid, recurring, multi-currency
White-label client portal	None	None	Partial	Per tenant, fully branded
Client-readable reports	Log files	Log files	Basic	Dashboards and exports
WhatsApp, RCS, voice	No	No	No	In the same platform
Accountable support	Community	Community	Community	Vendor, with an SLA
Time to first paying client	6 to 12 months	4 to 9 months	Weeks, then a ceiling	Days

Read that grid honestly and two things jump out. The top rows, the telecom rows, are a tie or close to it, because we are all standing on the same software. Every row where money, clients or brand appears is where the free options stop and the build project starts. The last row is the one that ends up mattering most, and we will price it in a moment.

The four gaps, with a price on each

The Kannel alternative guide walks through what a bearer will never do for you. This article does the less comfortable thing and puts a number on each gap. The estimates below assume one competent full-stack developer who already understands SMPP, delivery receipts and money, which is a rarer animal than it sounds and prices accordingly.

Multi-tenancy. About 1 to 2 developer-months. Accounts, a reseller tree, permission groups, per-tenant isolation of contacts and campaigns and sender IDs, and a suspension switch that stops one client without touching the others. It sounds like a weekend of CRUD until the day a bug leaks one client’s contact list into another’s export, which is a phone call you only make once.

Billing. About 3 to 6 developer-months, and this is where projects die. Reserve credit before send, price by the route actually taken, refund correctly on a hard failure but not on a soft one, make every operation idempotent so a queue retry never double-charges, hold prepaid and postpaid side by side, handle multiple currencies, and produce an invoice a finance department will accept. The billing models guide describes the ledger discipline involved. The first version takes a month and looks finished. The version that survives a client disputing a 50.00 USD line item takes six.

White-label portals and reports. About 2 to 3 developer-months. A branded panel per tenant: compose, upload a list, check a balance, pull a delivery report, see an invoice. Plus turning raw DLR events into something a client can filter and understand without calling you. This is the part your clients actually touch every day, so it is also the part that cannot look like an internal tool.

Operations and the forever tax. About 20 to 30 percent of the build, every year, indefinitely. Security patches, a WhatsApp template rule that changed, a carrier that started returning a new error code, the developer who wrote your billing engine taking a job elsewhere and leaving you with an undocumented ledger. Software is not a capital purchase you make once, it is a pet you feed. Everyone models the build. Almost nobody models the feeding.

Add it up: 6 to 12 developer-months to a first version you would put a paying client on, plus a permanent maintenance line. That is the same figure our Kannel guide quotes, and it is not a scare number. It is what this specific problem costs, and it is why the commercial platforms exist at all.

Total cost of ownership over three years

Numbers, then. The two columns below assume the same business: a reseller with clients to bill, running on their own server. The developer rate 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 genuinely enormous spread and is the single biggest reason this decision looks different in Lagos than it does in Frankfurt.

Line item, 3 years	Open source, built up	Smppcube v9
Software licence	0 USD	6,400 USD, once
Server, 40 to 80 USD per month	1,440 to 2,880 USD	1,440 to 2,880 USD
Build the missing layer, 6 to 12 dev-months	18,000 to 96,000 USD	0 USD
Maintenance, years 2 and 3	7,200 to 38,400 USD	Your own ops time
Support when a bind drops	Community goodwill	Included
Three-year cash total	26,640 to 137,280 USD	7,840 to 9,280 USD

Before anyone writes in: yes, the low end of that open-source column is achievable. If you are the developer, and your time has no market price because you were going to be at that desk anyway, the build column collapses toward the cost of your server and your patience. That is a real scenario and we say so in the next section but one. What it is not is free. It is six to twelve months of your professional life, spent on infrastructure rather than on customers, and paid in the one currency you cannot invoice for later.

And note the shape of the two columns, not just the totals. One 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, and a tail that never stops. In a business built on thin per-message spreads, the predictable column is worth something on its own.

The line nobody puts in the spreadsheet

Here is the number that dwarfs everything above, and it never appears in the build-versus-buy comparisons people post in forums.

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 every month. Now delay the day you can onboard client number one by six months while you build a billing engine. That is 54,000 USD of margin that never existed, and that is the optimistic case, because it assumes the clients wait for you. They do not. They sign with the operator who was ready in March.

This is why time-to-first-revenue belongs in the comparison table and why we put it there. Every month of build is a month of not selling, in a market where the moat is not technology at all: it is route quality, service, and the stickiness of a client whose systems are already wired to your API. None of those three are earned by writing a credit ledger. They are earned by having clients, which requires being able to take clients, which is the thing the build is standing in front of.

The counterpoint, honestly stated: this argument only bites if you actually have clients waiting. If you are still proving demand, a delayed launch costs you nothing because there was no revenue to delay. Which brings us to the section this whole article has been building toward.

When open source is still the right call

We would rather lose the sale than sell you 6,400 USD of software you did not need. Four cases where free is correct.

You are a single tenant with nobody to bill. One company, one carrier, your own systems sending your own messages. No reseller tree, no client balances, no invoices, no portal. Kannel plus a few scripts is the right answer, and a multi-tenant platform is weight you would carry for nothing. This is the most common case where we say do not buy.

You are still proving the market. No clients yet, no signed contracts, just a hypothesis. A free gateway and a spreadsheet is a perfectly respectable pilot, and it costs you a weekend to find out whether anyone will pay you at all. Buy the platform when the answer is yes, not before.

Gateway software is your product. Some teams are building a messaging platform to sell, or have a genuinely unusual requirement that no commercial product models. If the software is the business rather than a tax on the business, of course you build it. Building it is the point.

Your volume and your margins are tiny. A few thousand messages a month at a small spread will not amortise a licence in any reasonable timeframe, and it will not amortise six developer-months either. Stay small, stay free, stay honest with yourself about which one you are.

Notice that three of those four are the same test in different clothes: is the commercial layer your product, or is it the thing standing between you and your product?

Deciding this in an afternoon

You do not need a consultant. You need four honest answers, written down where you cannot fudge them later.

First, do you have clients to bill? If no, stop, use Kannel, come back when the answer changes. If yes, the commercial layer is not optional and the only question is who writes it.

Second, what is a developer-month actually worth to you? Use a real number, either what you would pay someone or what you could earn with those hours doing something else. If your answer is “nothing, I do this for fun”, that is a legitimate answer, and the build column just got very cheap. Write it down anyway, because it changes the moment you get busy.

Third, what does a month of delay cost? Multiply your expected monthly gross margin by the months of build. If that number is bigger than a licence, the argument is already over and no amount of spreadsheet refinement will bring it back.

Fourth, who answers at 2 a.m.? Not who patches it eventually. Who owns the problem while a client’s overnight statement run is failing. If the answer is “me, and I am also the only person who understands the billing code I wrote”, price that honestly. That is a person, not a line item, and it is the constraint that quietly caps how big you can get.

Then decide, and be at peace with it. If the four answers point at open source, you have our blessing and our respect, and the self-hosted gateway guide will tell you what you are signing up for operationally. If they point the other way, what you are buying is not really software. It is the six to twelve months you get to spend on customers instead, delivered as a one-time licence on your own server, with the multi-tenant, billing and portal layer already written and Kannel still doing the job it was always good at, underneath.