Skip to content
Dan Mwenda

DANMWENDA.DEV

I design, build and run the systems businesses depend on.

Production software across payments, telecom, property and compliance — architected, shipped and operated end to end. That means the service and its data model, the integrations it depends on, and the infrastructure it runs on, not just the feature in front of a user.

Let's Work Together →

CAPABILITIES

Six areas cover most of what a production system actually needs, from the data model up through the interface a user touches and the server it all runs on. I work across all of them on every engagement rather than owning one layer and handing off the rest.

  • Backend and API architecture

    Services in Go and PHP, with the data model treated as the primary design artefact rather than something generated from code. Background processing for anything a user shouldn't wait on: payment callbacks, SMS dispatch, scheduled billing runs. Where a system depends on a third party I don't control, the failure path is designed before the happy path — retries, idempotency keys, and a state a human can inspect when something is stuck.

  • Payment and disbursement integration

    M-Pesa Daraja end to end — STK push for collection, B2C for payout, C2B webhooks for reconciliation — plus bank webhook integrations like Equity Bank's biller-validation and payment-notification pair. The failure modes here are specific: a callback that never arrives, a payment reference a user typed wrong, a payout that succeeds on the rail but fails to record locally. Idempotency and a reconciliation path a human can audit matter more than the happy-path integration code, which is usually the easy half.

  • Real-time and messaging systems

    WebSocket connections scoped to who actually needs live state, not broadcast to everyone watching a screen — the difference between a server that scales with the number of active operators and one that scales with crowd size. Telecom messaging and USSD sit in the same category: session state that has to survive inside a carrier's timeout window, and delivery guarantees that have to hold even when the carrier's own retry behaviour is undocumented or inconsistent.

  • Data modelling and persistence

    PostgreSQL and MySQL, with schema and query design done by hand rather than generated by an ORM — SQLC compiles hand-written SQL into typed Go, which keeps a payout or a reconciliation query auditable as plain SQL instead of reconstructed from model definitions. Redis for anything that needs to be fast and short-lived: session state, rate limits, queue backing. Migrations are a first-class part of the work, not a step run once and forgotten.

  • Infrastructure and deployment

    Docker and Docker Compose for anything that needs to run the same way in development and in production, on Linux VPS infrastructure I administer myself rather than a managed platform abstracting it away. Reverse proxying and TLS through Caddy, monitoring through Prometheus and Grafana where a system’s health needs to be visible rather than assumed, and deployment reduced to a single documented command rather than a sequence of steps only one person remembers.

  • Frontend and interfaces

    Vue 3 and Next.js for the interface layer, and Laravel's Inertia stack where a PHP backend and a Vue frontend need to share routing and state without a separate API layer in between. The interface is the last thing designed, not the first — it exists to make the system underneath legible to the person using it, which only works if that system is coherent to begin with.

HOW I WORK

The shape of the work is the same whether the system moves money, messages, or a tenancy record: understand what's actually being modelled before writing code, build integrations to fail safely before making them fail rarely, and stay responsible for what happens after launch.

  1. 01Scope the constraint

    Before any code, the actual constraint gets named in writing — not ‘build a payments feature’ but ‘Safaricom confirms a charge asynchronously, so the system has to be correct in the gap between a fan tapping pay and the callback arriving.’ That constraint becomes the thing every later decision gets checked against, and it's usually where scope creep gets caught early, before it's expensive.

  2. 02Design the data model

    The schema comes before the API. A tenancy, a debt, a tip, a payout — each gets a shape that reflects what it actually is and what states it can actually be in, drawn out as tables and relationships before a single endpoint exists. Getting this wrong is the most expensive mistake to fix later, because everything else is built on top of it.

  3. 03Build and integrate

    Integrations get built against their failure modes first: what happens when a callback never arrives, when a webhook fires twice, when a delivery receipt is late by hours. The happy path is usually the easy part once the failure handling exists — retries, idempotency keys, and a state a human can inspect when something is stuck.

  4. 04Operate and own it

    Deployment is a single documented command, monitoring exists before something breaks rather than after, and the system stays mine to operate rather than handed off at launch. A system I don't run day to day is a system whose failure modes I stop learning from.

SELECTED WORK

Five systems in production, each in a different domain and mostly in a different stack — evidence that the range above isn't a list of technologies I've read about.

All work →