Case studySaaS platform Live
SMSHub
Twilio, with a real inbox: live threads, contacts, templates and billing for teams that run on SMS.
- Role
- Sole full-stack engineer
- Timeline
- 3 months
- Stack
- Flask, Socket.IO, PostgreSQL
- APIs
- Twilio, Stripe
The problem
Twilio is great at sending SMS and terrible at being an inbox. Businesses that run on it end up with:
- no proper interface to follow conversations
- no history of who said what to which customer
- the same replies typed out by hand, over and over
- no shared inbox for the team
What I built
A Messenger-style app on top of each customer's own Twilio account. They connect it once, then send, receive and organise messages like any modern chat app.
Real-time messaging
Messages and notifications arrive instantly over WebSockets.
Serious security
Twilio credentials encrypted with Fernet, hashed passwords, a unique webhook per user.
Contact management
Tags, categories, notes and custom statuses on every contact.
Message templates
Saved quick replies for the answers you give every day.
Per-user webhooks
Each account gets its own URL to receive incoming SMS.
Stripe subscriptions
Free and Pro plans with message limits and billing.
Architecture
- FrontendHTML, CSS & JS · Socket.IO client · responsive UI
- BackendFlask · Flask-SocketIO · Flask-Login
- ServicesTwilio API · Stripe API · webhooks
- DataPostgreSQL · Fernet encryption · multi-tenant isolation
- Passwords hashed with Werkzeug security
- Twilio credentials encrypted with Fernet
- Unique webhook tokens per user
- Complete data isolation between tenants
- HTTPS enforced and rate limiting on API endpoints
In numbers
- messages sent
- 10k+
- avg response time
- <100ms
- uptime
- 99.9%
Got a process like this eating your week?
Tell me what it is. I'll tell you honestly whether software should be doing it.