Nairobi, Kenya · Building across backend, native mobile and infrastructure

Senior software engineer

I build the systems people depend on.

From real-time communication to transaction-safe financial infrastructure, I turn difficult product problems into calm, observable, production-ready systems.

01 / Position

Seniority is not how much code you can produce. It is knowing where complexity belongs, what can fail, and how the team will know.

02 / Selected system work

Evidence, not a highlight reel.

One growing platform. Several difficult systems. Each case note focuses on the decisions beneath the interface.

Realtime systems02

Communication that survives the real world.

Presence, delivery state, offline queues, background synchronization, multi-instance fan-out and SFU-backed audio/video calling.

Financial infrastructure03

Money systems designed for failure.

Exact values, append-only double-entry records, idempotent operations, callbacks, reversals, risk checks and reconciliation.

03 / How I think

A system is a set of promises.

Select a layer. The interface changes; the engineering obligation does not.

Selected principle

Put complexity where it can be owned.

Good boundaries make change local. Domains should expose stable contracts while keeping their invariants, data and failure policy explicit.

domain ownershipstable contractsmigration safety

04 / Operating method

Calm systems come from deliberate work.

  1. 01

    Model the truth

    Start with invariants, actors and state—not endpoints or screens.

  2. 02

    Design the failure

    Retries, stale data and partial completion are normal operating conditions.

  3. 03

    Instrument the claim

    If a system says it is healthy, there should be evidence behind the statement.

  4. 04

    Release reversibly

    Safe migrations, staged delivery and honest fallbacks keep change survivable.

05 / Field notes

What the incident teaches.

Short notes from building systems where the difficult part begins after the happy path.

01

A timeout is not a verdict.

A response can disappear after the operation commits. Financial and distributed workflows therefore need stable idempotency keys, explicit state and reconciliation—not blind retries.

Transactions · failure semantics
02

The client lifecycle is part of the system.

Background execution, permissions, network transitions and operating-system delivery rules are distributed state. Treating them as interface details creates failures no backend dashboard can explain.

Native mobile · realtime
03

Observability is a product feature.

Useful diagnostics preserve context: the operation, participant, role, transition and correlation ID. That evidence turns a two-device mystery into a sequence the team can reproduce and fix.

Operations · engineering evidence

06 / About

Breadth without hand-waving.

I have grown by owning complete outcomes: the service, the client, the migration, the failure path and the operational follow-through. That is how I learned to see products as systems rather than collections of tickets.

What I bring
  • Backend and distributed architecture
  • Native iOS and Android engineering
  • Transaction integrity and financial workflows
  • Security, identity and administrative controls
  • Production diagnosis and release readiness
Tools I reach for

TypeScript · Go · Swift · Kotlin · SQL · PostgreSQL · Redis · Kafka · WebSockets · SwiftUI · Jetpack Compose · Docker · Kubernetes · OpenTelemetry

Beyond delivery

I lead technical planning and code review, communicate across product and operations, and mentor final-year IT students at Strathmore University.

07 / Next

Have a difficult system to make simple?

I’m interested in ambitious engineering problems, responsible AI systems, and teams that value evidence over theatre.

salvatoluice5@gmail.com