DEV Community: Pritt Patrick

Why Kenyans Still Type 20-Digit Tokens in 2026: The Split Metering Reality and the Auto-Load Bottleneck

Pritt Patrick — Wed, 30 Sep 2026 12:58:29 +0000

Every Kenyan with a prepaid meter knows the ritual. You buy tokens on M-Pesa (Paybill 888880), receive the SMS with a 20-digit code, grab the Customer Interface Unit (CIU), plug it into a wall socket, and carefully key in the numbers. One wrong digit and you get “Reject.” Batteries low? “Conn Fail.” Power out in the house? Hope the alkaline batteries are fresh and you’re on the right socket.

This is not a bug. It is the deliberate architecture of Kenya’s split metering system.

How Split Metering Actually Works

Kenya Power’s prepaid system separates the hardware into two devices:

The main meter (MCU – Measurement/Control Unit): Usually installed outside on a pole, in a locked box, or in a shared meter room. It measures consumption, stores the credit, and physically disconnects supply when units run out. It is deliberately hard to reach to reduce tampering.
The Customer Interface Unit (CIU): The small keypad + display you keep inside the house. This is the only way most customers interact with the meter.

Communication between the two happens almost exclusively through Power Line Communication (PLC). The CIU injects signals into the house wiring. The meter listens on the same electrical network. That is why the CIU must be plugged into a wall socket on the same circuit (and why extension cables often break the connection). Batteries only power the CIU’s screen and keypad; they do not replace the need for a live power-line path to the meter.

The tokens themselves follow the Standard Transfer Specification (STS) — a South African-origin standard designed in the 1990s for environments with little or no reliable communication infrastructure. Each 20-digit token is encrypted specifically for one meter using a unique decoder key stored inside that meter. There is no network address, no SIM card, and no back-channel from the meter to Kenya Power.

The Core Bottlenecks That Prevent Automatic Loading

Physical and logical isolation by design

The meter has no cellular, GPRS, NB-IoT, or IP connection. It was engineered to work in remote areas where mobile signal is unreliable or nonexistent. Once installed, the only trusted path for credit is a human typing a cryptographically signed token into the CIU. Kenya Power’s central systems generate the token after payment; they have no way to push it into the meter.
One-way communication

PLC in the current deployment is effectively one-directional for token loading (CIU → meter). There is no reliable reverse channel that would allow the utility to confirm delivery or push credit remotely without additional hardware.
Security and anti-tamper priorities

Keeping the meter offline and requiring physical entry of a meter-specific token reduces certain classes of remote attacks and makes large-scale credit fraud harder. The split design itself exists largely to keep the measurement unit out of easy reach of customers.
Legacy STS constraints and the 2024 TID update

STS tokens use a finite Token Identifier space. The global TID rollover forced a massive “Update Token Meter Yako” campaign in 2024, during which customers still had to manually enter reset and update codes. Even after the upgrade to STS Edition 2, the fundamental delivery method remained manual key entry.
Practical failure modes that compound the problem
- Low or dead CIU batteries
- Wrong socket / extension cable / phase mismatch
- PLC errors and “Conn Fail”
- Token entry lockouts after repeated wrong attempts
- Power already off in the house (forcing battery-dependent entry)
- 20-digit human entry error rate (estimated around 6% in some analyses)

These issues hit hardest in rural areas, multi-tenant buildings, and among elderly or less tech-comfortable users. The result is delayed restoration of power, high call volumes to 97771, and a persistent feeling that the system is stuck in the past while the rest of Kenya’s digital economy has moved on.

Why “Just Make It Automatic” Is Not Trivial

Suggestions often surface: add GSM modules to CIUs, roll out full Advanced Metering Infrastructure (AMI) smart meters with two-way communication, or build apps that somehow push tokens. Each has real barriers:

Retrofitting millions of existing meters is expensive and logistically heavy.
True AMI (with GPRS/4G/NB-IoT) changes the security model and requires new communication modules, backend systems, and regulatory alignment.
Any solution that touches the meter’s credit path must remain STS-compliant and tamper-resistant.
Battery-powered or non-invasive approaches still need a reliable way to deliver the token bits to the meter without violating the isolation model.

Research papers have explored GSM-enabled CIUs that receive the SMS and automatically key the token. Other work looks at automated token-filling systems that dramatically cut load time and error rates. Hardware projects (including non-invasive approaches that sit between the CIU and the power line) are also being explored by independent makers precisely because the official path remains manual.

The Real Cost of the Status Quo

Manual 20-digit entry is more than an inconvenience. It creates:

Unnecessary downtime after purchase
Support burden on Kenya Power
Exclusion for users who struggle with the keypad process
A perception gap between Kenya’s advanced mobile-money ecosystem and its electricity last-mile experience

In 2026 we can pay for almost everything with a few taps. Buying electricity credit is nearly as seamless. Delivering that credit into the meter still requires a 1990s-era ritual.

The split metering + STS architecture solved important problems of revenue protection and operation in low-connectivity environments. Those problems have not disappeared. But the gap between “token purchased” and “power restored” is now one of the most visible friction points in Kenya’s energy system. Closing it without compromising the security and reliability that made prepaid metering successful is the real engineering challenge ahead.

Until then, keep spare alkaline batteries, use the same wall socket, and double-check those 20 digits.

Building KIVU — Lake Intelligence for Fish-Cage Farmers on Lake Victoria

Pritt Patrick — Wed, 23 Sep 2026 10:52:49 +0000

Fish cages on Lake Victoria can lose an entire stock overnight when dissolved oxygen crashes. Most farmers still rely on experience, visual checks, and late phone calls. We wanted something better.

KIVU is a lake-wide aquaculture and environmental intelligence platform we built as a team of five. It sits between the farmer’s phone and the lake: real-time telemetry, an explainable AI risk engine, geospatial zone intelligence, and expansion suitability signals — all backed by PostGIS and served from a single Go binary.

This is the story of what we built, how we structured it, and what we learned.

The problem
Cage aquaculture is expanding rapidly around Lake Victoria (Kenya, Uganda, Tanzania). The opportunity is huge, but so are the risks:

Dissolved oxygen can drop critically (< 3 mg/L) with little warning
Temperature spikes and algal events stress fish
Farmers lack accessible historical trends or early-warning systems
Satellite data (e.g. Copernicus) exists but rarely reaches the people who need it
Deciding where to place the next cage is still largely guesswork
We set out to build a practical decision-support layer — not another dashboard that only works in a lab.

What KIVU does
We organized the product into four clear levels:

Level Focus What the farmer gets

Cage Water quality telemetry Submit/receive DO, temp, pH, turbidity. AI Risk Engine runs automatically.
Farm Multi-cage overview Dashboard of cage status, aggregated metrics, and active alerts.
Lake Regional intelligence PostGIS zones (Homa Bay, Mbita, Rusinga…) with environmental metrics.
Expansion Site suitability Spatial scoring for new cage placement + rationale. Cross-cutting features:

Tech stack

Layer Choice Why
Backend Go 1.22 + Gin + sqlx Fast, simple, great for APIs
Database PostgreSQL 15 + PostGIS 3.3 Real geospatial types & indexes
Auth JWT (access + refresh) + bcrypt Stateless, farmer-friendly (phone)
Frontend Vanilla HTML/CSS/JS Zero build step, served by Gin
Geospatial GEOGRAPHY(Point/Polygon, 4326) Accurate distance & containment
External Copernicus + SMS client Satellite context + real alerts
Packaging Docker Compose One-command demo
Everything lives in one repo. docker compose up --build brings up PostGIS (with migrations + seed data) and the backend on port 8080. The same Go process serves both the API (/api/v1/...) and the frontend.

The AI Risk Engine (the interesting part)
We deliberately kept the risk engine rule-based and explainable. Farmers need to understand why an alert fired.

When a new reading is posted for a cage, the engine:

Pulls the latest ~10 readings
Scores against clear thresholds:
Dissolved oxygen < 3.0 mg/L → critical hypoxia (+50)
DO < 5.0 mg/L → moderate hypoxia (+25)
Three consecutive declining DO readings → deteriorating trend (+20)
Temperature anomalies / high turbidity contribute further
Produces:
Risk score
Risk level (low / medium / high / critical)
List of triggered factors
Human-readable recommendation
Confidence score
Can automatically create an alert (and optionally trigger SMS)
This design made demos reliable and the logic easy to discuss with domain experts. We can always layer ML models later; for a first version, transparency won.

Geospatial with PostGIS
Cages are stored as points:

location GEOGRAPHY(Point, 4326)
Lake zones are polygons. We use GiST indexes and queries such as:

ORDER BY ST_Distance(boundary, ST_SetSRID(ST_MakePoint($1, $2), 4326)::geography)
to find the nearest zone for expansion suitability. Seed data covers real-ish sectors around Homa Bay, Mbita Channel, and Rusinga.

Having proper geography types from day one saved us from the classic “just store lat/lon and hope” trap.

Backend structure (Go)
We followed a clean layout:

backend/
├── cmd/server/main.go
├── config/
├── database/ # migrations + seed
├── integrations/ # Copernicus, SMS
├── internal/
│ ├── handlers/
│ ├── middleware/ # CORS, logging, JWT
│ ├── models/
│ └── services/ # Auth, AI Risk, Alerts, Expansion, Copernicus sync
└── routes/
Key services:

AuthService — register/login, token issuance & rotation
AIRiskEngine — the scoring logic above
AlertsService — persistence + SMS hook
ExpansionService — zone suitability
CopernicusSyncService — background loop
The router also serves the static frontend, so a single binary (or container) is enough for a full demo.

Lessons we learned
Explainable beats black-box for domain users who have to trust the system with livestock.
PostGIS is worth the learning curve if your problem is inherently spatial.
Pairing on backend (two of us) kept the API and schema consistent under time pressure.
Serving static files from Gin removed an entire deployment concern for a hackathon/demo.
Seed data with realistic coordinates and deteriorating DO trends made the risk engine and maps come alive in demos.
Clear product levels (Cage → Farm → Lake → Expansion) helped both the team and anyone we pitched to.

What’s next
Possible directions:

Real sensor integrations (IoT)
Stronger ML models on top of the current rule engine
Multi-language SMS / USSD for last-mile reach
Deeper Copernicus / climate data layers
Mobile-first progressive web app
Final thoughts
KIVU started as a hackathon-style project, but the problem is real. Turning water-quality readings and open satellite data into timely, understandable signals for cage farmers is valuable work.

If you’re building in aquaculture, climate tech, geospatial systems, or just like clean Go + PostGIS architectures, we’d love to hear from you.

KIVU — smarter cages, healthier lakes.

XRadius: Building a Modern ISP & Wi-Fi Hotspot Billing Platform with Go, MikroTik, M-Pesa and WebSockets

Pritt Patrick — Wed, 12 Aug 2026 06:40:52 +0000

Running an ISP or public Wi-Fi hotspot in Kenya is more than putting up a router and connecting customers.

You need to manage customers, internet packages, payments, network access, routers, sessions, revenue, staff, and support — often across several systems.

That is the problem I wanted to solve with XRadius.

XRadius is an ISP and Wi-Fi hotspot billing platform designed for internet service providers and hotspot operators. The goal is simple:

Make it easier to sell internet, collect payments, manage networks, and give customers a seamless connection experience.

The problem

Imagine a customer arrives at a Wi-Fi hotspot and wants:

10 Mbps — 1 hour — KES 20

The traditional workflow might look something like this:

Customer selects a package.
They enter their phone number.
They initiate an M-Pesa payment.
They wait.
The operator checks whether payment arrived.
Someone activates the customer's internet access.
The customer refreshes the page and hopes it worked.

That experience can be frustrating for both the customer and the operator.

I wanted XRadius to make this process automatic.

What is XRadius?

XRadius is being built as a multi-tenant platform for ISP and Wi-Fi hotspot businesses.

At a high level:

                    ┌─────────────────────┐
                    │      XRadius        │
                    │   ISP Platform      │
                    └──────────┬──────────┘
                               │
          ┌────────────────────┼────────────────────┐
          │                    │                    │
          ▼                    ▼                    ▼
     Customers             Payments             Network
          │                    │                    │
          ▼                    ▼                    ▼
    Captive Portal          M-Pesa             MikroTik
                              │                    │
                              ▼                    ▼
                         Transactions          Internet

The platform brings these pieces together instead of requiring the operator to manage them independently.

Why Go?

The backend is being built with Go.

Go is particularly attractive for this kind of system because XRadius needs to handle several concurrent activities:

API requests
Payment callbacks
Customer sessions
Router communication
Background jobs
Notifications
WebSocket connections
Dashboard updates

Go's lightweight concurrency model makes it a good fit for an application that needs to manage many simultaneous connections and background operations.

The backend follows a modular architecture with components for authentication, customers, billing, payments, networking, dashboards, and notifications.

The technology stack

The current architecture includes technologies such as:

Go — backend/API
PostgreSQL — primary database
Redis — caching, queues and real-time state
MikroTik RouterOS API — network provisioning and control
M-Pesa Daraja API — payments
JWT — authentication
WebSockets — real-time communication
Docker — deployment and service orchestration

The system is designed so that additional payment providers and networking integrations can be added later.

The captive portal

One of the most important parts of XRadius is the customer-facing captive portal.

A customer should not need to understand anything about RADIUS, MikroTik, APIs, or payment callbacks.

They should simply see something like:

EXTREME SOLUTIONS

Plug In. Connect Up. Go Extreme.

Choose your package

10 Mbps
1 Hour
KES 20

[ Buy Now ]

After selecting the package, the customer enters their phone number and initiates payment.

The complicated infrastructure should happen behind the scenes.

M-Pesa + WebSockets

One of the features I'm particularly interested in is combining M-Pesa payment processing with WebSockets.

The flow looks like this:

Customer
   │
   │ Select package
   ▼
Captive Portal
   │
   │ HTTP request
   ▼
XRadius API
   │
   │ Initiate payment
   ▼
M-Pesa
   │
   │ Payment callback
   ▼
XRadius Backend
   │
   ├── Verify transaction
   ├── Update PostgreSQL
   ├── Update Redis
   └── Provision internet
            │
            ▼
        MikroTik
            │
            ▼
       Internet Access
            │
            ▼
        WebSocket
            │
            ▼
         Customer

Instead of making the customer repeatedly refresh the page, the frontend can maintain a WebSocket connection.

When the payment is confirmed, XRadius can immediately notify the customer:

Payment successful! Connecting you to the internet...

Then the customer can be redirected into their active internet session.

This makes the payment-to-connect experience feel much more like a modern application.

Real-time admin dashboard

WebSockets are not only useful for customers.

They can also make the administrator dashboard much more dynamic.

For example, an operator could see:

ONLINE USERS       127
ACTIVE PACKAGES     84
TODAY'S REVENUE     KES 18,450
ACTIVE ROUTERS       6
PAYMENTS TODAY      312

Instead of refreshing the dashboard every few seconds, important changes can be pushed to the browser in real time.

For example:

M-Pesa Payment Received
        ↓
Transaction Created
        ↓
Database Updated
        ↓
WebSocket Event
        ↓
Admin Dashboard

The revenue counter can update immediately.

The online-user count can change immediately.

A router going offline can trigger an alert immediately.

MikroTik integration

The network layer is where XRadius becomes more than a normal billing application.

The platform is designed to communicate with MikroTik routers through the RouterOS API.

This allows the billing system to interact with the actual network infrastructure.

For example:

Customer purchases package
          ↓
Payment confirmed
          ↓
XRadius determines package
          ↓
Bandwidth rules applied
          ↓
MikroTik receives configuration
          ↓
Customer gets internet access

This also opens the door to features such as:

Multiple router management
Online user monitoring
Bandwidth control
Session management
Hotspot provisioning
Router health monitoring
Automatic user disconnection after expiry

The goal is to move from manually managing routers to managing the network from one platform.

Bandwidth control

An internet package is not simply a price and duration.

It can also define network behavior.

For example:

Package	Speed	Duration	Price
Starter	5 Mbps	1 hour	KES 10
Standard	10 Mbps	3 hours	KES 25
Premium	20 Mbps	24 hours	KES 50

XRadius can use the package configuration to determine the appropriate bandwidth policy when provisioning a customer.

This creates a direct relationship between:

Payment → Package → Network Policy → Internet Access

Redis

Redis plays an important supporting role in the architecture.

Some information does not need to be repeatedly retrieved from PostgreSQL.

Redis can help with:

Caching
Session state
Temporary payment state
WebSocket-related state
Background job queues
Rate limiting
Short-lived data

For example, payment processing can involve several asynchronous steps.

Redis can help coordinate temporary state while PostgreSQL remains the source of truth for persistent financial records.

PostgreSQL

PostgreSQL acts as the primary persistent data store.

The domain model includes concepts such as:

Customers
Internet packages
Invoices
Payments
Routers
Hotspots
Transactions
Users
Businesses

This provides the foundation for reporting, billing history, customer management and auditing.

Multi-tenant architecture

One of the important goals of XRadius is to support multiple ISP and hotspot businesses from the same platform.

The basic concept is:

                    XRadius
                       │
        ┌──────────────┼──────────────┐
        │              │              │
        ▼              ▼              ▼
    Business A     Business B     Business C
        │              │              │
     Routers         Routers         Routers
     Customers       Customers       Customers
     Payments        Payments        Payments

Each business should be able to manage its own:

Customers
Packages
Routers
Payment accounts
Revenue
Staff
Network infrastructure

This creates the possibility of XRadius becoming a platform rather than simply software installed on one router.

Security matters

Because XRadius handles payments, customer information and network infrastructure, security cannot be an afterthought.

The architecture therefore needs to consider:

Secure password storage
JWT security
Role-based access control
API authentication
Rate limiting
Input validation
Payment verification
Secure secrets management
Audit logging
Database security
Router credential protection
WebSocket authentication
Secure Docker configuration
HTTPS/TLS

A compromised billing system could potentially become a compromised network.

That makes security one of the most important parts of the project.

The business model

The platform is being designed around a SaaS model for Kenyan ISP and hotspot operators.

An operator could sign up, configure their business, connect their payment account, configure internet packages and connect their MikroTik routers.

From there, they can manage their operation from the XRadius dashboard.

The broader vision is:

One platform for running an ISP or Wi-Fi hotspot business.

What makes the project interesting?

For me, the interesting part of XRadius is that it sits at the intersection of several technologies.

It combines:

Fintech

M-Pesa and payment processing.

Networking

MikroTik, bandwidth management, hotspots and sessions.

Backend engineering

Go, PostgreSQL, Redis and APIs.

Real-time systems

WebSockets and live dashboards.

SaaS

Multi-business architecture and subscription management.

These aren't isolated components.

They have to work together.

A payment needs to eventually become network access.

A network session needs to become billing information.

A customer action needs to trigger backend events.

A router problem needs to become an administrator notification.

That integration is where the real engineering challenge lies.

Where XRadius is heading

There are several areas I want to continue exploring:

Real-time M-Pesa payment status
Real-time admin dashboards
Multi-router management
Better bandwidth management
Automated router provisioning
Advanced revenue analytics
Customer notifications
Network health monitoring
Mobile applications
More payment providers
AI-assisted ISP analytics
Automated anomaly detection

The long-term goal isn't just to build another billing dashboard.

It's to build infrastructure that helps small and growing internet businesses operate more efficiently.

Final thoughts

Building XRadius has been an interesting journey because it forces software engineering and networking to meet in the real world.

A customer doesn't care that a payment callback went through an API.

They care that they paid and got internet.

An ISP operator doesn't care that a WebSocket event was emitted.

They care that their dashboard accurately shows who is online and how much they have earned.

That's the standard I'm aiming for with XRadius:

Hide the complexity. Automate the workflow. Make internet businesses easier to run.

And ultimately:

XRadius — Connect. Bill. Manage. Grow.

If you're interested in ISP infrastructure, MikroTik, RADIUS, M-Pesa integrations, Go, real-time systems, or building technology for African connectivity businesses, this is a project I'll be documenting as it evolves.

Building JONAM: Using Copernicus Earth Observation Data to Help Restore Lake Victoria's Fisheries

Pritt Patrick — Wed, 12 Aug 2026 06:22:47 +0000

"What if satellite data could help protect the livelihoods of millions who depend on Africa's largest lake?"

Last weekend, our team JONAM had the privilege of participating in the Kijani Space Hackathon, where we proudly secured 3rd place while tackling Challenge 2: Sustainable Fisheries & Blue Economy.

Rather than building another dashboard, we wanted to solve a real problem affecting millions of people around Lake Victoria: declining fish stocks caused by worsening water quality.

The Problem

Lake Victoria supports millions of people through fishing, transportation, agriculture, and tourism. However, over the years the lake has experienced:

Increasing water pollution
Poor water quality
Frequent algal blooms
Reduced fish breeding habitats
Declining fish populations

For fishing communities, these are not just environmental issues—they directly affect livelihoods, food security, and local economies.

Our question became:

Can Earth observation data help communities understand where water conditions are becoming unsuitable for fish before the problem becomes critical?

Our Solution: JONAM

JONAM is an AI-powered web application that combines satellite-derived environmental data with machine learning to monitor water quality and provide insights into conditions that may contribute to declining fish stocks.

Instead of relying solely on manual sampling—which is expensive and only covers small areas—our platform continuously analyses satellite observations covering the entire lake.

Why Copernicus?

To build JONAM, we integrated the KijaniBox API, which provides access to environmental datasets from the Copernicus Programme.

Copernicus is the European Union's Earth observation programme. It uses a constellation of Sentinel satellites together with in-situ observations to monitor Earth's atmosphere, land, and oceans.

For our project, we focused specifically on live water telemetry variables available through the KijaniBox platform.

1. Water Temperature

Satellites measure the thermal radiation emitted from the water surface to estimate temperature.

Temperature influences:

Fish metabolism
Oxygen availability
Fish breeding conditions

Abnormally warm water can reduce dissolved oxygen and stress aquatic ecosystems.

2. Turbidity

Turbidity measures how cloudy the water is.

Using reflected sunlight captured by optical sensors, satellites estimate suspended sediments and particles within the water.

High turbidity often indicates:

Soil erosion
Runoff after rainfall
Pollution entering rivers and lakes

Excessive turbidity limits sunlight penetration and disrupts aquatic life.

3. Chlorophyll-a

Chlorophyll-a is estimated from the colour of the water observed by satellite sensors.

It acts as an indicator of phytoplankton concentration.

Moderate levels indicate healthy productivity.

Very high concentrations may indicate harmful algal blooms, which:

Reduce oxygen
Produce toxins
Kill fish
Signal nutrient pollution

4. Precipitation

Rainfall estimates are generated by combining satellite observations with weather models.

Heavy rainfall often transports:

Agricultural fertilisers
Industrial waste
Urban runoff
Sediments

into Lake Victoria, increasing pollution and nutrient loading.

5. Wind Speed

Wind speed is estimated using atmospheric observations and numerical weather prediction models.

Wind affects:

Water mixing
Oxygen distribution
Surface circulation
Dispersion of pollutants

Strong winds can either improve oxygenation or spread polluted water to previously unaffected areas.

From Data to Action

JONAM analyses these environmental variables together instead of looking at each independently.

By learning relationships between:

Temperature
Turbidity
Chlorophyll-a
Precipitation
Wind speed

our AI model identifies environmental conditions associated with deteriorating water quality and declining fish habitats.

The platform presents these insights through an intuitive dashboard, enabling users to monitor changing conditions across Lake Victoria.

Why This Matters

Traditional water quality monitoring often depends on field teams collecting samples from a handful of locations.

Satellite observations provide:

Consistent coverage
Frequent updates
Large-scale monitoring
Lower operational costs
Historical trends for comparison

This makes environmental intelligence more accessible to researchers, governments, conservation organisations, and eventually fishing communities themselves.

The Hackathon Experience

The Kijani Space Hackathon challenged us to think beyond technology and focus on measurable environmental impact.

Throughout the event, we transformed Earth observation data into practical insights that could contribute toward healthier aquatic ecosystems and more sustainable fisheries.

We're incredibly proud that JONAM earned 3rd place in Challenge 2, but the experience reinforced something even more valuable:

Satellite data becomes truly powerful when transformed into decisions that improve people's lives.

What's Next?

Our vision for JONAM extends beyond the hackathon.

Future improvements include:

Real-time water quality alerts
Fish habitat suitability predictions
Pollution hotspot identification
Decision support for fisheries management
Mobile access for lakeside communities
Integration with IoT sensors for ground validation

Final Thoughts

Hackathons often end when prizes are awarded.

For us, this is just the beginning.

Lake Victoria's challenges require continuous innovation, and by combining Earth observation, AI, and accessible environmental data through the KijaniBox API, we hope JONAM can become one small step toward more sustainable fisheries and cleaner waters.

If you're interested in Earth observation, environmental AI, or geospatial technologies, we'd love to connect and continue building solutions that make a real-world impact.

The future of conservation isn't just in collecting more data—it's in turning that data into timely, actionable intelligence.

Intro.

Pritt Patrick — Thu, 02 Jul 2026 11:59:56 +0000

Hello guys, I am a cloud DevOps apprentice at zone01 Kisumu. I am an automation enthusiast and I am ready to learn more about DevOps and Go.