Inside PayDues: building software for student-run organizations

Software for organizations that rebuild themselves every year

Student-run organizations are one of the hardest environments to build software for — and one of the most overlooked. A chapter isn't a small business with a stable team. It's an institution that replaces most of its leadership every single year, runs on volunteers with no formal training, and handles real money on behalf of its members. Most financial tools quietly assume none of that is true. Building PayDues meant taking those constraints seriously instead of designing around them. Here's how they shape the product.

Turnover is the default, not the exception

In most software, the people using it this year will mostly be using it next year. In a chapter, they won't. The treasurer who finally figured out your system graduates, and a sophomore who has never run finances for anything inherits the keys in May. So our first design rule is that the tool has to be learnable in an afternoon and survive a handoff. If a feature only works because one person remembers a trick, it's broken by design. We optimize for the person who's never seen the software before, because next year that's everyone.

The treasurer is a volunteer, not an accountant

The person running chapter finance is usually a full-time student doing this on top of classes, a job, and the rest of their life. They didn't sign up to become a bookkeeper. That means the boring, repetitive work — sending reminders, reconciling payments, chasing overdue balances — should be automated, not delegated to someone's evenings. Our job is to take the parts of the role that cause burnout off the treasurer's plate so they can spend their limited time on the parts that genuinely need a human.

Trust is the whole product

When members hand their dues to the chapter, they're trusting that the money is tracked, safe, and accounted for. When a chapter hands its finances to us, it's trusting the same thing at a larger scale. That trust is the actual product — the features are just how we earn it. So payments run on infrastructure built by people who do payments for a living, every charge and waiver is logged and exportable, and the records are clean enough that a treasurer handoff or an exec-board question is answered in minutes, not archaeology. We'd rather be boring and trustworthy than clever and opaque.

What we optimize for

A few principles guide most of the decisions:

• Clarity over features. A treasurer who understands the tool beats a powerful tool nobody can run.
• Automate the thankless parts. Reminders and reconciliation should happen on their own.
• Mobile-first, always. Members pay from their phones, between classes — so paying has to take under a minute.
• Clean records by default. Good data shouldn't require discipline; it should be what naturally happens.
• Design for the handoff. Every screen should make sense to someone who started yesterday.

Where we're headed

The long-term goal is simple to say and hard to do: make running chapter finance feel less like a second job and more like a solved problem. Every release is measured against that — does it make the treasurer's life easier, does it survive next year's turnover, and does it keep the chapter's money clear and trustworthy? Student organizations do a lot with very little. The least their software can do is get out of the way.