█████╗ ██████╗ ██████╗ █████╗ ██╗ ██╗ ██╗ ██╗
██╔══██╗██╔══██╗██╔══██╗██╔══██╗██║ ██║ ██║ ██║
███████║██████╔╝██║ ██║███████║██║ ██║ ███████║
██╔══██║██╔══██╗██║ ██║██╔══██║██║ ██║ ██╔══██║
██║ ██║██████╔╝██████╔╝██║ ██║███████╗███████╗ ██║ ██║
╚═╝ ╚═╝╚═════╝ ╚═════╝ ╚═╝ ╚═╝╚══════╝╚══════╝╚═╝ ╚═╝
Building scalable systems — from pixel-perfect mobile UIs to distributed backends
I'm a software engineer who cares deeply about how software is designed, not just that it works. My work sits at the intersection of mobile, web, and systems — with a growing obsession for clean architecture, domain-driven thinking, and robust backend design.
- 🏗️ Currently building SafarGo — an inter-region transportation app for Somalia, built with React Native + Expo
- 🦫 Exploring Go for high-performance backend services
- ✍️ Writing about dev topics at KawTech Blog
- 🎯 Deep interest in Software Architecture, Design Patterns, and Multi-tenant Systems
Inter-region transportation platform for Somalia A mobile-first app connecting passengers with inter-city travel across Somali regions.
Stack: React Native · Expo Router · Reanimated · Go (backend) · PostgreSQL
Arch: Clean Architecture · Repository Pattern · Multi-tenant Design
Status: 🔨 Active Development
A SaaS platform where multiple schools operate in complete isolation under a single deployment.
┌──────────────────────────────────────────────────────────┐
│ API Gateway / Router │
│ (Tenant Resolution by subdomain) │
└────────────┬──────────────────┬────────────────┬─────────┘
│ │ │
┌──────▼──────┐ ┌──────▼──────┐ ┌──────▼──────┐
│ School A │ │ School B │ │ School C │
│ Tenant │ │ Tenant │ │ Tenant │
└──────┬──────┘ └──────┬──────┘ └──────┬──────┘
│ │ │
┌──────▼──────────────────▼────────────────▼──────┐
│ Shared Application Layer │
│ Auth · RBAC · Billing · Notifications │
└──────────────────┬───────────────────────────────┘
│
┌──────────────────▼───────────────────────────────┐
│ Database (Schema-per-Tenant) │
│ tenant_a.* │ tenant_b.* │ tenant_c.* │
└──────────────────────────────────────────────────┘
| Principle | Application |
|---|---|
| SOLID | Each module has one responsibility; interfaces over concrete types |
| DRY | Shared services via DI container; tenant config drives behavior |
| Dependency Inversion | Core domain has zero infra dependencies |
| Separation of Concerns | Domain / Application / Infrastructure / Presentation layers |
| Twelve-Factor App | Config from env, stateless processes, backing services |
// Repository Pattern — abstracts data access per tenant
type StudentRepository interface {
FindByID(ctx context.Context, tenantID, studentID string) (*Student, error)
ListByClass(ctx context.Context, tenantID, classID string) ([]*Student, error)
Save(ctx context.Context, student *Student) error
}
// Factory Pattern — creates tenant-scoped services
type TenantServiceFactory struct {
db *sql.DB
cache CacheProvider
mailer MailProvider
}
func (f *TenantServiceFactory) StudentService(tenantID string) StudentService {
repo := NewPgStudentRepo(f.db, tenantID)
return NewStudentService(repo, f.cache, f.mailer)
}
// Observer Pattern — event-driven notifications
type EnrollmentObserver interface {
OnStudentEnrolled(event EnrollmentEvent)
}
"Make it work, make it right, make it fast — in that order."
I think about software in layers:
Presentation ──▶ What the user sees & touches
Application ──▶ Use cases & orchestration
Domain ──▶ Business rules, entities, pure logic ← the core
Infrastructure──▶ DB, HTTP, file system, 3rd parties
This separation means the domain layer never knows about React, Go, or PostgreSQL — it's just pure logic. Everything else adapts around it.
I'm always open to discussing architecture decisions, interesting problems, or potential collaborations — especially around mobile apps, transportation tech, or anything being built for the Somali market.