David Oduse

Kongres started with a relatively simple observation: organizations that run recurring events often collect attendance data, but that data does not necessarily become useful information about the people attending them. An attendance list can tell an organization how many people showed up. It does not necessarily tell them who came for the first time, who keeps returning, how participation changes over time, or how individual attendance contributes to a broader understanding of the organization's community. Kongres was an attempt to solve that problem. The idea was to build an attendance system that treated every attendance record as part of a larger member and engagement dataset rather than as an isolated event record. I eventually launched Kongres as a live product, made it available to organizations for free, and learned as much from what happened after launch as I did from building the software itself. Starting With Attendance The initial problem was straightforward: org...

A practical walkthrough of architecting, structuring, and implementing a URL shortener backend that handles authentication, authorization, pagination, and clean separation of concerns. Why GraphQL GraphQL gives clients exactly what they ask for and nothing more. For a URL shortener, this means a frontend can fetch only the fields it needs, whether it is a dashboard with all URL metadata or a simple list with just short codes and click counts. No overfetching, no underfetching, no versioning headaches. Architecture Overview The project follows a clean architecture pattern with four layers: Client -> GraphQL Resolver -> Service -> Repository -> Database Each layer has a single responsibility. Resolvers handle input validation and delegate to services. Services contain all business logic. Repositories own the database queries. This separation makes the code testable, maintainable, and easy to reason about. Folder Structure src/ config/ Environment configuration cont...

Sometimes the best software projects aren't born out of ambitious ideas. They're born out of practical business problems. A client recently reached out after running into limitations with Mailchimp. Their outreach campaigns were being affected by daily sending restrictions, forcing them to spread email campaigns across multiple days. For a business that relied on timely outbound communication, that wasn't sustainable. Instead of working around those limitations or paying for another platform, they decided to build a tool tailored to their workflow. The goal wasn't to compete with Mailchimp or recreate years of product development. It was to build a focused internal application that solved one problem well: sending large email campaigns without unnecessary complexity. Over the course of a weekend, I designed, built, and deployed a custom email outreach platform from scratch. Understanding the Requirements Before writing any code, I wanted to understand exactl...

I used to make this mistake myself, so I don't say any of this from a distance. The reasoning always sounds airtight when you're the one making it. There are five million businesses in the country. Our product solves a problem every one of them has. So our market is five million businesses. It feels like arithmetic. It is actually a story we tell ourselves because it's more exciting than the alternative. The truth I've come around to, slowly and a little reluctantly, is that having a problem does not make someone a customer. Customers live inside a much smaller space than the market does, and confusing the two is one of the more expensive habits a founder can develop. The Problem Is Only the Beginning Say you build something that helps businesses run more efficiently. You can stand up in front of investors and say, correctly, that almost every business struggles with operational inefficiency at some point. That sentence is true and it tells you almost nothing us...

One of the biggest misconceptions in enterprise software is the idea that every business should eventually move away from spreadsheets. I don't believe that's true. For many small businesses, Excel is exactly the right tool. If you're a one person operation making all the decisions yourself, spreadsheets are often faster, simpler, and cheaper than a full business platform. The goal should not be to replace Excel. The goal should be to solve problems that Excel no longer solves well. When Excel Stops Being Enough The challenge usually isn't transaction volume. It's organizational complexity. As businesses grow, work becomes distributed. Multiple people create purchases. Managers approve expenses. Inventory exists in different locations. Finance needs accurate books. Payroll becomes more complicated. Departments begin depending on each other. Eventually, spreadsheets stop being a shared operational system and become isolated files that everyone is trying t...

Monesize Core did not begin as an attempt to build a large enterprise platform. It evolved. The product started from a much smaller problem space. As the system grew, the limitations of the original approach became increasingly obvious. Business operations were becoming more complex, financial records were becoming more important, and the relationship between the two could no longer be treated as an afterthought. That eventually led to a different architectural question: what if the operational system and the financial system were designed as parts of the same system from the beginning? That question became the foundation for Monesize Core. Today, Core is a modular finance and operations platform built around a central accounting engine, operational domains, event-driven coordination, tenant isolation, compliance infrastructure, and a growing identity layer that allows independently deployed products to participate in the wider Monesize ecosystem. This article documents how tha...