Forem: Sospeter Mong'are

The Stages of AI in Software Engineering - And Where We Are Today

Sospeter Mong'are — Wed, 15 Apr 2026 11:36:28 +0000

Software engineering hasn’t just evolved. It has accelerated.

In the last couple of years, the way we build software has changed more than most people realize. Many developers are still operating in older patterns, while the ground beneath them has already shifted.

To understand where we are going, it helps to break things down into stages.

Stage 1: Ask AI

This is where it started for most people.

AI was used like a smarter search engine. You would:

paste an error
ask for a function
get a quick fix

Nothing about your workflow really changed.

You were still:

thinking through the problem
designing the solution
writing most of the code

AI was just helping with syntax and speed.

Stage 2: AI in Your Editor

Then AI moved closer.

Instead of switching tabs, it started living inside your editor. It could:

autocomplete your thoughts
suggest full functions
understand your code context

This felt powerful. And it was.

But the control didn’t change.

You were still driving.
AI was just helping you move faster.

Stage 3: Describe the Problem

This is where the real shift began.

Instead of asking:
“How do I build this?”

You started asking:
“Here’s what I want. Build it.”

The focus moved away from code and into clarity.

You describe:

the feature
the behavior
the expected outcome

AI handles the implementation.

At this stage, your value is no longer how fast you can type.
It’s how clearly you can think.

Stage 4: Manage AI Agents (Where We Are Now)

We are no longer just working with a single AI.

We are starting to work with multiple agents at once.

Instead of writing code line by line, you:

assign tasks
run workflows in parallel
review outputs

One agent can build a feature.
Another writes tests.
Another refactors existing code.

This no longer feels like coding.

It feels like managing a team.

And that changes everything.

Stage 5: Autonomous AI Systems (What’s Next)

The next step is already taking shape.

Agents won’t just work in parallel.
They will work together.

A single request could trigger a full pipeline:

build
test
validate
deploy

With little to no human interruption.

Your role becomes:

defining requirements
setting boundaries
reviewing final outcomes

You are no longer in the loop at every step.
You step in when it matters.

Stage 6: Self-Evolving Systems (The Future)

This is where things get even more interesting.

Software will not just run.
It will improve itself.

Systems will:

learn from user behavior
adjust features automatically
optimize performance continuously
refine their own logic over time

Software becomes something closer to a living system.

Not static. Not finished. Always adapting.

What This Means for Engineers

The role of a software engineer is not disappearing.
But it is changing.

Less focus on:

writing every line of code

More focus on:

defining problems clearly
making architectural decisions
validating outcomes

The bottleneck is no longer coding speed.

It is thinking.

The Real Shift

AI didn’t remove the need for engineers.

It exposed something deeper:

If you cannot clearly explain what you want to build,
AI will build the wrong thing faster.

But if you can think clearly,
AI becomes a multiplier.

Final Thought

The best engineers in this new world will not be the fastest coders.

They will be the clearest thinkers.

Because in the end, AI executes.

Humans decide what is worth building.

Understanding SOLID Principles in Object-Oriented Programming

Sospeter Mong'are — Mon, 13 Apr 2026 14:08:02 +0000

When building software, especially in object-oriented languages like Java, writing code that works is only part of the job. The real challenge is writing code that is easy to maintain, extend, and scale over time. This is where SOLID principles come in.

SOLID is not about how many classes you should have. Instead, it is a set of five design principles that guide how you structure and organize your classes for better software quality.

What is SOLID?

SOLID is an acronym representing five key principles of object-oriented design:

Single Responsibility Principle
Open/Closed Principle
Liskov Substitution Principle
Interface Segregation Principle
Dependency Inversion Principle

These principles help developers reduce complexity, improve readability, and make systems easier to modify without breaking existing functionality.

1. Single Responsibility Principle (SRP)

A class should have only one reason to change, meaning it should handle only one responsibility.

For example, a class that manages user data should not also handle logging or database connections. Separating responsibilities ensures that changes in one area do not affect unrelated parts of the system.

This makes your code easier to debug and maintain.

2. Open/Closed Principle (OCP)

Software entities such as classes should be open for extension but closed for modification.

This means you should be able to add new functionality without changing existing code. Instead of modifying a class directly, you extend it or use abstractions.

This reduces the risk of introducing bugs into already tested code.

3. Liskov Substitution Principle (LSP)

Objects of a subclass should be able to replace objects of the parent class without affecting the correctness of the program.

In simple terms, if a class inherits from another, it should behave in a way that does not break expectations. If replacing a parent class with a child class causes errors, then the design violates this principle.

4. Interface Segregation Principle (ISP)

Clients should not be forced to depend on interfaces they do not use.

Instead of creating large, general-purpose interfaces, it is better to create smaller, more specific ones. This ensures that classes only implement what they actually need.

This leads to cleaner and more focused code.

5. Dependency Inversion Principle (DIP)

High-level modules should not depend on low-level modules. Both should depend on abstractions.

This means you should rely on interfaces or abstract classes rather than concrete implementations. It reduces tight coupling between components and makes your system more flexible.

Why SOLID Matters

Applying SOLID principles leads to:

Better code organization
Easier testing and debugging
Improved scalability
Reduced risk when making changes
More reusable components

Final Thoughts

SOLID principles do not tell you how many classes to create. Instead, they guide how those classes should behave and interact with each other.

By applying these principles consistently, you move from writing code that simply works to building systems that are robust, maintainable, and ready to grow with changing requirements.

Understanding AI Agents: Autonomous vs Semi-Autonomous Systems

Sospeter Mong'are — Wed, 08 Apr 2026 12:21:22 +0000

As Artificial Intelligence continues to evolve, the concept of an "agent" has become central to how intelligent systems are designed and deployed. From chatbots and virtual assistants to automated financial systems and robotics, agents are the building blocks behind many modern applications. To fully understand how these systems operate, it is important to start with a clear definition of what an AI agent is, and then explore the difference between autonomous and semi-autonomous agents.

What Is an AI Agent

An AI agent is a software system or program that is designed to perceive its environment, make decisions, and take actions in order to achieve a specific goal.

At its core, an agent has three main components:

Perception: The ability to gather information from its environment. This could be user input, API responses, sensor data, or database queries.
Decision-making: The logic or intelligence that allows the agent to analyze information and determine what action to take.
Action: The execution of tasks, such as sending a message, updating a database, calling an API, or triggering another process.

A simple example is a chatbot. It receives a message from a user, processes the input, decides on a response, and sends a reply. More advanced agents can handle complex workflows, learn from data, and adapt over time.

Agents can also be goal-driven, meaning they are designed not just to respond to inputs, but to actively pursue objectives. For instance, an agent might be tasked with increasing sales conversions, monitoring system health, or automating customer engagement.

Autonomous AI Agents

Autonomous AI agents are systems that operate independently with minimal or no human intervention. Once they are given a goal or set of objectives, they can plan, make decisions, and execute actions on their own.

Characteristics of Autonomous Agents

Autonomous agents are defined by a high level of independence. They can:

Make decisions without human approval
Adapt to changing environments
Continuously operate without supervision
Optimize their actions based on feedback and data

These agents often rely on advanced techniques such as machine learning, reinforcement learning, and real-time data processing to improve their performance over time.

Examples of Autonomous Agents

Automated trading systems that analyze markets and execute trades instantly
Self-driving vehicles that navigate roads and respond to traffic conditions
Network monitoring systems that detect and respond to threats without human input

Advantages

High efficiency and speed
Ability to operate at scale
Reduced need for human labor in repetitive tasks

Challenges

Higher risk due to lack of human oversight
Difficulty in handling unexpected or ambiguous situations
Ethical and accountability concerns

Because of these challenges, fully autonomous systems are often deployed in controlled environments or where the risks are manageable.

Semi-Autonomous AI Agents

Semi-autonomous AI agents operate with a combination of machine intelligence and human involvement. They can perform many tasks independently, but they require human input, validation, or approval at key stages.

Characteristics of Semi-Autonomous Agents

These agents are designed to assist rather than fully replace human decision-making. They typically:

Provide recommendations or suggestions
Execute tasks up to a certain point
Require human confirmation for critical actions
Work collaboratively with users

Examples of Semi-Autonomous Agents

Code assistants that suggest implementations while developers decide what to use
Customer support systems that draft replies for human agents to review
Financial systems that flag suspicious transactions for manual verification

Advantages

Lower risk due to human oversight
Better handling of complex or sensitive scenarios
Increased trust and accountability

Challenges

Slower than fully autonomous systems due to human involvement
Requires well-designed interaction between human and machine
May not scale as easily in high-demand environments

Semi-autonomous systems are widely used in real-world applications because they strike a balance between efficiency and control.

Key Differences Between Autonomous and Semi-Autonomous Agents

The distinction between these two types of agents lies primarily in control, decision-making, and risk management.

Aspect	Autonomous Agents	Semi-Autonomous Agents
Human involvement	Minimal or none	Required at key points
Decision-making	Fully independent	Shared with humans
Speed	High	Moderate
Risk level	Higher	Lower
Use cases	Automation at scale	Human-assisted workflows

When to Use Each Type

Choosing between autonomous and semi-autonomous agents depends on the context in which the system will operate.

Use Autonomous Agents When:

Tasks are repetitive and well-defined
Decisions are based on clear data patterns
Speed and scalability are critical
The risk of errors is low or manageable

Use Semi-Autonomous Agents When:

Decisions require human judgment or context
The system operates in sensitive domains such as finance or healthcare
Accountability and trust are important
Errors could have significant consequences

Practical Perspective for Developers

For developers building systems such as APIs, backend services, or automation platforms, understanding this distinction is crucial.

Autonomous agents are ideal for background processes such as data synchronization, automated notifications, or system monitoring. These tasks benefit from speed and do not usually require human validation.

Semi-autonomous agents are better suited for user-facing features such as messaging platforms, financial transactions, or content generation tools. In these cases, allowing a human to review or approve actions helps prevent costly mistakes.

For example, in a WhatsApp API platform, an autonomous agent might automatically send scheduled messages or respond to frequently asked questions. A semi-autonomous agent, on the other hand, might generate message drafts that a user reviews before sending to customers.

Conclusion

AI agents are powerful tools that enable systems to act intelligently and achieve goals with minimal manual effort. The distinction between autonomous and semi-autonomous agents lies in how much control is given to the system versus the human.

Autonomous agents focus on independence, efficiency, and scalability, while semi-autonomous agents emphasize collaboration, oversight, and safety. Understanding when and how to use each type is essential for building reliable, effective, and responsible AI-driven systems.

Testing M-PESA STK Push Callbacks Locally Without Exposing Your Server

Sospeter Mong'are — Wed, 18 Mar 2026 13:02:35 +0000

If you've ever built an M-PESA STK Push integration, you've probably hit this wall: M-PESA needs a publicly accessible callback URL to send payment confirmations, but your app is running on localhost. How do you test this without deploying every single time?

In this guide I'll show you a simple approach using webhook.site and a small Node.js poller script that automatically forwards M-PESA callbacks to your local machine.

What We're Building

When a user completes an STK Push payment, M-PESA sends a POST request to your callback URL with the payment result. Normally that URL has to be publicly accessible. Since localhost isn't public, we'll use webhook.site as a middleman - it catches the callback from M-PESA, and our poller script picks it up and forwards it to our local app automatically.

The flow looks like this:

M-PESA → webhook.site → our poller script → localhost

Prerequisites

Node.js installed on your machine
Your Laravel app running locally
An M-PESA Daraja API account (sandbox or production)
Basic understanding of how STK Push works

Step 1 - Get a webhook.site URL

Go to webhook.site and you'll immediately get a unique URL that looks like this:

https://webhook.site/f5d500b7-1196-42ef-8ecd-c906e49f7df36

The part after the last slash is your token. Copy it - you'll need it shortly. Keep this tab open so you can see incoming requests.

Step 2 - Store the Callback URL in Your .env

Instead of hardcoding the webhook.site URL in your code, store it in your .env file so you can swap it out easily without touching any code:

MPESA_CALLBACK_URL=https://webhook.site/f5d500b7-1196-42ef-8ecd-c906e49f7df36

On production you simply leave this variable out and it falls back to your real callback URL automatically.

Step 3 - Update Your ProcessController

In your M-PESA ProcessController where you build the STK Push request, find the CallBackURL line and update it like this:

"CallBackURL" => env('MPESA_CALLBACK_URL') ?: route('ipn.MPesa'),

What this does is simple. If MPESA_CALLBACK_URL is set in your .env it uses that. If it's not set, it falls back to your real route. This means locally it points to webhook.site, and on production it uses your actual callback route - no code changes needed when you deploy.

Step 4 - Create the Poller Script

This is the magic piece. Create a file called forwarder.js anywhere on your machine - I put mine in the project root. Paste this in:

const WEBHOOK_TOKEN = 'f5d500b7-1196-42ef-8ecd-c906e49f7df36'; // your token here
const LOCAL_URL = 'http://localhost:8000/ipn/mpesa';
const POLL_INTERVAL = 5000; // check every 5 seconds

let lastSeenId = null;

async function poll() {
    try {
        const res = await fetch(`https://webhook.site/token/${WEBHOOK_TOKEN}/requests?sorting=newest&per_page=1`);
        const data = await res.json();

        if (!data.data || data.data.length === 0) return;

        const latest = data.data[0];

        if (latest.uuid === lastSeenId) return; // already processed this one

        lastSeenId = latest.uuid;

        const body = latest.content;
        console.log('New callback received! Forwarding to local app...');
        console.log(body);

        const forward = await fetch(LOCAL_URL, {
            method: 'POST',
            headers: { 'Content-Type': 'application/json' },
            body: body
        });

        console.log('Done. Local app responded with status:', forward.status);

    } catch (err) {
        console.error('Error:', err.message);
    }
}

setInterval(poll, POLL_INTERVAL);
console.log('Watching webhook.site for incoming callbacks...');

Replace the WEBHOOK_TOKEN value with your own token from Step 1. The LOCAL_URL should match whatever route your app uses for the M-PESA IPN.

Step 5 - Run Everything

You'll need two terminals open.

Terminal 1 - start your Laravel app:

php artisan serve

Terminal 2 - start the poller:

node forwarder.js

You should see this message in Terminal 2:

Watching webhook.site for incoming callbacks...

Step 6 - Trigger a Test Payment

Go through your app's deposit flow and trigger an STK Push. Enter your phone number and hit pay. You'll get the prompt on your phone.

Once you complete the payment, here's what happens automatically:

M-PESA sends the callback to webhook.site
Your poller picks it up within 5 seconds
It forwards the full payload to your local app
Your local app processes it and updates the database

You'll see something like this in Terminal 2:

New callback received! Forwarding to local app...
{"Body":{"stkCallback":{"ResultCode":0,"CheckoutRequestID":"ws_CO_xxxxx",...}}}
Done. Local app responded with status: 200

And your database gets updated just like it would in production.

Why Not Just Use ngrok?

Ngrok is the most common answer to this problem and it works well. However if you're running a licensed script, adding a new public URL can trigger a second domain detection and invalidate your license. The webhook.site approach avoids this completely since your app never gets a new public URL - only the callback endpoint changes temporarily, and only in your local .env.

Cleaning Up After Testing

When you're done testing, remove MPESA_CALLBACK_URL from your .env or comment it out:

# MPESA_CALLBACK_URL=https://webhook.site/f5d500b7-1196-42ef-8ecd-c906e49f7df36

Your app will fall back to the real route automatically. Stop the forwarder.js script and you're done. Nothing was changed in your codebase, nothing gets pushed to production.

Summary

The whole setup takes about 5 minutes and gives you a proper local testing loop for M-PESA callbacks without ngrok, without deploying, and without touching your production environment. The poller script is lightweight, requires no dependencies beyond Node.js, and you can reuse the same approach for any other payment gateway callback - just change the LOCAL_URL to point to the right IPN route.

How to Run Multiple PHP Versions on Windows and Switch Easily

Sospeter Mong'are — Sun, 15 Mar 2026 12:45:08 +0000

When working on modern PHP projects like those built with Laravel, you will eventually run into version conflicts.

One project may require PHP 8.3, while another older project may still run on PHP 8.1 or 8.2. If your system only has one PHP version installed, you will constantly run into errors like:

Composer detected issues in your platform:
Your Composer dependencies require a PHP version ">= 8.3.0".
You are running 8.2.12.

Instead of reinstalling PHP every time you switch projects, the better solution is to install multiple PHP versions and switch between them instantly.

One of the easiest ways to achieve this on Windows is by using Scoop, a lightweight package manager designed for developers.

Below is a simple and clean setup.

1. Install Scoop

Open PowerShell and run:

Set-ExecutionPolicy RemoteSigned -Scope CurrentUser
irm get.scoop.sh | iex

Confirm installation:

scoop --version

Scoop installs tools into your user directory and avoids the common permission problems that occur with traditional installers.

2. Add the Versions Bucket

Scoop organizes packages using "buckets". To install multiple PHP versions, you need the versions bucket.

scoop bucket add versions

This bucket contains packages like:

php81
php82
php83

3. Install Multiple PHP Versions

You can now install any PHP version you need.

Example:

scoop install php82
scoop install php83

Check installed packages:

scoop list

At this point both PHP versions exist on your system, but only one will be active at a time.

4. Switch Between PHP Versions

To switch to PHP 8.3:

scoop reset php83

To switch to PHP 8.2:

scoop reset php82

Verify the active version:

php -v

This instantly updates your terminal environment.

5. Running Your Laravel Project

Once the correct version is active, you can start your project normally:

php artisan serve

If the project requires PHP 8.3, switching to php83 will resolve the platform check error.

Why This Approach Is Powerful

Modern development environments rarely use a single runtime version.

You may have projects such as:

Legacy project running PHP 8.1
Production system using PHP 8.2
New Laravel 11 applications requiring PHP 8.3

Using Scoop allows you to move between these environments instantly without reinstalling anything.

Bonus: Install Other Developer Tools

Scoop can also install common development tools:

scoop install composer
scoop install nodejs
scoop install git

This creates a clean development environment that is easy to maintain and update.

Final Thoughts

Managing multiple PHP versions used to be complicated on Windows. With Scoop, the process becomes simple and developer friendly.

Instead of fighting your environment, you can focus on building applications and switching versions only when necessary.

For backend developers working with frameworks like Laravel, this setup saves time and prevents version related errors during development.

M-PESA DARAJA API - C2B Integration Guide

Sospeter Mong'are — Fri, 13 Mar 2026 09:42:47 +0000

Introduction

If you are building a web or mobile app that needs to receive payments from M-PESA customers in Kenya, the Safaricom Daraja API is the tool you need. This guide will walk you through everything from scratch no prior API experience required.

By the end of this guide, you will understand:

What the C2B API is and how it works
How to set up and test it in the sandbox using Postman
What ValidationURL and ConfirmationURL do
How to take your integration live

What is C2B?

C2B stands for Customer to Business. It refers to the flow of money from an individual customer to your business. When a customer pays your Paybill or Till number via M-PESA, that is a C2B transaction.

The C2B API allows your application to receive real-time notifications every time a payment comes in, so you can automate things like:

Marking an order as paid
Sending a payment receipt to the customer
Updating your accounting system automatically

What is Daraja?

Daraja (which means "bridge" in Swahili) is Safaricom's developer portal that gives you access to the M-PESA API. It provides a sandbox (testing) environment where you can simulate payments without using real money, and a production environment for real transactions.

Portal URL: https://developer.safaricom.co.ke

PART ONE: SANDBOX TESTING

Before using real money, Daraja gives you a sandbox environment to safely test your integration. This is where you should always start.

STEP 1 - Create a Daraja Account & App

Set up your developer profile

Go to https://developer.safaricom.co.ke and click Sign Up
Fill in your details and verify your email address
Once logged in, click "My Apps" in the top navigation menu
Click "Create Sandbox App" - give it any name (e.g. "MyShopC2B")
Under the products section, check "M-Pesa Sandbox" to enable sandbox APIs
Click "Create App"

Your app will now appear in the "My Apps" section. Click on it and you will see two important values:

Key	Description
Consumer Key	Acts like your app's username for the API
Consumer Secret	Acts like your app's password for the API

💾 Save These! Copy your Consumer Key and Consumer Secret somewhere safe. You will need them for every API call.

STEP 2 - Get an Access Token

Authenticate before making any API call

Every single API request to Daraja requires an access token. Think of it like a temporary password that proves your identity. It expires after 1 hour and you need to generate a new one.

In Postman:

Method: GET
URL: https://sandbox.safaricom.co.ke/oauth/v1/generate?grant_type=client_credentials

Go to the Authorization tab in Postman:

Auth Type: Basic Auth
Username: paste your Consumer Key
Password: paste your Consumer Secret

Click Send. You should get a response like this:

{
  "access_token": "SGWcJPtNtYNPGm1DqBNqZZZZZZ",
  "expires_in": "3599"
}

📋 Copy It! Copy the access_token value. You will paste it in the Authorization header of every request below.

STEP 3 - Understanding Your Callback URLs

The heart of how C2B notifications work

Before registering your URLs, it is important to understand what each one does. When a customer makes a payment, Safaricom contacts your server at two different points in the payment flow:

📱 Customer Pays  →  🔍 ValidationURL  →  ✅ ConfirmationURL
  (Sends money)      ("Should I allow    ("Payment done,
                          this?")          record it!")

ValidationURL - "Should I allow this payment?"

This is called before the payment is processed. Safaricom sends you the payment details and waits for your response. You can accept or reject the payment based on your own business logic - for example, checking if the account number the customer entered actually exists in your system.

You respond with one of the following:

// Accept the payment
{ "ResultCode": "0", "ResultDesc": "Accepted" }

// Reject the payment
{ "ResultCode": "C2B00012", "ResultDesc": "Rejected" }

⚠️ Note: ValidationURL is optional. If you set ResponseType to "Completed" when registering, Safaricom skips validation and auto-accepts all payments. This is recommended for beginners.
Validation URL is the URL that receives the validation request from API upon payment submission. The validation URL is only called if external validation on the registered short code is enabled.
(By default, External Validation is disabled)

ConfirmationURL - "Payment went through, save the details"

This is called after the payment has been successfully processed. At this point, you cannot reject the payment - it has already gone through. This is where your app should record the transaction, update a database, send a receipt, or trigger any other business logic.

Feature	ValidationURL	ConfirmationURL
When called	BEFORE payment is processed	AFTER payment is processed
Purpose	Accept or reject the payment	Record and act on the payment
Your response matters?	YES - can block the payment	NO - informational only
Required?	Optional	Yes, always required

🏪 Real-world analogy: Think of it like a supermarket checkout. The ValidationURL is the cashier checking if your loyalty card is valid before ringing up. The ConfirmationURL is the receipt printer - it just records that the sale happened.

STEP 4 - Get a Free Callback URL for Testing

Use webhook.site to capture callbacks

Your ValidationURL and ConfirmationURL must be publicly accessible HTTPS endpoints. For sandbox testing, you do not need a real server - you can use a free tool called webhook.site.

Go to https://webhook.site in your browser
You will instantly get a unique URL like: https://webhook.site/abc-123-xyz
Copy that URL - you will use it as both your ValidationURL and ConfirmationURL for testing
Leave the webhook.site tab open. Callbacks from Safaricom will appear here in real time

🚫 URL Rules: Never use words like "MPesa", "M-Pesa", or "Safaricom" in your URLs - the system will block them. Also, localhost URLs will not work. Always use a proper HTTPS URL.

STEP 5 - Register Your Callback URLs

Tell Safaricom where to send payment notifications

Now you will call the Register URL API to link your callback URLs to your Paybill shortcode.

In Postman:

Method: POST
URL: https://sandbox.safaricom.co.ke/mpesa/c2b/v1/registerurl

Headers tab - add these two headers:

Header Key	Header Value
Authorization	`Bearer YOUR_ACCESS_TOKEN` (paste the token from Step 2)
Content-Type	`application/json`

Body tab - select "raw" and "JSON", then paste:

{
  "ShortCode": "600584",
  "ResponseType": "Completed", // Either Cancelled or Completed
  "ConfirmationURL": "https://webhook.site/your-unique-url",
  "ValidationURL": "https://webhook.site/your-unique-url"
}

Field	Explanation
ShortCode	The sandbox test Paybill number (600584 is the default sandbox shortcode)
ResponseType	"Completed" means skip validation and auto-accept all payments
ConfirmationURL	Your webhook.site URL - where Safaricom sends payment confirmations
ValidationURL	Your webhook.site URL - where Safaricom asks for approval (optional here)

A successful response looks like:

{
  "OriginatorCoversationID": "...",
  "ResponseCode": "0",
  "ResponseDescription": "success"
}

STEP 6 - Simulate a C2B Payment

Pretend a customer is paying you

Now for the fun part - you will simulate a customer sending money to your Paybill. Safaricom provides a test phone number you can use.

In Postman:

Method: POST
URL: https://sandbox.safaricom.co.ke/mpesa/c2b/v1/simulate

Use the same Authorization header as before, then paste this JSON body:

{
  "ShortCode": "600584",
  "CommandID": "CustomerPayBillOnline",
  "Amount": "100",
  "Msisdn": "254708374149",
  "BillRefNumber": "INV001"
}

Field	Explanation
ShortCode	Your sandbox Paybill number
CommandID	Use `"CustomerPayBillOnline"` for Paybill, or `"CustomerBuyGoodsOnline"` for Till
Amount	The amount the simulated customer is paying (in KES)
Msisdn	The test customer phone number - always use `254708374149` in sandbox
BillRefNumber	The account reference - e.g. an invoice number or order ID

STEP 7 - Check Your Callback

See what your app would receive

After sending the simulation request, go to your webhook.site tab. Within a few seconds, you should see a POST request arrive. This is exactly the payload your real server would receive when a customer pays.

It will look something like this:

{
            "TransactionType": "Pay Bill",
            "TransID": "UCB030CBG1",
            "TransTime": "20260311161727",
            "TransAmount": "1.00",
            "BusinessShortCode": "600991",
            "BillRefNumber": "account001",
            "InvoiceNumber": "",
            "OrgAccountBalance": "4635316.60",
            "ThirdPartyTransID": "",
            "MSISDN": "bbff37cea44ac0b2d964ee0dfb8d2df8513dc7ba1b36129a929fc3fbd6dd4af4",
            "FirstName": "John"
}

Field	Value	Explanation
`TransactionType`	`Pay Bill`	The type of transaction. Will be "Pay Bill" for Paybill or "Buy Goods" for Till numbers
`TransID`	`UCB030CBG1`	Unique M-PESA transaction ID. Use this as your reference to avoid processing the same payment twice
`TransTime`	`20260311161727`	Timestamp of the transaction in `YYYYMMDDHHmmss` format. This one means 11 March 2026 at 16:17:27
`TransAmount`	`1.00`	The amount the customer paid in KES
`BusinessShortCode`	`600991`	Your Paybill or Till number that received the payment
`BillRefNumber`	`account001`	The account number the customer entered when paying. Use this to identify which customer or order the payment belongs to
`InvoiceNumber`	(empty)	Optional invoice number. Usually empty for most C2B transactions
`OrgAccountBalance`	`4635316.60`	Your Paybill account balance after this transaction was processed
`ThirdPartyTransID`	(empty)	Used in some integrations for a third-party reference. Usually empty
`MSISDN`	`bbff37c...`	The customer's phone number. In sandbox it is returned as a hashed/masked value for privacy.
`FirstName`	`John`	The first name of the customer as registered on M-PESA

💡 Tip: The three most important fields to save in your database are TransID (to prevent duplicate processing), BillRefNumber (to identify the customer/order), and TransAmount (to confirm the correct amount was paid).

In a real application, you would read this JSON payload and use the TransAmount, BillRefNumber, and MSISDN fields to update your database and send a receipt to the customer.

⚠️ Sandbox Note: Sandbox callbacks can sometimes be unreliable. If your webhook.site does not receive anything after 30 seconds, try the simulation again. This is a known sandbox issue.

Full C2B Flow Recap

Step	Action	What Happens
1	Get Token	You authenticate with your Consumer Key & Secret and receive a temporary access token
2	Register URLs	You tell Safaricom where to send payment notifications
3	Customer Pays	A real or simulated customer sends money to your Paybill or Till number
4	Validation	Safaricom hits your ValidationURL asking "should I accept this?" (optional)
5	Confirmation	Safaricom hits your ConfirmationURL with the full payment details
6	Your App Acts	Your server reads the payload and updates the database, sends a receipt, etc.

PART TWO: GOING LIVE

Once your sandbox integration is working correctly, you are ready to go live and process real M-PESA transactions.

Prerequisites Before Going Live

Make sure you have all of the following before applying for live credentials:

A working sandbox integration - all steps above tested and confirmed working
A registered and verified Paybill or Till Number from Safaricom
An active Safaricom G2 Business Admin account (used to verify your shortcode)
A real publicly accessible HTTPS server URL (not localhost, not webhook.site) for your callback URLs
Company documentation: Certificate of incorporation, KRA PIN, and directors' IDs (for businesses)

🏢 Get a Paybill First: To get a Paybill number, visit a Safaricom shop with your company registration documents. For a Till number, you can apply via the Safaricom self-onboarding portal. Processing takes 24–72 hours.

Step 1 - Register on the Safaricom G2 Portal

The G2 portal (https://org.ke.mpesa.com) is Safaricom's business management platform. You need an account here so Daraja can verify you own the Paybill or Till number you want to use.

Send an email to M-PESABusiness@safaricom.co.ke requesting a Business Admin account
Attach required documents: company registration certificate, KRA PIN, directors' IDs, and a signed board resolution
Safaricom will create your G2 account and send login credentials
Log in, change your password, and create an "assistant role" user - these credentials will be used in the next step

Step 2 - Confirm Your Sandbox Integration is Solid

Before applying to go live, make sure all of the following are working in sandbox:

Access token generation is working
URL registration returns a success response
Simulated payments are triggering callbacks to your server
Your server is responding with the correct 200 OK responses
Your database or backend is correctly parsing and saving the callback payload

Step 3 - Click "Go Live" on the Daraja Portal

Log into https://developer.safaricom.co.ke
Go to "My Apps" and open your app
Click the "Go Live" button
Select "Verification by Shortcode" as the method
Enter your Paybill/Till shortcode and your G2 assistant user credentials
Select the API products you need (e.g. C2B)
Upload your test cases - a document showing what you tested and the results
Submit your request

⏱️ Approval Time: Safaricom typically takes 24–72 hours to review and approve your live request. You will receive your production credentials by email once approved.

Step 4 - Replace Sandbox Credentials with Live Ones

Once approved, update your application to use production values:

What to Change	Sandbox → Production
API Base URL	`sandbox.safaricom.co.ke` → `api.safaricom.co.ke`
Consumer Key	Sandbox key → New live Consumer Key
Consumer Secret	Sandbox secret → New live Consumer Secret
ShortCode	`600584` (test) → Your actual Paybill/Till number
Callback URLs	webhook.site URLs → Your real HTTPS server URLs

Step 5 - Test a Small Live Transaction

After switching to production credentials, do a small test with real money (e.g. KES 1) to confirm everything works end to end:

Pay your Paybill from a real M-PESA number
Confirm your ConfirmationURL receives the callback
Verify your database is updated correctly
Check that the customer receives the expected response or receipt

📝 Keep Logs: Always log every transaction in the early stages of going live. Implement retry logic in case of failed callbacks - Safaricom may occasionally retry if your server is slow to respond.

Common Mistakes to Avoid

#	❌ Do NOT do this	✅ Do this instead
1	Include "MPesa" or "Safaricom" in your callback URLs	Use neutral words in your URLs e.g. `/payment/confirm`
2	Use localhost or 127.0.0.1 as your callback URL	Host your app or use a tunneling tool like Ngrok (sandbox only)
3	Use webhook.site/ngrok URLs in production	Use a real, stable HTTPS server in production
4	Apply for all products without knowing what you need	Plan ahead - decide which APIs you need before going live
5	Forget to renew your access token every hour	Generate a fresh token on each session or add auto-renewal logic
6	Ignore the callback response format	Always respond with `200 OK` and valid `ResultCode`/`ResultDesc`

Useful Resources

Resource	URL
Daraja Developer Portal	https://developer.safaricom.co.ke
Daraja API Documentation	https://developer.safaricom.co.ke/APIs
Safaricom G2 Business Portal	https://org.ke.mpesa.com
Test Callback Tool	https://webhook.site
M-PESA Business Email	M-PESABusiness@safaricom.co.ke

If you need payment integrations, You can reach out to me on email.

Happy building!

Understanding APIs: Core Knowledge Every Developer Should Have

Sospeter Mong'are — Mon, 09 Mar 2026 20:10:20 +0000

Application Programming Interfaces (APIs) are the backbone of modern software. They enable different applications and services to communicate with each other, exchange data, and perform actions across systems. Whether you are working in frontend, backend, or product development, understanding how APIs work is essential.

Below are the key concepts every developer should understand when learning APIs.

1. REST

Most modern APIs follow the REST (Representational State Transfer) architecture. REST defines how resources are structured and accessed over the web. In a REST API, resources such as users, payments, or products are accessed through endpoints.

Example:

GET /users
GET /orders/123

REST helps maintain consistency and makes APIs easier to understand and use.

2. HTTP Methods

HTTP methods define the type of action you want to perform on a resource. The most common methods include:

GET - Retrieve data from the server
POST - Create a new resource
PUT or PATCH - Update an existing resource
DELETE - Remove a resource

Understanding when to use each method is fundamental when building or consuming APIs.

3. Status Codes

Status codes tell you the outcome of an API request. They help developers quickly determine whether a request succeeded or failed.

Common examples include:

200 - Request successful
201 - Resource created successfully
400 - Bad request
401 - Unauthorized
404 - Resource not found
500 - Server error

Learning how to interpret these codes is crucial for debugging integrations.

4. JSON

Most APIs use JSON (JavaScript Object Notation) as the format for exchanging data. JSON is lightweight and easy for both humans and machines to read.

Example response:

{
  "id": 101,
  "name": "John Doe",
  "email": "john@example.com"
}

Developers should be comfortable reading, writing, and validating JSON structures.

5. Authentication and Authorization

APIs must ensure that only authorized users or systems can access them. Authentication verifies identity, while authorization determines what actions are allowed.

Common methods include:

API Keys
OAuth 2.0
JWT (JSON Web Tokens)
Basic Authentication

Many business APIs rely heavily on authentication mechanisms, such as the Stripe API, Twilio API, and M-Pesa Daraja API.

6. Headers

HTTP headers provide additional information about the request or response.

Common headers include:

Authorization - used to pass authentication tokens
Content-Type - defines the format of the request body
Accept - indicates the expected response format

Understanding headers helps you control how APIs process requests.

7. Request and Response Structure

An API request can contain several components:

Path parameters
Query parameters
Request body
Headers

Example request:

GET /transactions?limit=10

The response typically returns structured data along with a status code.

8. Error Handling

Well-designed APIs return clear error messages when something goes wrong.

Example:

{
  "error": "invalid_request",
  "message": "Missing required field"
}

Understanding error responses helps developers quickly diagnose and fix issues during integration.

9. Pagination

When APIs return large datasets, they often split results into smaller pages.

Common parameters include:

limit
offset
cursor

Example:

GET /transactions?limit=20&offset=40

Pagination ensures efficient data retrieval without overloading the system.

10. Rate Limiting

To protect infrastructure, many APIs limit how many requests a client can make within a given time period.

If the limit is exceeded, the server may return:

429 Too Many Requests

Developers must design their systems to handle rate limits gracefully.

11. Webhooks

Webhooks allow systems to receive real-time notifications when an event occurs, instead of constantly polling an API.

For example, a payment service may send a webhook when a payment is completed. This pattern is widely used in platforms like the Stripe API.

12. API Documentation

Good documentation is essential when working with APIs. Many APIs use tools like Swagger, Postman, or the OpenAPI Specification to clearly describe endpoints, parameters, and responses.

Being able to read and interpret API documentation is a critical developer skill.

Conclusion

APIs power the digital world. From payment processing to messaging services and cloud platforms, they enable systems to interact seamlessly.

For anyone building modern applications, understanding REST, HTTP methods, status codes, JSON, authentication, headers, pagination, rate limits, and webhooks is not optional. It is foundational knowledge that every developer should master.

What is Vite

Sospeter Mong'are — Wed, 18 Feb 2026 09:47:07 +0000

If you just downloaded a React project and saw something like:

npm run dev

And then an error mentioning vite, you might be wondering:

What exactly is Vite?

Let us break it down in simple terms.

What Is Vite?

Vite is a tool that helps you run and build modern frontend applications like React, Vue, or plain JavaScript apps.

You can think of it as:

A development server
A build tool
A translator for modern JavaScript

All combined into one.

Why Do We Need Vite?

Modern frontend code includes things like:

JSX (used in React)
TypeScript
ES Modules
CSS imports inside JavaScript
Modern JavaScript features

Browsers do not fully understand all of this directly.

Vite takes your modern code and converts it into something the browser can understand.

Without a tool like Vite, your React app would not run properly in the browser.

What Does Vite Actually Do?

When you run:

npm run dev

Vite:

Starts a local development server
Usually something like:
http://localhost:5173
Loads your app into the browser
Watches your files for changes
Automatically refreshes the browser when you save changes

This makes development fast and smooth.

Simple Analogy

Imagine building a car:

React is the engine components
Your code is the raw material
The browser is the driver
Vite is the factory that assembles everything so the car can run

Without the factory, the parts do not become a working car.

Is Vite Part of React?

No.

React is just a JavaScript library for building user interfaces.

It does not:

Start a server
Compile files
Bundle your code
Optimize your app for production

Vite is what makes your React project actually run during development and prepares it for deployment.

Why Is Vite Popular?

Vite is popular because it is:

Very fast
Simple to configure
Lightweight
Easy to set up

Compared to older tools like Webpack, Vite starts almost instantly and reloads changes much faster.

What Happens If Vite Is Missing?

If you see an error like:

'vite' is not recognized as an internal or external command

It usually means:

You have not installed project dependencies yet.

The fix is usually:

npm install
npm run dev

Final Thoughts

If you are building modern frontend apps, Vite is the tool that:

Runs your app locally
Converts modern code to browser ready code
Makes development faster
Prepares your app for production

In short:

Vite is the engine that makes your frontend project come alive.

The Engineer as a Decision Maker, Not a Developer

Sospeter Mong'are — Wed, 11 Feb 2026 08:43:49 +0000

For years, the software industry has romanticized the image of the engineer as someone who writes elegant code, masters frameworks, and ships features at lightning speed. But the most valuable engineers today are not defined by how fast they type or how many languages they know.

They are defined by the quality of their decisions.

The shift from developer to decision maker is what separates average engineers from high impact engineers. And in a world where AI can generate code in seconds, this shift is no longer optional. It is essential.

Code Is a Tool. Decisions Create Value.

A junior developer focuses on implementation:

How do I build this?
Which syntax should I use?
How do I fix this error?

A decision making engineer asks different questions:

Should we build this at all?
What problem are we actually solving?
Is this the simplest solution?
What are the long term consequences?

The difference is subtle but powerful.

Code is the output. Decisions determine whether that output is useful, scalable, secure, and aligned with business goals.

An engineer who understands tradeoffs between performance and cost, speed and maintainability, abstraction and simplicity becomes far more valuable than someone who only knows how to implement tickets.

Every Line of Code Is a Liability

Writing code feels productive. But every line added is something that must be maintained, tested, debugged, documented, and eventually refactored.

A decision driven engineer understands that sometimes the best decision is:

Reuse instead of rebuild.
Integrate instead of invent.
Simplify instead of scale prematurely.
Delete instead of add.

Strong engineers reduce complexity. They do not increase it just to prove skill.

They think in systems, not just scripts.

Technical Choices Are Business Decisions

Choosing a database is not just a technical act. It affects:

Hosting costs
Scaling strategy
Hiring requirements
Vendor lock in
Performance under growth

Choosing to microservice too early can slow a startup. Choosing to ignore observability can cost days in downtime. Choosing the wrong payment flow can affect revenue.

Engineers who understand that architecture impacts money, users, and growth move from being implementers to strategic contributors.

They stop waiting for instructions. They start shaping direction.

Decision Making Requires Context

You cannot make strong engineering decisions without understanding:

The product vision
The customer pain points
The revenue model
The team capacity
The timeline constraints

This is why the best engineers attend product meetings, ask business questions, and care about metrics.

They do not hide behind code.

They know that a technically perfect solution that misses market timing is a failure.

AI Is Raising the Bar

With AI tools generating boilerplate, scaffolding APIs, and even debugging, the value of raw coding skill is decreasing.

The competitive advantage is now:

Problem framing
Tradeoff analysis
Risk evaluation
Architectural thinking
Clear communication

Anyone can generate code.

Not everyone can decide what should be generated.

From Task Taker to Owner

A developer waits for a ticket.

A decision making engineer asks:

What outcome are we targeting?
Is this the highest priority problem?
Is there a faster way to deliver impact?
What will break in six months if we do this?

Ownership changes everything.

Instead of “I implemented what I was told,” the mindset becomes, “I am responsible for the result.”

That shift transforms careers.

How to Become a Decision Driven Engineer

Study tradeoffs, not just syntax.
Learn why systems fail. Learn scaling patterns. Learn architectural mistakes.
Understand the business model.
If the product makes money from transactions, uptime and performance matter differently than if it makes money from subscriptions.
Simplify aggressively.
Complexity compounds. Simplicity scales.
Communicate clearly.
The best decisions are useless if you cannot explain them.
Think long term.
Ask what this decision looks like at 10x growth.

The Future Engineer

The future engineer is not the person who knows the most frameworks.

It is the person who:

Knows when not to use one.
Understands impact beyond code.
Aligns technology with strategy.
Chooses clarity over cleverness.
Optimizes for outcomes, not ego.

Code is still important. But code is no longer the differentiator.

Judgment is.

And the engineers who master decision making will shape products, teams, and industries long after the syntax they once memorized becomes obsolete.

React Hooks Explained (Beginner-Friendly)

Sospeter Mong'are — Mon, 09 Feb 2026 05:08:00 +0000

First: What is a Hook?

A Hook is just a special function React gives you to “plug into” React features like:

State
Lifecycle
Context
Performance optimization

Hooks always:

Start with use
Are called inside components only
Follow predictable rules

The Core Hooks (You should learn these)

These are the hooks you’ll use in almost every React app.

1️⃣ `useState` — Store changing data

You already know this one 👍

const [count, setCount] = useState(0);

Use it for:

Form inputs
Toggles
Counters
Loading states

Mental model:

“Component-level variables that cause re-render when changed.”

2️⃣ `useEffect` — Run side effects

Also familiar now.

useEffect(() => {
  fetchData();
}, []);

Use it for:

API calls
Subscriptions
Timers
Logging

Mental model:

“Run this after rendering or when something changes.”

3️⃣ `useContext` — Read global data

Used with React Context.

const user = useContext(UserContext);

Use it for:

Logged-in user
Theme
Language

Mental model:

“Read shared data without passing props.”

Secondary Hooks (Learn after basics)

These make apps cleaner and faster.

4️⃣ `useRef` — Store values without re-rendering

const inputRef = useRef(null);

Use it for:

Accessing DOM elements
Storing values that shouldn’t trigger UI updates
Timers, counters, previous values

Example:

inputRef.current.focus();

Mental model:

“A box that holds data across renders without re-rendering.”

5️⃣ `useReducer` — Advanced state logic

Alternative to useState.

const [state, dispatch] = useReducer(reducer, initialState);

Use it when:

State logic is complex
Many related state updates exist

Backend analogy:

Reducer = controller logic

6️⃣ `useMemo` — Cache expensive calculations

const result = useMemo(() => heavyCalculation(data), [data]);

Use it to:

Prevent unnecessary recalculations
Improve performance

Mental model:

“Only recalculate if inputs change.”

7️⃣ `useCallback` — Cache functions

const handleClick = useCallback(() => {
  doSomething();
}, []);

Use it when:

Passing functions to child components
Preventing unnecessary re-renders

Mental model:

“Same function instance unless dependencies change.”

Advanced / Rare Hooks (Know they exist)

You don’t need these early on, but it’s good to know them.

8️⃣ `useLayoutEffect`

Like useEffect, but runs before browser paint.

Use only when:

You need to measure layout sizes
You see flickering UI issues

⚠️ Rarely needed.

9️⃣ `useImperativeHandle`

Controls what a parent can access from a child component.

Used with forwardRef.

Advanced use cases only.

10️⃣ `useId`

Generates unique IDs.

const id = useId();

Useful for:

Form inputs
Accessibility (labels)

Custom Hooks (VERY IMPORTANT)

You can create your own hooks.

function useGroups() {
  const [groups, setGroups] = useState([]);

  useEffect(() => {
    fetchGroups().then(setGroups);
  }, []);

  return groups;
}

Use them to:

Reuse logic
Keep components clean

Mental model:

“Extract reusable logic into a function.”

Beginner Learning Order (Recommended)

Here’s the safe learning path:

useState
useEffect
useContext
useRef
useReducer
useMemo & useCallback
Custom Hooks

What You Should NOT Do as a Beginner 🚫

Don’t memorize all hooks
Don’t use useMemo everywhere
Don’t optimize too early
Don’t jump to advanced hooks before basics

Quick Summary Table

Hook	Purpose	Learn When
useState	Local state	Day 1
useEffect	Side effects	Day 1
useContext	Global state	Early
useRef	DOM & mutable values	Early
useReducer	Complex logic	Intermediate
useMemo	Performance	Later
useCallback	Stable functions	Later

Final Takeaway

You don’t need all hooks to build real apps.
You need to understand a few deeply.

If you master:

useState
useEffect
useContext

You can build most production apps comfortably.

The First Big Mistake: Thinking Software Engineering Is Just Coding

Sospeter Mong'are — Wed, 04 Feb 2026 10:42:02 +0000

One of the biggest misconceptions shaping today’s AI panic is the belief that software engineering equals writing code. From that flawed assumption comes an even bigger conclusion: “If AI can write code, then AI will replace software engineers.”

This logic sounds convincing-until you understand what software engineering actually is.

Coding Is the Output, Not the Job

Writing code is only the visible output of software engineering, not the work itself.

Software engineering is about:

Understanding ambiguous problems
Translating human needs into technical systems
Designing architectures that scale
Making trade-offs between performance, cost, security, and time
Anticipating failure, misuse, and edge cases
Maintaining systems long after they are written

Code is simply the medium through which these decisions are expressed.

If you remove the thinking, the code becomes meaningless.

Software Engineering Is Decision-Making Under Constraints

Real-world systems don’t fail because someone didn’t know syntax.
They fail because:

Requirements were misunderstood
Assumptions were wrong
Systems didn’t scale as expected
Trade-offs weren’t thought through
Human behavior wasn’t considered

These are engineering problems, not typing problems.

AI can generate code, but it does not own responsibility. It doesn’t sit in meetings to clarify vague requirements. It doesn’t get paged at 2 a.m. when production is down. It doesn’t weigh business risk against technical purity.

Engineers do.

AI Is Powerful at Code - Weak at Context

AI excels at:

Pattern matching
Rewriting existing logic
Generating boilerplate
Speeding up repetitive tasks

But software lives in context:

Business goals change
Users behave unpredictably
Legal and compliance rules evolve
Systems interact with messy, legacy infrastructure

Context is not static. It’s political, social, economic, and human. That’s where engineering judgment lives-and where AI struggles the most.

The Real Role of a Software Engineer

A software engineer is closer to a systems thinker than a typist.

They:

Ask why before how
Challenge requirements that don’t make sense
Design for failure, not perfection
Communicate trade-offs to non-technical stakeholders
Take responsibility for outcomes, not just outputs

This is why senior engineers write less code than juniors-but create far more value.

What AI Actually Changes

AI doesn’t eliminate software engineers. It raises the bar.

Just like:

Compilers didn’t eliminate programmers
Frameworks didn’t eliminate engineers
Cloud computing didn’t eliminate infrastructure thinking

AI removes low-level friction and exposes who actually understands systems.

The future belongs to engineers who can:

Think clearly
Reason about systems
Make sound decisions
Use AI as a tool, not fear it as a replacement

Conclusion

The first mistake was reducing software engineering to coding.
The second mistake is assuming automation replaces thinking.

AI will write more code.
Humans will still decide what should exist, why it should exist, and whether it should exist at all.

That’s not going away anytime soon.

Passing Props in React (How Components Talk to Each Other)

Sospeter Mong'are — Wed, 04 Feb 2026 06:50:00 +0000

Why Passing Props Exists

In React:

Components are isolated
One component cannot access another’s data directly

So how do they communicate?

👉 Props

What Are Props?

Props are inputs to a component.

Think of them like:

Function parameters
API request data

Simple Example

function Greeting({ name }) {
  return <h1>Hello {name}</h1>;
}

function App() {
  return <Greeting name="John" />;
}

What’s Happening?

App sends data → name="John"
Greeting receives it → { name }
UI updates based on props

Backend analogy:

function greeting(name) {
  return `Hello ${name}`;
}

greeting("John");

Props Are Read-Only

❌ This is NOT allowed:

props.name = "Mike";

Props are:

Immutable
Owned by the parent

If data must change → it belongs in state, not props.

Common Beginner Mistake

Trying to store everything in one component.

Correct mindset:

Components should receive data, not own everything.

Key Takeaway

Props are how data flows downward in React.

No props → no real app.