Software & Systems Development
Pragmatic software engineering for operations — automation, integration, and enterprise systems, built by engineers who run production infrastructure.
Software that serves operations.
01 — Foundation
An Operations-First Engineering Practice
Our software practice grew out of running networks and systems, not the other way around. Development skills are grounded in formal software-engineering training (ALX/Holberton School — software engineering, DevOps & AI) applied continuously inside live ISP, telecom, and enterprise environments.
The result is software built for the realities of production: automation that survives failure modes, integrations that respect operational boundaries, and systems that the people running them can actually maintain.
02 — Capabilities
What We Build With
Tooling chosen for maintainability, not fashion
Languages & Tooling
- Python
- C
- Bash
- JavaScript
- PHP
- HTML & CSS
- Git
Automation & DevOps
- Linux server administration
- Infrastructure design & management
- Operational scripting and glue code
- Data structures & algorithms fundamentals
Web Platforms
- Cloud web development (HTML, CSS, JavaScript)
- WordPress
- Joomla
Microsoft 365 & Power Platform
- Power Automate
- Power Apps
- Copilot
- Purview
- M365 agentic AI cloud machines
Microsoft Dynamics 365
- Finance
- Supply Chain Management
Open-Source Enterprise Systems
- DHIS2
- Kobo Toolbox
- ODK
- CRMs
- ERPs
03 — Integration Engineering
Integration Glue That Survives Production
Most integration failures are silent: a webhook dropped at 02:00, a duplicate event that posts a payment twice, two systems that slowly disagree about what is true. Having run the ISP systems these integrations connect — billing, AAA, monitoring, ticketing — we treat glue code as production software, not scripting.
The Patterns We Build In
Delivery over a network is at-least-once at best. We design for duplicates, gaps, and reordering from day one, rather than assuming they will not happen.
Idempotent Consumers
Every event will eventually arrive twice — a payment confirmation, a provisioning trigger, a status callback. We key each event and guard processed state so a replayed message produces no second side effect: one confirmation, one invoice settled, one service activated.
Queues, Retries & Backoff
Synchronous chains fail together. We put a queue between systems so a slow or offline endpoint does not lose events, retry with exponential backoff and jitter, and route poison messages to a dead-letter queue where they can be inspected instead of silently blocking everything behind them.
Reconciliation Jobs
Retries handle minutes of failure; replay handles hours; reconciliation handles everything else. Scheduled jobs compare systems of record — payments against invoices, accounting sessions against billing — detect drift, and repair it, so correctness never depends on perfect delivery.
Observability of Glue Code
Integration code fails quietly unless it is instrumented. We ship structured logs, delivery and failure metrics, and alerts on queue depth and reconciliation deltas — so the first sign of a broken integration is a dashboard, not a customer complaint at month-end.
Where This Bites in Practice
The stakes are concrete in the operational systems we work on daily:
Payment → Billing → Provisioning
A mobile-money or gateway confirmation must resolve to exactly one payment record and one service reactivation. A dropped event suspends a paying customer; a duplicated one gives away service or double-credits an account. Both cost money and trust.
AAA & Usage Accounting
Session accounting streams feed billing. Missed or duplicated accounting records mean revenue leakage or disputed invoices — which is why the accounting-to-billing path gets idempotency and a nightly reconciliation, not just a webhook.
Monitoring & Ticketing
Alert-to-ticket automation without deduplication and correlation floods the helpdesk during a real outage — exactly when it matters most. We design suppression, dedup keys, and closure sync so the ticket queue reflects reality.
Software that serves operations, not the other way around.
05 — Delivery Discipline
Delivery Discipline in the AI-Assisted Era
Generating code is now cheap; verifying it is the constraint. We use LLM and agentic tooling daily — and that is precisely why the discipline around it matters more, not less.
Specification First
- Written problem statement before any code is generated
- Acceptance criteria and explicit non-goals agreed up front
- Data contracts and failure modes named in the spec
- Ambiguity resolved with the client, not guessed at by a model
Tests as the Contract
- Failure-mode tests — duplicates, timeouts, partial data — not just the happy path
- A passing regression suite is the definition of done
- Generated code must earn its way through the same suite as hand-written code
- No test, no merge — regardless of who or what wrote the change
Review Rigor
- Automated checks handle style, known vulnerabilities, and formatting
- Human review focuses on intent, architecture, and operational fit
- Small, reviewable changes — large generated diffs get split or rejected
- Nothing ships that the maintaining engineer cannot explain line by line
When We Do Not Generate
- Billing arithmetic and anything that moves money
- Authentication, authorization, and credential handling
- Scripts that act on live production infrastructure
- Anywhere the cost of a subtle bug exceeds the cost of writing it by hand
The same discipline extends to low-code: Power Platform work starts with environment strategy, data-loss-prevention policies, and named ownership — before citizen-built apps harden into unmaintained shadow IT.
06 — Open-Source Platforms
Open-Source Enterprise Platforms, Deployed Honestly
DHIS2, Kobo Toolbox, ODK, and open CRM/ERP platforms are how much of Africa runs health programmes, field data collection, and back-office operations. We have deployed and adapted them in production — including health-sector work with Jembi Health and the Rwanda Ministry of Health, and operational systems for Tanzania National Parks.
Deployment Realities
License-free is not cost-free. The real work is adaptation — forms, indicators, and workflows that match how the institution actually operates — plus hosting, upgrades, and integration with the systems already in place. We scope that work explicitly instead of hiding it behind the word "free".
Data Ownership
The point of open source is that the institution owns its data, its schema, and its export path. We configure for local ownership from day one — hosting where regulation and connectivity demand it, documented data models, and no dependency that turns into per-seat lock-in later.
Handover & Capacity
A deployment is not finished until the institution can run it without us. Every engagement ends with admin runbooks, trained local administrators, and a documented upgrade path — because a system only its vendor understands is a liability, not an asset.
We deploy platforms the client can own — technically, legally, and operationally.
07 — Where It Fits
Where This Practice Fits
Software & systems development at HCS is rarely a standalone engagement — it usually closes a gap the infrastructure work has exposed:
- Automating repetitive network and systems operations
- Integrating billing, monitoring, and ticketing platforms that do not talk to each other
- Deploying and adapting open-source enterprise systems for NGOs and institutions
- Building internal tools, dashboards, and workflow apps on the Microsoft stack
- AI-assisted tooling (LLM, NLP, agentic AI, open-weight models) applied to operational data
If a commercial product already solves the problem well, we will say so.
The economics inverted this cycle: with agentic coding tools, generating code is now cheap and verifying it is the constraint — teams report PR volume nearly doubling while median review time balloons — so the durable skill is specification, testing, and review discipline, not typing speed. Meanwhile open-source ERP adoption keeps climbing as proprietary per-seat pricing rises, which means the interesting operations work in 2026 is mostly integration glue: making ERPNext or Odoo, a payment processor, and a decade-old line-of-business system agree on what an invoice is.
Discuss a Systems or Software Problem
Start with a focused review of the operational gap you are trying to close.