So, Who The Hell Is David Oduse?

If you've landed on this blog for the first time, you might reasonably wonder who is behind all these random articles about software, security, infrastructure, products, and whatever else I happened to become interested in.

I'm David Oduse.

I'm a software engineer, product owner, techpreneur, and an endlessly curious person who has somehow made a habit of turning curiosity into software.

I build things. I break things. I fix things. I think things. And, when something teaches me something interesting, I write about it.

That's probably the simplest way to explain this website.

I Didn't Really Plan for It to Become This

My path into tech has been driven more by curiosity than by some perfectly structured career plan.

I've always enjoyed figuring things out. How does this system work? Why was it designed this way? What happens if something fails? Can this process be made simpler? What happens if someone tries to abuse it? Could I build one myself?

That last question has gotten me into quite a lot of trouble over the years.

I've built software products, backend systems, internal tools, experiments, security projects, and various things that existed primarily because I wanted to understand a problem properly. Some became real products. Some remained prototypes. Some were deployed and used for a while. Some were eventually discontinued. And some probably should have been discontinued much earlier.

I've learned something from all of them.

These Days, I Build Business Software

A large part of my recent work has been around Monesize, particularly Monesize Core.

Core is an enterprise finance and operations platform designed around the idea that business operations and financial records should be connected rather than maintained as disconnected pieces of information.

Building it has taken me far beyond simply writing APIs. I've had to think about accounting systems, operational workflows, organizational structures, permissions, compliance, government integrations, infrastructure, security, modular architecture, event-driven systems, and the realities of building software that businesses are expected to rely on every day.

And perhaps more importantly, building Monesize has changed the way I think about engineering. I've become increasingly convinced that good engineering decisions should start with business requirements, not technology preferences. The question isn't "what architecture would be fun to build?" It's "what does the business actually need, and what does that require the system to do?" The architecture comes after that.

That sounds obvious, but it's surprisingly easy to forget when you're a software engineer surrounded by interesting technologies. Sometimes the right engineering decision is an elegant distributed system. Sometimes it's a boring monolith. Sometimes it's building something from scratch. Sometimes it's integrating an existing service. And sometimes the correct answer is simply: don't build it.

I'm learning to appreciate that last one.

I've Built Things That Nobody Wanted

This is probably one of the more useful lessons I've learned from building products. Not everything you build will succeed.

I've built products that had users. I've built products that had almost no users. I've built products that looked promising until reality arrived. I've also shut products down when the evidence said they weren't worth continuing.

That experience taught me something that writing code alone never could: a technically good product can still be a bad business. You can build a beautiful system. You can design a clean architecture. You can write excellent code. And nobody may care.

That's not necessarily an engineering failure. Sometimes it's simply evidence that the problem, market, timing, distribution, or product wasn't right. Learning to distinguish those things has become an important part of how I approach product development. I don't want to build technology simply because I can. I want there to be a reason for it to exist.

Engineering Is More Than Code

I've become increasingly interested in what happens around the code. How does the system behave when something fails? How should data move between services? Where should a responsibility live? How do you prevent one organization from seeing another organization's data? How should permissions work? What happens when an external API goes down? How do you recover? How do you make a system understandable six months after the person who wrote a particular component has forgotten why they wrote it?

Those questions are often more interesting to me than the programming language being used. This is why my interests have expanded into enterprise architecture, distributed systems, infrastructure, accounting systems, security engineering, and operations. The code is only one part of the system.

Then There's Security

Alongside software engineering, I've developed a strong interest in cybersecurity and offensive security. I spend time studying penetration testing, vulnerability research, secure software design, infrastructure security, and how real systems can be attacked.

What I enjoy about security is the change in perspective. When you're building software, you think about how the system is supposed to work. When you're attacking it, you start asking: what if it doesn't? What if the user manipulates this? What if authentication is bypassed? What if this boundary doesn't actually hold? What if an assumption made by the developer isn't true?

That mindset has influenced how I build software. Security isn't something I want to bolt onto an application after everything else has been finished. Understanding how a system can fail or be abused is part of understanding how to design it properly in the first place.

I Like Going Down Rabbit Holes

This is probably responsible for a significant portion of what you'll find on this website. I can start by wondering how something works and, several hours later, find myself reading about a completely different field.

One day it's accounting architecture. Another day it's Linux internals. Then distributed systems. Then security. Then some obscure historical or philosophical question that has absolutely nothing to do with the software I was supposed to be working on.

I don't particularly want to get rid of that tendency. Curiosity has been one of the most useful things I've had as an engineer. It makes me ask questions. Questions lead to experiments. Experiments lead to projects. Projects lead to failures and discoveries. And occasionally, those discoveries become something useful.

Why I Write All This Down

Writing is how I think. I can understand something while I'm building it, but writing about it forces me to understand it differently.

Why did I choose this architecture? Why didn't I choose another? What problem was I actually solving? What assumptions did I make? Which ones turned out to be wrong? What happened when the system met reality?

Those questions are difficult to answer properly if you only remember the final implementation. That's why many of the technical articles here come from actual work. Some document things that worked. Some document things that didn't. Some explain architectural decisions. Some are security research. Some are lessons from products I've built. And some are simply me trying to make sense of an idea.

I don't want this blog to be a collection of tutorials written for the sake of having tutorials. I want it to be a record of how I think about technology and the things I build.

This Isn't Really Just a Software Blog

You'll find plenty of software talk here. Enterprise engineering. Backend architecture. Distributed systems. Cybersecurity. Infrastructure. DevOps. Linux. Product engineering. Software reliability. Business software. Engineering lessons from real projects.

But occasionally, I'll write about something completely unrelated. I've never been particularly good at keeping my curiosity inside neatly labelled boxes. Sometimes I want to write about technology and society. Sometimes business. Sometimes history. Sometimes philosophy. Sometimes an idea that doesn't have an obvious category at all.

That's okay. The blog is called a blog, not a peer-reviewed journal.

What's Next?

I have no idea. And I think that's a good thing.

Right now, I'm deeply interested in enterprise software, financial systems, backend architecture, distributed systems, cybersecurity, infrastructure, and product engineering. Tomorrow I might become obsessed with operating systems. Or compilers. Or distributed databases. Or some completely ridiculous project that has no business being built.

Whatever it is, I'll probably try to build something around it. And if I learn something interesting, I'll probably write about it.

That's what I want this website to remain: a record of the things I'm building, the things I'm learning, the mistakes I'm making, and the ideas I'm trying to understand. Not a perfectly polished account of a career. Not a claim that I have everything figured out. Just the trail.

Anyways, Hello.

I'm David. I build software and products. I care about engineering, but I'm equally interested in the business problems that engineering is supposed to solve. I like understanding systems. I like building things. I like figuring out why things break. I like security. I like asking inconvenient questions. And apparently, I like writing very long posts about myself.

If you've made it this far, thanks for stopping by. Have a look around. There are probably a few things here worth reading.

And if you find something interesting, that's exactly why I keep writing.