The Origin: Solving a Real Communication Problem
In 2014, the gap between businesses that needed to reach customers via SMS and the tools available to do it affordably was significant. Existing platforms were expensive, poorly documented, and built for markets that didn't reflect the reality of West African telecoms infrastructure.
I built ScrybaSMS to close that gap — a self-funded, solo-engineered SMS platform that would grow from a prototype to a system processing hundreds of thousands of messages across multiple countries.
What ScrybaSMS Delivers
ScrybaSMS is a multi-channel messaging platform enabling businesses and individuals to send automated, promotional, and transactional SMS messages worldwide.
By the numbers:
- 452,800+ messages processed with delivery confirmation tracking
- 22,780+ registered users across multiple countries
- 99.9% platform uptime through progressive infrastructure improvements
- Sub-200ms API response times for high-throughput integrations
Core Platform Features
- Global SMS Delivery — Multi-carrier routing with automatic failover for maximum deliverability
- Campaign Management — Scheduled broadcasts, audience segmentation, and delivery analytics
- RESTful API — Fully documented API enabling integration with any web application or backend system
- Auto-responders — Triggered message sequences based on inbound SMS keywords
- Account Dashboard — Credit management, delivery reports, campaign history, and real-time analytics
- Sender ID Management — Custom alphanumeric sender IDs for brand-consistent messaging
Architecture Overview
ScrybaSMS was originally built on PHP (Yii Framework v2) — chosen at the time for its mature ORM, built-in RBAC, and rapid development tooling. The architecture was designed from day one to handle high-volume asynchronous messaging without a degraded user experience.
Request Flow
User / API Client
│
▼
ScrybaSMS Platform (PHP / Yii v2)
│
├── Message Queue (Redis)
│ │
│ ▼
│ Worker Pool
│ │
│ ▼
│ SMS Gateway Router
│ ├── Provider A (Primary)
│ ├── Provider B (Failover)
│ └── Provider C (Regional)
│
└── Delivery Receipt Handler
│
▼
Campaign Analytics DB
Key architectural decisions:
- Asynchronous message processing via a Redis-backed queue decoupled sending from the web request cycle — a user initiating a 10,000-recipient broadcast never waits for the queue to drain
- Multi-provider routing with automatic failover — if a primary gateway returns an error code, the message is re-queued and dispatched via the next available provider
- Delivery receipt webhooks processed asynchronously and stored against the originating campaign for analytics
Infrastructure
- Linux server (Ubuntu) with Nginx, PHP-FPM, and MariaDB
- Redis for session management, job queuing, and rate-limit counters
- Let's Encrypt SSL with automated renewal
- Automated off-site backups with verified restore procedures
10 Years of Sustained Engineering
What makes ScrybaSMS notable isn't just the initial build — it's the decade of continuous improvement while maintaining near-zero downtime.
Progressive modernisation milestones:
- Migrated from shared hosting to a dedicated VPS — zero data loss, zero user-facing downtime
- Introduced Redis job queues, replacing synchronous message dispatch that was blocking under burst load
- Implemented rate limiting and fraud detection to protect the platform from abuse as the user base grew
- Optimised database indexes and query patterns as the message history table crossed the millions-of-rows threshold
- Added comprehensive delivery analytics, transforming raw delivery data into actionable campaign insights
This is what long-term software stewardship looks like: not a rewrite every two years, but deliberate, incremental improvement that keeps a system modern without abandoning the users depending on it.
Engineering Lessons Applied
ScrybaSMS is the project where I learned what enterprise-grade reliability actually requires in practice — and where many of the engineering principles I carry into every new project were forged:
- Queue everything that shouldn't block the user — if it can be done asynchronously, it should be
- Design for failover from day one — single points of failure are technical debts that compound
- Observability is not optional — every critical operation should produce a log entry, and those logs should be searchable
ScrybaSMS is live at scrybasms.com. The platform continues to grow and is being evaluated for a full-stack modernisation to a Laravel + Vue.js SaaS architecture.