OrgFlow

Student organizations were managing attendance, membership, and recurring operations across disconnected tools. I interviewed leaders across 15+ organizations, reframed the problem from attendance tracking to operational coordination, and helped build OrgFlow across product strategy, design, frontend, backend, and deployment. The product reached 500+ users and reduced executive-board administrative work by 23%.

Student organizations already had plenty of tools. The problem was that none of them worked together. Attendance might live in a Google Form, membership information in a spreadsheet, event updates in GroupMe or Slack, and historical knowledge with whichever executive happened to own the process that semester.

Individual tools worked, but the overall system created repetitive administrative work and made transitions between leadership teams difficult. I initially saw an opportunity to make attendance easier, but after speaking with leaders across 15+ student organizations, I realized attendance collection was only one visible part of a much larger problem. Organizations did not primarily need another way to check members in. They needed a reliable place to manage the information and recurring workflows that kept an organization running.

I spoke with student organization leaders about how they managed membership, meetings, attendance, events, and officer responsibilities. Rather than asking which features they wanted, I focused on their existing processes: where information lived, what they updated manually, what happened when a new officer took over, and which recurring tasks created the most work.

A consistent pattern emerged. An officer might collect attendance through a form, export it into a spreadsheet, manually compare it against a roster, and later use that information to determine engagement or membership standing. Another officer might maintain a separate version of the same member list. The problem was not one catastrophic failure. It was dozens of small administrative tasks repeated every week.

My original framing was, “How might we make attendance easier for student organizations?” Research changed that to, “How might we reduce the operational overhead required to manage an organization over time?” That distinction mattered because it changed OrgFlow from a single-purpose attendance tool into a shared operational layer.

At the same time, I did not want it to become an all-in-one platform before we had proven that students would consistently use the core experience. The challenge became deciding which workflows needed to exist together for the product to be useful.

The opportunity space quickly became large. Organization leaders could potentially use the product for communication, recruiting, event planning, dues, analytics, scheduling, member discovery, and dozens of other tasks. Building everything would have made the product more impressive on paper but less focused in practice.

I prioritized functionality based on three factors: frequency, operational cost, and shared value. I asked whether a problem happened repeatedly, whether solving it would meaningfully reduce manual work, and whether the information became more valuable when multiple officers could access it. That pushed membership management, attendance, and centralized organizational records toward the center of the MVP while other ideas remained future opportunities.

This became an important product lesson for me: a roadmap is not a list of everything that could create value. It is a decision about which value needs to exist first.

I did not want organizations to completely change how they operated in order to adopt OrgFlow. The experience therefore needed to make familiar tasks easier while removing the repetitive work around them. The core workflow connected organization-level information, member records, and attendance so that data collected during one activity could remain useful later instead of becoming another isolated spreadsheet.

I worked across the product experience, including UI/UX, frontend development, backend logic, deployment, product strategy, and roadmap prioritization. That gave me a different relationship with feasibility than I had in purely design-oriented projects. A feature was not finished when a screen looked correct. I had to consider what data it required, how that data persisted, what happened when users made mistakes, and whether the workflow still made sense after repeated use.

OrgFlow was built with React, Next.js, TypeScript, and SQL. Working close to implementation forced me to make product decisions earlier because every addition introduced new states, edge cases, and dependencies. Instead of optimizing for feature count, I focused on whether the core workflow was coherent.

I asked what information should be stored once and reused, which actions should require an executive versus a general member, what should happen when a member's status changed, and how much information someone actually needed at the point of action. Those implementation details became product decisions because they directly affected whether OrgFlow reduced work or simply digitized the same work.

For OrgFlow, adoption alone was not enough. Someone creating an account did not necessarily mean the product had solved the operational problem. The more meaningful signal was whether organizations could use the product to reduce recurring administrative work.

OrgFlow ultimately reached 500+ users, and executive-board workflows saw a 23% reduction in administrative work. That result mattered because it connected directly back to the original problem: the goal was never to create another place for organizations to store data, but to reduce the effort required to keep an organization running.

If I continued developing OrgFlow, I would build the measurement strategy around repeated organizational value rather than raw sign-ups. I would look at weekly active organizations, repeat attendance usage, percentage of organizations completing recurring workflows through OrgFlow, executive time saved, adoption across multiple officers, and retention across semester transitions.

One metric I would especially want to understand is whether the product survives leadership turnover. If a new executive board continues using OrgFlow without the original champion pushing adoption, that would be a much stronger signal that the product has become part of the organization's operating system.

OrgFlow taught me that the first version of a problem is rarely the most useful one. I started by seeing an attendance problem, research revealed an operational coordination problem, and building the product showed me that solving that problem required more than simplifying individual tasks. The information created by those tasks needed to remain connected and useful over time.

It also changed how I think about MVPs. The best MVP is not simply the smallest set of features that can technically ship. It is the smallest product that allows users to experience the core value proposition end to end. For OrgFlow, that meant moving beyond attendance while still resisting the temptation to build everything an organization could eventually need.