DEV Community: Favor Charles Owuor

Why you should Deploy early and often

Favor Charles Owuor — Fri, 29 May 2026 14:15:19 +0000

Create a project and ensure it has all the features first then and only then can I deploy it. That's something most of us have done, right? Though you may have not thought or said the same thing word for word, but it's something that just happens sub-consciencely. Basically like habit and it does not seem to have any issues. So why would you change your current normal balance to now start deploying work that's incomplete? Let's explore this question together.

Deploy early and often

This is a software development philosophy that prioritizes frequent, smaller releases over long, feature-heavy development cycles. This approach creates a rapid, tight feedback loop with users while eliminating the risk of building software no one actually wants. It's also known as RERO: Release Early, Release Often

The thing is, your project might work fast and efficiently in your local host environment. Where there is one user, the hardware would be dedicated to that task alone at the time of testing, and no major issues. But when you deploy there's differences in latency, infrastructure and the users.

I heard from another developer that he once deployed a website and minutes later the site crashed. Reason being, one of the users had sent many requests in a short period of time. Another one's account creation failed because they added an emoji to their user name.

These are all variables that would not be considered in a local environment. Putting your work out there as you develop it allows you to identify weak points and problems you normally wouldn't experience alone.

Why Deploy Early and Often?

Faster Feedback Loops: Getting a Minimum Viable Product (MVP) to users early ensures customer preferences guide the product, saving hundreds of hours of guesswork. They can also show errors and issues that the product may have that you may not have seen in the planning or creation process
Easier Debugging: Deploying smaller batches of code makes tracking down and fixing bugs easier, as there are fewer variables and lines of code changed at any given time.
Reduced Release Stress: Long periods between releases generate pressure, making deployments risky and complicated. Making deployments a normal, frequent occurrence turns them into a routine, and low risk. When you have many features at hand and want to release them all at once the likely hood of one of them failing silently is high. I once deployed a project and there were many silent errors in different parts, but when looking at the code, there were no error indicators anywhere.
Higher Quality: It shifts the mindset from chasing "full-featured perfection" to continuous improvement and user-defined validation. It's better to work step by step and "perfect" features as you go. Since you will be sure of the working features, your attitude towards the project rises as stress reduces since you have the time and effort dedicated to making the next thing.

How to Implement It Effectively

Deploying isn't just one and done. You need to implement and use the proper tools and practices to ensure a smooth development journey. If done right It will allow you to focus on creation and innovation.

Automation:
Use a CI/CD (Continuous Integration/Continuous Deployment) pipeline that automatically builds, tests, and deploys code changes. This makes it so that you always deploy projects that are stable and work according to spec
Feature Flags:
Utilize feature flags (toggles) to merge features into the main branch but hide them from users until they are officially ready. This allows continuous deployment without exposing incomplete features. You may have select users as testers. They will ascertain if the features that you have pushed work as intended.
Solid Rollback Plans:
When automating deployments, ensure your infrastructure allows you to quickly roll back to the previous stable version if something breaks. This is more frequent than one might realize. You might push a feature to production, then it breaks everything. It's important to note that having versions that are close in terms of times they were developed makes it easier to restore. That's why having updates that are few and far between can really hurt when the rollback happens.

Conclusion

A product that “works but", fails at the critical moment is of eploy early and often help you frustrating, and most developers have experienced it. That’s why the ideaa bitter experience I'm sure most of us have experienced. But having the concept of "Deploy early and often” matters. It" though long can helps you catch issues sooner, improve reliability, and keep your system ready for real use at any timebuild better and working systems always ready for action. If you haven’t started doing this yet, now is a good time as any. It'll save you a lot of stress and worries in the long run.

Beginner steps into CI/CD

Favor Charles Owuor — Tue, 26 May 2026 09:28:22 +0000

Image by freepik

Most people me included, just use Github as kind of like an online store for code. But this application has more to it than meets the eye.

What is CI/CD

Continuous Integration (CI): Is the of automation of the process of merging code changes. It's typically trigged on every push or pull request, running automated tests and builds to detect bugs early.
Continuous Deployment/Delivery (CD): Automatically prepares or pushes tested code to a production environment once the CI checks pass

These series of events can help cut down on the time and effort spent on the manual tasks. They can be summarized in the image below.

How you can do it

Step 1: Create your workflows

In CI, there's four key concepts one should know i.e. trigger, workflow, job and step.

A trigger is what will cause the CI process to start
Workflow is the automation file(.yml)
Job is a group of steps on one machine
Step is a single command or action

To begin we first create a .github directory. Inside we create a workflows folder. Inside we create out ci.yml file. The structure should look like this:

Step 2: Define triggers

For this instance we want the process to start when someone performs a pr but you can set it to push as well

name: CI Pipeline

# TRIGGERS
on:
    push:
        branches: [main]
    pull_request:
        branches: [main]

Step 3: Define Jobs

Jobs work in Isolated Environments. Every job runs inside its own fresh virtual machine (called a runner), such as Ubuntu, Windows, or macOS.
If your workflow has multiple jobs, GitHub runs them at the same time to save time.
A job groups together a series of sequential tasks (steps) that handle the actual work.

# JOBS
jobs:
    test:
        runs-on: ubuntu-latest # The machine to use

        steps:
            ...

Step 4: Define Steps

Steps are the individual, sequential tasks that execute inside a single job. They run one after another, in the exact order they are listed in the YAML file.
All steps in a single job run on the same virtual machine instance. If Step 1 creates a file or installs a package, Step 2 can use it.
In case any step fails (returns an error code), the job stops immediately, and the remaining steps are skipped.

steps:
      # Step 1: Get the code
      - name: Checkout Github code
        uses: actions/checkout@v4

      # Step 2: Set up Node.js
      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
        ...

That there was a simple CI pipeline now of to the CD.

Step 5: Deployment cycle

Similar to the CI structure, the CD is also made in the same structure but the steps differ.
They go from tests, if they pass then to the build. Upon successful build the project is then staged and finally pushed to production.

name: Deploy

on:
  push:
    branches: [main]

# Prevent multiple deployments at once
concurrency:
  group: deployment
  cancel-in-progress: false

jobs:
  # First: Run tests
  test:
    name: Run Tests
    ...

  # Second: Build the project
  build:
    name: Build
    runs-on: ubuntu-latest
    needs: test
    steps:
      ...

  # Third: Deploy to staging
  deploy-staging:
    name: Deploy to Staging
    runs-on: ubuntu-latest
    needs: build
    environment: staging        # Requires environment approval (optional)

    steps:
      ...

  # Fourth: Deploy to production (manual approval)
  deploy-production:
    name: Deploy to Production
    runs-on: ubuntu-latest
    needs: deploy-staging
    environment: production     # Can require manual approval in GitHub settings

    steps:
      ...

But this is just an example, to better understand see the video here or see this github repo. It will provide a wider view and context

Why do this

Short answer: Speed. Organizations that have mastered the CI/CD, build and deploy products faster than others. Since products are always being rated and feedback being provided. Developers commit smaller changes more often, hence keeping up with customer demands.
With ongoing feedback, developers are constantly making small changes.
Automated continuous testing ensures that the codebases remain stable and ready for deployment at all times. Since the manual tasks are taken care of with this automation, developers can focus on creation, innovation, and other important tasks

Conclusion

I'm also still learning about this concept and implementing it into my own workflow. It's a core skill that I believe every developer should enforce in their workflows especially junior developers. It's a major time saver and also ensures you always have working code ready for production.

Logs in code

Favor Charles Owuor — Mon, 25 May 2026 11:44:00 +0000

Image from thumbs.dreamstime.com

When writing code, many developers especially junior level, don't understand the importance of having logs in their code. I was also a victim of this. This article will delve a bit into the importance of logs in your development cycle and how you can implement them.

The Importance

So recently I've been developing a personal finance tool. When trying to do add a transaction performed it brings errors but they don't state where the issue is.

This is what is be displayed on the website:

It shows there's an issue in the way the time is being parsed. The bigger issue is that the error message is being displayed to the user which is a mistake on my part. Still, this would be better shown in the logs. As for the logs, this is what is displayed:

The image just shows that there was a bad request and nothing else, no context. So I didn't even know where to begin with in terms of fixing my code.

Back to the matter at hand, the importance of adding logs to your code. So what exactly is logging?

Logging can be defined as writing text describing what’s been happening in your program to a file or other storage system. Logging is essential for debugging and troubleshooting. When there's a bug, you need to find out which specific part of the program is broken, because it’s often not the part that’s visibly acting weird. This is often the first step in addressing a new bug after reproducing it, or even part of figuring out how to reproduce it.

In fact, logs can be helpful at every stage of the debugging process. You have to confirm your assumptions on what parts are known to work. After all, the whole program is supposed to work, and often times, the thing that’s broken is something that you would’ve assumed definitely worked.

How to implement it

So I got to work and added a few lines of code to see the actual reason why the transactions were not being created.:

The code initially just returned the err, but the slog.Error code allows for a more detailed error to be shown in the logs. Like so:

The line in red is:

{
"time":"2026-05-25T10:47:02.872094934Z",
"level":"ERROR",
"msg":"CreateTransactions failed",
"user_id":"a7e2fa58-712c-4fed-9783-35272ea7e2a1",
"account_id":"1ad6e60e-b104-4dc4-91d7-b22de26ee972",
"amount":2300,
"type":"expense",
"error":"Type can only be income or exepense"
}

As you can see in the logs, the error is more detailed and I can see that the error is a typo in my own code base, since it is an error 500(internal). So Upon closer inspection of my code I realized, that I wrote something entirely different.

Instead of expense I wrote:

That's an error on my part(coding while tired). but I wouldn't have known to go back to my code and check, if I didn't have that error message.

So for you the reader you:

1. Choose a Standard Library or Framework

Avoid using print() for permanent logging, as it lacks control over levels and destinations. Use established tools for your language:

Python: The built-in logging module.
Java: Log4j2 or Logback via SLF4J.
Node.js: Winston or Bunyan.
Go: Log
Rust: The log crate facade

2. Define Severity Levels

Categorizing messages will allow you to filter logs in different environments (e.g., show only errors in production but everything in development).

DEBUG: Detailed information for diagnosing problems during development.
INFO: Confirmation that things are working as expected (e.g., service started).
WARNING: Indication that something unexpected happened, but the software is still working.
ERROR: Serious problems where a specific function failed to execute.
CRITICAL: Fatal errors indicating the program itself may be unable to continue.

3. Configure Loggers, Handlers, and Formatters

A strong setup has three main components:

Loggers: The entry point where your code sends messages (e.g., logger.info("Starting process")).
Handlers (Appenders): Determine where the logs go—such as the console, a local file, or a remote server.
Formatters: Define the layout of the log message. A standard format includes: [Timestamp] [Level] [Source/Module] [Message].

4. Best Practices for Better Logs

Structured Logging: Use JSON or key-value pairs instead of plain text to make logs easily searchable by machines.
Include Context: Log useful identifiers like user_id or transaction_id, but never log sensitive data like passwords or credit card numbers.
Log Exceptions: In try-except blocks, use logger.exception() to automatically capture the full stack trace.
Use UTC Timestamps: Standardizing on UTC avoids confusion when working across different time zones.
Centralize Configuration: Configure logging once at the project's entry point (e.g., your main.py or App.java) rather than in every individual file.

Conclusion

Working with logs has saved me a lot of time in debugging and looking for errors where none can be seen. In development its easier to spot issues but in production it can be a nightmare. I encourage every developer especially the beginners to start using logs as early as your current project. It'll save you a lot of time and make your development journey a little bit easier.

Understanding Back-End Project Structures in Go: A Guide to Separate Concerns

Favor Charles Owuor — Wed, 11 Mar 2026 10:11:18 +0000

Code on laptop with hands typing in the dark Free Photo

When I first started writing Go to make a back-end API, I did what most people do — threw everything into one file. The handler, the business logic, the database calls, all of it crammed together. It worked, until it didn't. The moment I tried to refactor or write tests, three things broke. Sound familiar?

The fix isn't complicated, but it does require a bit of upfront thinking about how you organize your code. In this article I'll walk through a project structure that I learned recently. Companies like Uber and Netflix use similar patterns to manage large systems. It allows for scaling while remaining resilient to failures.

Why Bother Separating Concerns?

Most developers have all written messy code at some point. But once things are separated, the breathing room allows for testing, changes and reuse.

The idea behind separation of concerns is simple: each part of your code should have one job and one job only. When your handler is doing database queries and business logic, changes and tests can get tedious

The Four Layers

For this project we use four layers:

Model — the data structure
Repository — database access
Service — business logic
Handler — HTTP request handling

The payoff is that the same core logic runs with different routers (standard net/http, Gin, or Chi) and different databases (SQLite or MongoDB) without touching the middle layers at all.

1. Model

This is just the shape of your data. No HTTP, no database — just a structure, or skeleton.

type Todo struct {
    ID        string
    Title     string
    Completed bool
    CreatedAt time.Time
}

Everything else in the app revolves around this.

2. Repository

The repository is the only layer that talks to the database. Everything above it just calls repository methods.

You define an interface first:

type TodoRepository interface {
    Create(todo Todo) error
    GetByID(id string) (Todo, error)
    GetAll() ([]Todo, error)
    Update(todo Todo) error
    Delete(id string) error
}

Then you implement it for each database. Want to switch from SQLite to MongoDB? Write a new implementation, swap it in — nothing else changes.

3. Service

This is where your actual business logic lives. The service interact with whatever database being used, and it has nothing to do with HTTP. It just takes inputs, does something meaningful with them, and returns a result.

type TodoService struct {
    Repo TodoRepository
}

func (s *TodoService) Create(title string) (Todo, error) {
    todo := Todo{
        ID:        uuid.New().String(),
        Title:     title,
        Completed: false,
        CreatedAt: time.Now(),
    }
    err := s.Repo.Create(todo)
    return todo, err
}

Notice it only knows about the repository interface. That's the point.

4. Handler

Handlers sit at the edge of the application and deal with HTTP. They decode requests, call the service, and write responses.

func (h *TodoHandler) Create(w http.ResponseWriter, r *http.Request) {
    var req struct {
        Title string `json:"title"`
    }

    json.NewDecoder(r.Body).Decode(&req)

    todo, err := h.Service.Create(req.Title)
    if err != nil {
        http.Error(w, err.Error(), 500)
        return
    }

    json.NewEncoder(w).Encode(todo)
}

Because handlers only talk to the service (not the database), you can write different handlers for different routers — standard net/http, Gin, Chi — and they all call the exact same service methods underneath.

How It All Fits Together

Here's the flow when a request comes in:

HTTP Request → Handler → Service → Repository → Database

And back:

Database → Repository → Service → Handler → HTTP Response

Each layer only knows about the one directly below it. The handler doesn't know about the database. The service doesn't know about HTTP. The repository doesn't know about business logic. No bleed-through.

In practice, wiring it all together in main.go looks like this:

repo    := repository.NewSQLiteRepo(db)
service := service.NewTodoService(repo)
handler := handler.NewStdHandler(service)
router  := router.NewStdRouter(handler)

Want MongoDB instead? Change one line:

repo := repository.NewMongoRepo(collection)

Want Gin instead of net/http? Change one line:

handler := handler.NewGinHandler(service)
router  := router.NewGinRouter(handler)

The service layer doesn't move. The repository interface doesn't move. Only the edges change.

This is the resulting file structure:

├── cmd
│   └── main.go
├── internal
│   └── handlers
│   └── models
│   └── repository
│   └── services

Wrapping Up

This structure might feel like extra work upfront compared to dumping everything in one file and it is. This is true only for small projects. But the moment you need to write a test, switch a database, or hand the project to someone else, you'll be glad you did it.

I built the full working example of this with a Todo List API — complete with SQLite and MongoDB repositories, and handlers for net/http, Gin, and Chi. Take a look if you want to see all the pieces in place.

Start with this structure even on small projects. It's a habit that pays off fast.

A Compiled Review

Favor Charles Owuor — Tue, 17 Feb 2026 20:50:03 +0000

As a new developer using Go, I often wondered how different other compiled languages really are. I was advised to learn Go first because of its simplicity and speed. But what about the others? What are they and what can they offer.

There are many compiled languages, both popular and obscure. In this article, we focus on just four: C, C++, Rust, and Go. Let’s examine what each brings to the table.

Origins and Boom Years

C appeared in 1972, created by Dennis Ritchie at Bell Labs. It was developed to overcome limitations in B and BCPL and to build the Unix operating system. C provided low level memory access while maintaining structured programming concepts, which made it ideal for operating systems and critical performance software.

C++ was introduced in 1985 by Bjarne Stroustrup. It expanded C with object oriented programming features. The language gained strong popularity in the late 1990s and early 2000s during the rise of large scale software systems and game development.

Go was released by Google in 2009. It was influenced by C but designed to reduce complexity. It gained traction in the mid 2010s alongside cloud computing and microservices architecture due to its fast compilation and built in concurrency support.

Rust reached its stable release in 2015 from Mozilla, created by Graydon Hoare. It grew rapidly in the 2020s because of its strict memory safety model and strong performance guarantees. Many companies adopted it to reduce bugs related to memory errors.

Why Choose One and Leave the Other

As software systems became more complex, languages evolved to solve new problems. C provides control and performance. C++ adds abstraction to manage larger systems. Rust enforces memory safety, and Go simplifies concurrency and improves developer productivity.

Each language solves a different problem. C and C++ offer flexibility but require careful management. Rust prevents many classes of bugs at compile time. Go focuses on clarity and fast builds, making it practical for distributed systems and cloud services.

There is no one language that is better. There are trade offs. The best choice depends on what you as the developer want and/or need from whatever language you choose.

Concurrency Benchmark Across Languages

This test computes the sum of squares of the first 100,000,000 numbers split across 4 threads or goroutines. Execution time is measured in milliseconds.

Language	Sum	Time (ms)
C	672,921,401,752,298,880	113.4060
C++	672,921,401,752,298,880	80.5660
Rust	333,333,338,333,333,350,000	1171.7290
Go	672,921,401,752,298,880	48.8229

View Code

Why This Test Matters

These benchmarks show more than execution speed. They reveal how each language approaches concurrency and numerical safety under the same workload. While C, C++, and Go completed the computation without warnings. You see the computed numbers were too big for int64 so Rust refused silent overflow and required a larger integer type i.e. int128 while the other languages used the values as is.

Conclusion

Compiled languages are not interchangeable tools. Each reflects different priorities in software engineering. C and C++ reward experience and precision. Rust enforces correctness and offers strong safety guarantees. Go values simplicity and productivity.

Understanding these differences allows developers to choose intentionally instead of following trends. The right language is not about which is fastest. It is about which aligns best with the problem you are solving.

Building an AI Agent for Business Viability In a 24 Hour Hackathon

Favor Charles Owuor — Thu, 05 Feb 2026 11:16:59 +0000

I recently participated in a hackathon focused on building AI agents. The main rule was clear. AI could not be the product by itself. It had to support a real system.

Our team had five members. We worked for just over 24 hours. The pressure was real. So was the ambition.

The Problem We Chose

Many people have business ideas. Very few know if those ideas make financial sense before investing money.

We saw a gap. People needed a way to test ideas early, using numbers and logic, not hope and vibes.

Our goal was to build a tool that helps someone answer a simple question. Is this business idea viable or not?

The Core Idea

We built a business viability checker called Microbiz.

The user enters structured inputs. These include starting capital, pricing, expected monthly sales, operating costs, and time horizon.

At the core of the system is a calculation engine. It computes revenue, total costs, profit margins, and sustainability indicators over time.

This part was fully deterministic. Just math and logic to get consistent results every time.

We wanted users to trust the numbers first.

System Design and Team Roles

We used Django for the back-end. I worked mainly on this part.

My role involved handling inputs, validating data, running financial calculations, and structuring outputs. I also prepared the data so it could be consumed cleanly by the AI component.

Two teammates worked on the front-end. Their focus was speed and clarity. They designed an interface that made complex inputs easier to manage under time pressure.

Another teammate focused on prompt engineering. Their job was to control how the AI reasoned, what context it received, and how it communicated results.

Where the AI Fit In

We integrated Groq AI using an API key.

The AI did not redo the calculations. It received the raw user inputs plus all internal computed values.

From there, it performed higher level reasoning. It considered market conditions, pricing realism, demand signals, and feasibility based on what is currently visible online.

The AI produced one output; it gave a recommendation on whether the business idea was likely viable or risky under the given assumptions. It stated reasons based on the input given

The AI was meant to support decisions, not motivate or sell dreams.

The Reality Check

We underestimated the workload.

Writing formulas was not the hardest part. Defining realistic assumptions was.

We had to research small business behavior, cost structures, margins, and failure points. That research slowed development since none of us have any financial or business backgrounds, but skipping it would have made the system useless.

Time worked against us. Features piled up faster than we could finish them. We created and broke code again and again until we got to a middle ground that wasn't perfect but works well enough.

Despite working through the night, we did not complete everything we planned.

Pitch Day

Before demos, all teams were called to a common area and given three minutes for an elevator pitch with slides and demos. When our turn came, we presented with nothing but words.
It still worked in our favor since we understood the product deeply. We explained the problem clearly and answered the judges' questions without much thinking. We explained why pure AI was not enough and how logic and AI reasoning worked together.

We did not make the podium. However, the judges told us the product was useful and encouraged us to keep building it. That feedback mattered more than placement.

Lessons Learned

First, scope matters. AI agents amplify systems. They do not replace solid foundations.

If your assumptions are wrong, AI makes the output confidently wrong. It's just how systems work; GIGO (Garbage In Garbage Out)

Second, research is not optional. Especially when dealing with money and real people.

Third, clear ownership helps under pressure. Back-end, front-end, and AI roles stayed mostly separate. That prevented chaos.

What Comes Next

This project is not finished and it most definitely won't be shelved.

Our next step is reducing the amount of input required. The system should do more inference with less user effort so that even those who are green in business but would still like to start one can do it but with more knowledge.

Long term, the goal is idea discovery. The system should recommend business ideas directly, starting with specific regions in Kenya. And as the scope expands maybe even worldwide. Maybe one day you may even interact with it.

The hackathon may have ended, but the product will live on.