I design and build scalable, secure, and high-performance systems across web, mobile, and backend platforms.
Hi, I'm Phenius Muthomi - a Computer Science graduate and software engineer with experience building fintech systems, marketplace platforms, integration-heavy products, and distributed backend infrastructure.
I work across Next.js, React Native, Kotlin, Swift, TypeScript, Node.js, Python, Java, REST APIs, GraphQL, gRPC, WebSockets, and MQTT. That makes me useful both to teams hiring a senior software engineer across backend, web, and mobile, and to founders who need a founding engineer to move from idea to production.
My work sits at the intersection of software engineering, systems architecture, networking, and platform design. I think about whole production systems: client applications, API boundaries, application services, data stores, async workers, observability, and infrastructure behaving as one coherent platform.
Primary Focus
Connected systems
reliable communication across clients, services, data, and external integrations
Delivery Range
Web, mobile to cloud
clients, APIs, application services, data stores, and production infrastructure
Working Style
Systems-first
contracts, state ownership, async workflows, and observability matter
systems.map
runtime.flow
I am a senior engineer with a background in Computer Science and a career spanning integration engineering, backend systems, web and mobile platforms, fintech products, marketplace systems, and startup delivery. The throughline is connected software: secure APIs, reliable data flows, scalable services, and production systems that hold together across clients, services, and infrastructure.
I have built CBK-regulated payment systems, backend services, API gateways, relational data models, internal tools, multi-tenant financial platforms, mobile and web clients, and real-time systems. I do not think about products as isolated screens or isolated endpoints. I think about how clients, services, databases, background jobs, and external integrations behave as one production system.
Mobile Client & Web Client flows
API Gateway design
Application Services
PostgreSQL & Redis state
Worker Queue & Background Workers
Realtime Service & MQTT Broker
External Integrations
Modern software is not just code running in isolation. It is an ecosystem of clients, APIs, services, brokers, databases, devices, and networks communicating continuously. Strong engineering requires understanding how systems are structured, how services communicate, how failures propagate, and how architecture supports scale, maintainability, and integration.
01
Modern software is not code running alone. It is clients, APIs, services, brokers, databases, devices, and networks communicating continuously.
02
I care about how systems are decomposed, how contracts are shaped, and how teams can evolve services independently.
03
Protocol choice, payload design, latency, retries, and idempotency all shape reliability and system behavior.
04
Observability is part of design. If communication paths fail silently, the architecture is incomplete.
05
A scalable platform handles growth in load, features, partners, and engineering teams without collapsing into coupling.
06
I work as both builder and architect, reasoning from UI and mobile clients all the way down to transport and inter-service communication.
Across transport integrations, regulated fintech, multi-country financial products, marketplace systems, and startup platform design, the common pattern has been software that must move reliably through APIs, services, data stores, background processing, and external systems.
Tospay Ltd
Worked on integration systems involving SGR bytecode, a railway and terminal payload format, translating lower-level protocol messages into REST interfaces consumable by third-party systems integrating with SGR services.
Built translation boundaries that turned specialized transport payloads into stable API contracts.
Gladys Technologies
Developed backend systems, API gateway services, transaction databases, internal tools, and observability for a CBK-licensed payment platform supporting wallet-driven financial flows in Kenya.
Contributed to architecture and compliance work that supported PSP licensing while building secure transaction infrastructure.
Alsoug
Built MyCashi, a digital payments and e-wallet style product in South Sudan serving local financial use cases such as transfers, bill pay, top-ups, and wallet-oriented mobile finance.
Designed mobile payment software for environments where connectivity and infrastructure are not guaranteed.
Power Financial Wellness
Led development across Power's regional financial products, building mobile applications, backend services, relational data models, integrations, and deployment workflows for Kenya, Uganda, and Zambia.
Owned delivery across app and backend layers, from onboarding and financial flows to release automation and runtime visibility.
NCBA
Led design and development of CarDuka and AuctionsDuka across mobile and backend systems, combining React Native, Swift, Kotlin, and NestJS to deliver marketplace and fintech capabilities at production scale.
Worked across product surfaces, backend services, databases, CI/CD, and observability rather than treating the delivery as mobile-only work.
I design systems where Mobile Clients and Web Clients enter through an API Gateway, Application Services own business behavior and state, Worker Queue and Background Workers absorb async work, and live updates flow through a Realtime Service or MQTT Broker depending on whether the problem is direct state synchronization or topic-based broadcast. When a product needs aggregated client reads, GraphQL stays inside the API Gateway as a BFF instead of becoming a separate service boundary.
I care about how clients communicate through an API Gateway, how Application Services own business rules, how durable state lives in PostgreSQL, how Redis holds hot state and session data, how async work moves through a Worker Queue into Background Workers, and how External Integrations are isolated from the request path without becoming invisible operational risk.
mobile-client / web-client -> api-gateway -> application-services -> postgresql / redis -> worker-queue -> background-workers -> external-integrations -> realtime-service / mqtt-broker
GraphQL exists here as a GraphQL Gateway (BFF) inside the API Gateway for aggregated reads, not as a separate internal service boundary.
state ownership
application-services -> postgresql : durable business state, transactional records, geospatial queries
application-services -> redis : sessions, cache, and short-lived coordination state
worker-queue -> background-workers : jobs consumed with retry semantics, idempotency, and failure isolation
API Gateway & Client Layer
Mobile Client and Web Client traffic enters through an API Gateway that handles routing, authentication, and the optional GraphQL Gateway (BFF) used for aggregated client reads.
Application Services & State
Application Services own business rules, persist durable records in PostgreSQL, and use Redis for session state, caching, and short-lived coordination.
Worker Queue & Background Workers
Application Services enqueue jobs for settlement, notifications, and external service calls. Background Workers consume them asynchronously with retries, idempotency, and failure isolation so client requests stay fast.
Realtime Service vs MQTT Broker
Realtime Service uses WebSockets for direct client-server state synchronization. MQTT Broker handles topic-based pub/sub when multiple distributed clients need the same lightweight broadcast.
This is where architecture becomes operational reality: choosing the right communication style, exposing safe contracts, integrating heterogeneous systems, and keeping the platform understandable as complexity grows.
REST
Used for Mobile Client and Web Client requests through the API Gateway
Used for explicit service-to-service and partner integration calls
Fits authentication, validation, versioning, and retry-aware workflows
Keeps write paths and external boundaries easy to reason about
The default choice unless a system has a stronger reason to do otherwise
GraphQL
Used when a client needs an aggregated read model across multiple Application Services
Lives inside the API Gateway as a client-facing BFF, not as a separate service boundary
Schema-driven reads keep complex UI queries explicit and typed
Useful for composition-heavy dashboards and marketplace views
Not a default replacement for clear REST contracts on write paths
WebSockets
Used by the Realtime Service for direct client-server updates
Fits order state changes, delivery progress, live dashboards, and status transitions
Keeps UI state aligned without forcing clients to poll
Best when the update is tied to a user session or active screen
Separate from background processing and broker-based broadcast
MQTT
Used by the MQTT Broker when multiple clients subscribe to the same shared topic
Useful for lightweight fan-out across distributed clients and constrained networks
Good for broadcast-style updates where direct session ownership is not the point
Different from WebSockets: MQTT is topic-driven pub/sub, not a direct client-server session channel
Applied only in products that genuinely benefit from shared subscriptions
TCP / UDP
TCP underpins HTTP, WebSockets, and most MQTT sessions in application systems like these
UDP only matters when low-latency tradeoffs justify weaker delivery guarantees
Reliability, ordering, and connection behavior shape how higher-level protocols behave
Useful for debugging network issues and making realistic latency assumptions
Important architectural context, even when it is not the product-facing abstraction
System Integration
Translate partner-specific payloads into internal contracts the platform can trust
Separate inbound webhook handling from outbound partner calls
Treat retries, idempotency, and observability as part of the interface
Keep External Integrations from leaking quirks into Application Services
Make failure modes explicit so production behavior stays understandable
Bebea is a neighborhood commerce platform connecting customers, vendors, and riders through Mobile Client and Web Client flows, an API Gateway, Application Services, durable state, async processing, and live delivery updates. This section shows the actual runtime shape rather than a generic architecture sketch.
bebea.architecture
Order flow
A Mobile Client submits an order through the API Gateway. Application Services write the durable record to PostgreSQL, refresh hot state in Redis, enqueue downstream work, and return quickly. Background Workers then notify vendors, coordinate dispatch, and emit live order status through the Realtime Service.
Vendor discovery
Discovery reads come through the API Gateway into Application Services backed by PostgreSQL geospatial queries. Redis caches short-lived result sets so nearby-vendor lookups stay fast without turning stale data into a hidden correctness problem.
Real-time propagation
State changes flow through two deliberate channels. Realtime Service uses WebSockets for direct session synchronization when a user is actively tracking an order. MQTT Broker handles topic-based broadcasts when multiple subscribed clients need the same shared update.
External payment integration
Payment flows use an async confirmation pattern. Application Services enqueue work, Background Workers call the provider, and webhook or partner responses settle state in PostgreSQL before a user-facing update is published. That keeps external latency and retry behavior out of the request path.
Protocol selection rationale
Each protocol in Bebea was chosen for a specific behavioral reason, not convenience.
Client-server APIs where request-response is the natural shape of the interaction and broad compatibility with third-party systems matters.
Used as a GraphQL Gateway (BFF) inside the API Gateway when Web Client reads need aggregated data across Application Services without extra round trips.
Direct client-server state synchronization for active sessions such as order tracking, rider location, and live status changes where latency must stay low.
Shared topic-based broadcast when multiple subscribed clients need the same lightweight update and reconnect behavior needs to stay efficient.
Reliability & observability
Operational concerns addressed at the design level, not bolted on after the fact.
Worker-based background jobs
Application Services enqueue heavy operations such as settlement, rider dispatch, and notification fan-out. Background Workers consume them so API response times stay predictable and each job can be retried independently without replaying the whole client request.
Idempotent service design
Order creation and payment operations carry idempotency keys. Duplicate submissions from client retry logic or network-level flakiness are rejected cleanly at the service boundary without double-processing.
Failure visibility
Failed jobs carry structured error context, payload identifiers, and retry state. Problems surface through the Worker Queue instead of disappearing silently, which keeps failure isolation and debugging explicit.
Cache coherence under load
Redis caches use deliberate TTLs matched to data freshness requirements. Discovery results and vendor availability are short-lived. Expired entries degrade gracefully and the system falls back to PostgreSQL rather than surfacing errors to the client.
The value of this stack is not breadth for its own sake. It is the ability to move across mobile, backend, integration, communication, and architecture layers while keeping the whole system in view.
The strongest signal in my work is not just what was shipped, but how each product moved from client requests through an API Gateway and Application Services into data stores, background processing, and external integrations.
Featured project
Neighborhood commerce platform coordinating customers, vendors, riders, and local delivery flows.
Problem: Customers needed to discover nearby vendors, place orders, and track fulfillment without breaking the vendor and rider workflow behind the scenes.
Role: Founder, product architect, and systems builder across clients, Application Services, and delivery operations.
Communication challenge: The system had to keep customers, vendors, and riders synchronized while Application Services coordinated orders, geospatial discovery, and fulfillment state across unreliable mobile networks.
Architecture decision: I treated order state as durable records in PostgreSQL, used Redis for fast operational lookups, and pushed live status through WebSockets for session-specific updates while reserving MQTT for shared broadcast-style delivery coordination.
Featured project
Digital payments and e-wallet style product serving local financial use cases in South Sudan.
Problem: Users needed transfers, bill pay, top-ups, and wallet flows that still felt trustworthy when network quality was inconsistent.
Role: Android engineer responsible for payment-facing client architecture, request handling, and mobile reliability.
Communication challenge: The Mobile Client had to manage intermittent connectivity, request retries, and transaction state without confusing users or duplicating sensitive actions.
Architecture decision: I favored clear REST contracts, defensive client networking, and idempotent request handling so payment flows could recover cleanly when the network or partner response path was unstable.
Featured project
NCBA-backed marketplace and financing platform spanning client applications, backend services, and financial workflows.
Problem: The product needed vehicle discovery, financing interactions, and transactional flows while keeping client apps, backend services, and data models coherent.
Role: Senior Systems Engineer leading design and delivery across mobile clients, backend systems, APIs, database design, observability, and deployment workflows.
Communication challenge: Client apps depended on evolving backend capabilities for listings, loan pre-approvals, and financial workflows, so contracts and service coordination had to stay stable as the platform scaled.
Architecture decision: I favored a modular NestJS backend with clear service boundaries, Prisma-backed data access, REST and GraphQL APIs for client interactions, Redis for performance, and observability through Azure-native monitoring.
Featured project
Auction marketplace inside NCBA's digital platform, backed by shared financial and marketplace services.
Problem: Auction workflows needed fast read models, predictable transaction handling, and integration with existing marketplace and financial capabilities without duplicating core services.
Role: Senior Systems Engineer contributing across backend architecture, client delivery, API composition, and distributed service contracts.
Communication challenge: Auction reads and write flows cut across multiple services, so GraphQL composition, REST mutations, and inter-service communication had to stay coherent under change.
Architecture decision: We combined GraphQL and REST at the client boundary with modular backend services and proto/gRPC-driven inter-service communication so auction-specific features could evolve without breaking shared platform behavior.
I founded Bebea, a startup focused on building neighborhood commerce infrastructure. That experience is proof that I can design from first principles, own architecture decisions, move from concept to product, and think beyond tickets into operations, product mechanics, and business impact.
Bebea sharpened my ability to think like both engineer and operator. It required product judgment, architecture ownership, communication design, and execution discipline across Mobile Client and Web Client flows, Application Services, PostgreSQL-backed state, Background Workers, and real-time delivery behavior.
Design from first principles
Own architecture decisions
Move from concept to product
Think beyond tickets into systems, operations, and business impact
I actively use AI in my workflow for debugging, iteration, architecture exploration, code acceleration, and reducing feedback loops. AI does not replace engineering judgment. It amplifies it.
ai.multiplier
Step 1
Debugging complex issue chains across clients and services
Step 2
Reducing iteration time during implementation and refinement
Step 3
Using AI to explore architecture options before committing to a path
Step 4
Accelerating repetitive coding and scaffolding work
Step 5
Compressing feedback loops while keeping engineering judgment in control
Engineering judgment
The tool changes. The responsibility stays with the engineer.
The value of AI is speed with context, not speed without thought. I use it to widen exploration, accelerate delivery, and tighten loops around debugging and architecture decisions while keeping quality and system behavior in focus.
I work with founders who need help turning an idea into a real product, with startups that need a founding engineer or senior engineer across backend, web, and mobile, and with teams building fintech or integration-heavy platforms where architecture, data ownership, and runtime reliability all matter.
I can help turn an idea into a practical first product by shaping MVP scope, choosing a sensible stack, defining the architecture, and building the early platform with production awareness.
I am useful in environments that need one senior engineer to work across backend services, web platforms, mobile clients, API contracts, data models, deployment workflows, and runtime reliability.
I work well on systems where payments, External Integrations, a Worker Queue, Background Workers, and live client updates all need to operate reliably under production pressure.
Typical fit
If a team needs one engineer who can move from product-facing clients down to backend services, API contracts, data stores, background jobs, observability, and deployment workflows, this is the kind of work I do. The toolchain may be Next.js, React Native, Kotlin, Swift, NestJS, Node.js, Python, or Java, but the value is keeping the system coherent as it grows.
Available for roles where engineering judgment, cross-platform depth, and system-level thinking matter from day one.
Founding engineer or first technical hire
Senior backend, web, and mobile engineering
Systems architecture and API design
Fintech, integration-heavy, and real-time platforms
Available for opportunities
Open to full-time, contract, and founding engineer roles. Responding to serious inquiries.
finiephenius@gmail.com
Send a message →
Phone
+254 715 438 186
Call or WhatsApp →
About
Phenius Muthomi is a Senior Software Engineer and Systems Architect based in Nairobi, Kenya. He specialises in backend services, web and mobile platforms, distributed systems, fintech integrations, and real-time communication infrastructure. With experience across Next.js, React Native, Android, iOS, Node.js, Java, Python, cloud-hosted backend platforms, and production data systems, Phenius designs and builds software ecosystems from client experience to service architecture and infrastructure — helping startups ship reliable products and engineering teams scale with confidence.