David Oduse

Meetvo started with a simple question: could professional networking for technology talent be more useful if it focused on the things that actually matter to a person's career? Most social platforms are designed around consuming content. Professional networks are not necessarily much different. Profiles exist, but the experience often becomes dominated by feeds, media, engagement metrics, and general social activity. I wanted to explore a different model. Meetvo was designed as a text-first professional network specifically for technology professionals and recruiters. The focus was professional identity, technical knowledge, conversation, and opportunities. I eventually deployed the project as a live product at meetvo.me. I later stopped developing it and chose not to renew the domain, but the application remains available through its Vercel deployment. The Product Idea The central idea behind Meetvo was that a technology professional should be able to represent their caree...

Openfy started from an idea I had while thinking about how much infrastructure a new fintech product has to build before it can even begin solving its actual customer problem. Authentication, accounts, transactions, payment flows, analytics, savings products, and credit logic are not necessarily the differentiating part of a fintech product, but they still require substantial backend work. I wanted to explore what a reusable backend for those common capabilities could look like. That became Openfy. It was an open-source project rather than a commercial product. The goal was not to build a complete financial institution in a repository. It was to explore the backend architecture and implementation patterns that could provide a starting point for developers and fintech teams building financial applications. The Idea A lot of fintech products eventually need similar foundations. A user needs an account. The application needs authentication. Transactions need to be recorded. Users ...

Building a chat application sounds deceptively simple until you look beyond the happy path. Messages need to arrive almost instantly, remain available when users go offline, stay in order, and scale to millions of concurrent connections. This article builds a modern chat system from first principles, introducing one architectural component at a time as each new problem emerges.  The Problem Picture a messaging app. Two people, or a group, exchange messages that need to show up within milliseconds, in the right order, and exactly once as far as anyone can tell. On top of that, if someone's phone is off for a week, every message sent to them in that time still has to be there when they turn it back on. The scope here covers sending and receiving one-on-one and group messages, delivering messages that arrived while someone was offline, keeping messages in order within a conversation, showing sent, delivered, and read receipts, and tracking who's currently online or when they w...

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? ...