Building for Communities You Belong To
My primary social outlet - outside of family - is my tennis club. I play a few times a week, often with my lifelong best friend Dan. Tennis keeps us in regular contact, and as a result, our relationship close. There’s nothing like competitive sports - the physical and mental exercise of a tennis match just feels healthy. At 46, that matters more than it used to.
I grew up playing tennis at this club. It’s simply a special place to me. The people are good people - happy, caring, invested in something together. It’s member-owned, which means we vote, we serve on committees, we show up for work parties. There’s no corporate landlord. It’s ours.
I also happen to build software for a living. And at some point I started to wonder - what if I actually built something for this place? Not for users, not for a market. For my club. For the people I play with every week.
The idea started small - our club uses software that works, more or less, but it’s old and clunky and owned by a company that doesn’t know us. When something breaks, we submit a ticket. When we want a feature, we wait. It’s the standard vendor relationship - we’re customers, not partners.
I kept noticing friction. Booking courts was harder than it should be. Feedback from members disappeared into a void. The board had ideas but no easy way to act on them. And every time I noticed something, I’d think: I could fix that.
So I started building. Not a startup. Not a product. Just - software for my club.
The difference is hard to explain until you’ve felt it. Building for strangers means guessing - interviewing users, running surveys, analyzing funnels, trying to understand people I’ve never met. It’s necessary work, but it’s work.
Building for my own community, I already knew. I knew the problems because I had them. I knew the people because I played with them. The feedback loop isn’t a Slack channel or a support ticket - it’s a text from a friend after Tuesday night doubles.
There’s no pitch deck. No TAM calculation. No investor asking about my go-to-market strategy. The “market” is 500 members, and I know half of them by name. Success isn’t MRR - it’s whether booking a court on Saturday morning is easier than it was last month.
A year ago, I wouldn’t have taken this on. Building a full member portal - auth, reservations, payments, admin dashboards - is a lot of work. Not impossible, but enough that it would have felt like a second job. The kind of project that starts enthusiastic and dies quietly in a half-finished GitHub repo.
But the tools have changed. I build with Claude Code now, and it’s genuinely different. Not “AI writes my code for me” different - more like having a senior engineer available at 6am when I’m working before the day starts. The velocity is higher. The activation energy is lower. Projects that used to feel like a six-month commitment now feel like something I can chip away at on weekends.
That shift matters. It means passion projects are actually possible again. Not just for companies with engineering teams, but for one person who cares about their tennis club and knows how to ship software.
I’m not suggesting everyone should build software for their tennis club. But most of us belong to something. A gym, a church, a hobby group, a neighborhood association. Communities that matter to us, run by people we know, with problems we understand.
What would it look like to build for them?