The Pickleball Club That Ran on a Single Spreadsheet

Somebody on the board of the Laramie Pickleball Association had a spreadsheet. Two tabs. The first listed 142 members, with columns headed 2022, 2023, 2024, 2025 and 2026, and the way you knew whether a member had paid was a lowercase x sitting in the right column. The second tab was a hand-kept check register: date, member, withdrawal, deposit, running balance. We replaced it with a custom membership web app that tracks members, takes dues online and signs people in with Google. It's live at laramiepickleballassociation.net.

Here's the part people get wrong about that spreadsheet, though: it worked.

Jump to: What the spreadsheet was doing · Dues · Login · Where the data lives · What the board got · FAQ

It had been keeping a real club running for five seasons. Somebody built it, somebody maintained it, and every year the dues got collected and the books balanced. That is not a broken process. That is a volunteer doing an unglamorous job well, for free, on a Sunday.

The problem was never the spreadsheet. The problem was that the spreadsheet was load-bearing.

What the spreadsheet was actually doing

We say a version of this to almost every client, usually about a RevOps person exporting CSVs at 11pm on a Friday: if the answer to "how does this work" is a person and a file, the stack is broken, not the person. Volunteer boards are the same story with lower pay and better snacks.

Look at what that one file was quietly responsible for:

• The membership roster. Names, emails, phone numbers, birthdays.
• The payment ledger. Five years of who paid, encoded as the presence or absence of a single character.
• The treasury. A running balance maintained by hand, in a column, next to a "receipt?" checkbox.
• Institutional memory. Which is to say: whoever had the file open.

Every one of those is fine on its own. Stacked together in one document that lives on one person's machine, they become a single point of failure with a board election attached to it. Officers rotate. The treasurer changes. And the handoff for all four of those responsibilities is emailing an .xlsx and hoping the next person opens it in something that doesn't reformat the dates.

There is also the small matter of a member asking "am I paid up?" and the only way to answer being to open a file and squint at a column.

Dues: the part everyone underestimates

Taking $20 online sounds like the easy half. It is reliably the half that eats the schedule.

Season dues for 2026 are $20, and we wired them through PayPal's REST v2 API against live credentials. Two endpoints do the work: one creates the order, one captures it after the member approves. The client id is public and gets passed to the buttons component. The secret is server-only and never touches the browser, which is the sort of thing that is obvious right up until somebody ships it in a NEXT_PUBLIC_ variable.

The detail that actually matters is what happens after the capture. A payment that succeeds but doesn't update the member's record is worse than no payment system, because now you have two sources of truth that disagree and neither of them is a spreadsheet you understand. So the capture writes the dues record against the member, tagged with the season. The board's answer to "who has paid for 2026" stopped being a column of x's and became a query.

We've written before about when to build this yourself versus buying it, and for a club this size the maths is not subtle. Membership SaaS gets priced per member per month, forever, for a club that collects twenty bucks a head once a year.

Login, without inventing a password problem

Every club site eventually asks the same question: how do members log in?

The wrong answer, and the common one, is to roll your own email-and-password. Now you own password resets, hashing, breach exposure and a support burden staffed by volunteers. For a pickleball club. No thanks.

Members sign in with Google. The ID token comes back to the server, gets verified there, and becomes a signed session cookie: a 30-day JWT using jose, with the admin flag baked into the claim so the board-only routes have something to check that the browser can't edit.

Then there's the second, less obvious piece. The app also runs its own OAuth 2.1 authorization server, PKCE with S256 required, supporting authorization-code and refresh-token grants for public clients. That is not for members. That is so an AI assistant can connect to the club's own data with the board's permission and without anybody pasting an API key into a chat window. Same pattern we run on our own back office, which we wrote up here.

Is that overkill for a pickleball club? Probably, today. It also took an afternoon because we'd already built it once, which is the entire argument for a senior bench over a big org chart.

Where the data lives, and why it mattered on day one

The database is SQLite, and it lives outside the deploy directory.

That sentence is boring and it is the single most important line in the deploy script. Put the database inside the folder you rsync to, and the first routine deployment quietly overwrites five years of membership history with an empty file. We've all met somebody that happened to. Some of us have been somebody that happened to, which is precisely why it's configured this way now.

There is a separate dev site on its own port with its own database, so changes get tried somewhere that isn't the live club. The staging environment nobody trusts is a real failure mode, and the fix is making staging cheap enough that people actually use it.

What the board actually got

A public site, a member dashboard, and a board-only admin area, at laramiepickleballassociation.net. Members see the schedule, events, their own profile and whether they're paid up. The board sees members, payments, events and who else has admin.

The spreadsheet is still around. It should be. It's five years of history and it earned its retirement. It just isn't the thing standing between the club and its own membership list any more.

We're in Glenrock, Wyoming. Laramie is up the road. Building the local pickleball club's membership system is not going to appear in a quarterly deck anywhere, and it was one of the more satisfying builds of the year, because the person on the other end of it was a volunteer who now gets their Sundays back.

My knees, for the record, remain firmly on the sidelines.

Frequently asked questions

How much does a custom club membership app cost? It depends almost entirely on payments and login, which are the two pieces that carry real risk. A roster and an events list are straightforward. Taking money and holding identities is where the hours go. Our custom development engagements start at a project fee rather than a per-member subscription, which is usually the deciding factor for a club with a fixed annual dues income.

Why not use off-the-shelf membership software? For a lot of clubs, you should. If a SaaS product fits your dues structure and your board is happy with the per-member pricing, buy it and go play. Building makes sense when the recurring cost outgrows the one-time cost, when you need something the product won't do, or when you want the data to stay yours.

Can members pay dues online without an account? In this build, dues are tied to a member record, because the whole point was answering "who has paid this season" without a spreadsheet. A payment that isn't attached to a person just moves the reconciliation problem somewhere else.

Is Google sign-in a requirement for members? It's the path we shipped first because it removes password handling entirely. Most people already have a Google account, and the ones who don't can be added by the board directly.

What happens when the board changes? Admin is a flag on the member record, managed from the admin area. An outgoing treasurer hands over by having the new one promoted, not by emailing a file. That was one of the actual goals.

Do we need a developer to keep it running? It runs itself day to day. Someone should own it in the same way someone owns the club's bank account, but adding members, recording payments and posting events are all things the board does without touching code.

If your club is running on one spreadsheet

You probably don't need a big rebuild. You need the two or three things that stop being fun once the club grows: dues that collect themselves, a roster that isn't a file, and a way to hand the job to the next volunteer without a training session.

That's a custom web development project measured in weeks, not quarters. If you want to see what it looks like finished first, the Laramie Pickleball Association site is live and it's a fair representation of the work.

Or tell us what your spreadsheet is doing and we'll tell you honestly whether it's worth replacing.