Kongres: Building an Attendance and Engagement Platform

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: organizations needed a better way to record attendance at events. For many organizations, particularly churches and ministries, attendance is still heavily dependent on manual processes. People may sign attendance sheets, administrators may manually enter records, or attendance may simply be counted without retaining much useful information about the individuals who attended.

Kongres approached the problem from a different direction. An event would have its own attendance mechanism, and each attendance record could contribute to a persistent member database. That meant an attendance event could become more than a number. It could tell the organization who attended, whether someone was attending for the first time, how often a member participated, how attendance changed over time, which events attracted particular groups, and how participation differed across an organization's activities. The goal was to make attendance the starting point for engagement rather than the end of the process.

Designing the Core Workflow

The basic workflow was built around events. An organization could create an event, generate a unique link for that event, and provide attendees with a way to record their attendance.

QR codes made this particularly useful for physical events. Instead of requiring attendees to find a particular page manually, an organization could provide a QR code associated with the event. Scanning it would take the attendee directly into the attendance flow. The backend then handled the event and attendance records through a structured API, which kept the frontend experience relatively simple while allowing the backend to become the source of truth for the organization's attendance data.

Attendance Was Only the Beginning

One of the more important decisions in Kongres was not to treat attendance records as disposable event data. An attendee could become part of the organization's member database, which meant the system could build an increasingly useful picture of participation over time.

A first-time attendee, for example, could be identified as such, and subsequent attendance could then be associated with that person's existing record rather than creating an entirely new identity every time. That allowed Kongres to move from "how many people attended this event" toward "what does attendance tell us about the people participating in this organization." That distinction shaped several parts of the data model.

First-Timers and Segmentation

Attendance also created an opportunity to capture additional information. Kongres supported first-timer tracking and demographic segmentation, including gender. These weren't intended to turn the platform into a generic analytics product. They were there because organizations often need to understand who is participating, not simply how many people are present.

The resulting data could then feed attendance analytics and help administrators understand participation patterns. The backend therefore had to support more than simple event registration. It needed to maintain relationships between organizations, events, members, and attendance records.

Building the Backend

The backend was built with Node.js and Express.js, with PostgreSQL used as the primary database and Prisma ORM providing the database access layer. JWT authentication handled organization and administrator authentication. The application was structured around controllers, services, routes, middleware, and utility layers rather than putting all business logic directly inside route handlers. That separation was useful as the number of features increased.

The system eventually included APIs for organization registration and authentication, event creation, attendance, members, analytics, first-timer tracking, and organizational data. I designed the database structure with future extensions in mind, without forcing those features into the initial product.

QR Codes and Multiple Attendance Channels

The web attendance flow was only one possible way of collecting attendance. I also designed the product with USSD integration in mind, which was particularly relevant because attendance should not depend entirely on smartphone access or a particular web experience.

The idea was to make the backend capable of receiving attendance through different channels while keeping the underlying attendance model consistent. Whether the record originated from a web form, a QR code, or USSD, the system could ultimately treat it as an attendance event associated with an organization and an individual. This was an early example of separating the input channel from the underlying business operation.

Analytics

Once attendance records were being stored consistently, analytics became possible. The backend exposed analytics-oriented APIs that could support an administrative dashboard. Instead of requiring an administrator to manually count attendance records, the system could aggregate the data and expose useful metrics.

The purpose was not to create an enormous analytics platform. It was to make the data that organizations were already collecting more useful. Attendance history could become a way to understand participation rather than simply something stored for record keeping.

Designing for Future Integrations

I also designed Kongres with the expectation that attendance would eventually connect to other communication and engagement channels. The backend architecture left room for integrations such as SMS, email, USSD, additional engagement workflows, and AI-assisted insights. Not all of these became implemented product features.

The important architectural consideration was that the core attendance and member data should not become tightly coupled to any single communication provider. That would make it possible to introduce additional channels later without rebuilding the core application around them.

What Building Kongres Taught Me

Kongres was a useful project because it forced me to think about the difference between recording an event and building a system around the data produced by that event. The attendance itself was not particularly complicated. The interesting engineering problem was everything around it.

How should an organization be represented? How should members relate to attendance? When does an attendee become a member? How should first-timers be identified? How should historical attendance be queried? How should analytics be generated? How can different attendance channels feed the same backend? These questions pushed the project well beyond a simple attendance form.

Launching the Product

Eventually, Kongres moved beyond development and became a real product. I launched it publicly at kongres.app and made it available to organizations for free. Organizations used the system, which gave me an opportunity to observe what happened when software moved from development into actual use.

That distinction matters. A product can appear useful while it is being designed. Actual usage is a much better test. People have to choose to use it. Organizations have to incorporate it into their workflows. Administrators have to return to it. Attendance has to actually be recorded. The product has to become useful enough to justify the effort required to use it. Kongres gave me an opportunity to learn that lesson firsthand.

The Usage Reality

By June 2026, I reviewed the actual usage of Kongres. The result was straightforward: there had been no recorded activity during the year. That was a much more useful signal than any assumption I could make about the product's potential.

The software worked. The backend was functional. The product had been used by organizations. But the usage data showed that there was no meaningful ongoing activity. At that point, continuing to pay for the kongres.app domain simply because the product existed did not make much sense. So I decided not to renew the domain and discontinued the public service in July 2026. The application itself remains functional on its Vercel deployment.

Deciding to Shut It Down

There is a particular lesson in shutting down software that you built yourself. It is easy to become attached to the work. You spend time designing the architecture, you write the backend, you build the database, you create the product, you deploy it. Then it becomes tempting to keep maintaining it because you've already invested so much into it.

But the investment has already happened. The question after launch is different: is the product still providing enough value to justify continuing it? For Kongres, the usage data gave me a clear answer. The product did not have enough activity to justify continuing to operate the public domain. That made discontinuing the domain a more rational decision than continuing to maintain an externally available service that nobody was using.

What I Would Do Differently

Kongres also taught me something about product development that is difficult to learn from purely technical projects. Building more software does not necessarily make a product more valuable.

The backend can be well structured. The database can be carefully designed. The APIs can work correctly. The product can have room for future integrations. None of that guarantees adoption. In retrospect, I would place more emphasis on validating sustained usage earlier. The question wouldn't only be can I build this. It would also be: are organizations repeatedly using this enough for it to become part of their workflow? That is a much harder question. It is also the more important one.

The Technical Lessons

From an engineering perspective, Kongres gave me experience with several patterns that have continued to influence how I build software. The project reinforced the importance of keeping business logic separated from transport concerns. It gave me practical experience designing relational models around organizations, members, events, and attendance. It demonstrated the usefulness of Prisma for maintaining a structured database layer in a Node.js application. It also reinforced the value of designing APIs around the underlying business operations rather than around the screens that happen to consume them. The attendance system could therefore support different clients and input mechanisms without changing the fundamental data model.

What Kongres Became

Kongres ultimately became something slightly different from what I initially imagined. It was a real product. It had real organizations using it. It was deployed publicly. It had a working backend, database architecture, authentication, attendance workflows, QR-code generation, and analytics capabilities.

But it also became an experiment in something more important: whether the problem was valuable enough for organizations to keep using the solution. The answer eventually became clear. There was not enough ongoing activity to justify continuing the public service. So I shut it down. That is part of the product's engineering story too.

Conclusion

Kongres was not my largest system, nor was it the most complex architecture I have built. Its value came from the complete lifecycle. I identified a problem, designed a product around it, built the backend, deployed it, made it available to real organizations, observed how people actually used it, reviewed the data, and eventually made the decision to discontinue the public service.

The technical work taught me how to build an attendance and engagement system. The product itself taught me something more important: a working product is not necessarily a useful product. And sometimes the correct engineering decision is not to build more. It is to look at what the system is actually telling you and decide what should happen next.

Comments

Post a Comment

Popular Posts

Exploiting MS17-010 EternalBlue: SMB Flaw to SYSTEM Access

This writeup documents my exploitation of a vulnerable Windows machine using Metasploit. The goal was to identify the exposed attack surface, discover a critical vulnerability, exploit it, obtain privileged access, retrieve the flag file, and extract the NTLM hash of a user account. The exercise covered the full penetration testing workflow: Reconnaissance Vulnerability identification Exploitation Privilege verification Post-exploitation activities Reconnaissance The first step in any penetration test is understanding what is exposed. You cannot attack what you cannot see, and you should not attack blindly what you can. I ran an Nmap version scan against the target: nmap -sV <target-ip> The scan revealed the following open ports and services: 135/tcp open msrpc 139/tcp open netbios-ssn 445/tcp open microsoft-ds 3389/tcp open tcpwrapped 49152/tcp open msrpc 49153/tcp open msrpc 49154/tcp open msrpc 49155/tcp open msrpc The critical discovery was: 445/tcp ope...
Read more

God Never Wrote a Book: A Nigerian Agnostic's Case

Religion is a human system. It claims divine authorship for human documents. It asserts universal jurisdiction while displaying local origins. It promises moral order while producing observable dysfunction. This essay examines those claims directly. Let me be clear about what this is and what it is not. This is not an attack on believers. I grew up around believers. I know good people who believe. I know generous, thoughtful, hardworking people who also read Hebrews every morning and face Mecca every afternoon. This is not about them. It is about the systems they participate in. The claims those systems make. And the evidence those claims are supposed to rest on. Because the claims are extraordinary. And the evidence is not. The Fraud of Divine Authorship Let us start with the most basic question. How does a perfect, infinite, all-knowing being communicate with humanity, and the best delivery mechanism available is a human being with a pen? Every holy book was written by peop...
Read more

How I Patched CVE-2026-42945 on Monesize Nginx

On June 28, 2026, I discovered that our Monesize demo environment was running nginx 1.24.0, a version vulnerable to multiple critical security flaws including CVE-2026-42945, a remote code execution vulnerability with a CVSS score of 9.2. This post documents exactly how I identified the problem, patched it, and verified the fix, including a misconfiguration that took our applications offline for a few minutes in the process. The Discovery I was testing our authentication flow using Burp Suite Community Edition when I noticed something in the response headers coming back from our API gateway: HTTP/1.1 403 Forbidden Server: nginx/1.24.0 (Ubuntu) The Server header was leaking the exact nginx version and operating system. This is not just a cosmetic issue. Version disclosure is a reconnaissance gift. It gives an attacker a precise target to query against known vulnerability databases. Instead of probing blindly, they know exactly what they are dealing with and can search for working e...
Read more