How I Built Courtlines: A Club-Management SaaS, Engineered With Claude

Table of contents

Open Table of contents

• Why a club needs an operating system, not an app
• What Courtlines actually does
• The part that surprised me: what one operator can now ship
• The principles I won’t compromise on
• Where this fits with everything else I’m building
• FAQ
  • What is Courtlines?
  • Did Claude really write most of the code?
  • Can one person really build and run a SaaS this large with AI?
  • Why build your own club software instead of using CourtReserve or Skedda?
  • Where can I learn how you actually work with Claude day to day?

Why a club needs an operating system, not an app

If you have never run a sports facility, the software problem is invisible. From the outside it looks like “people book courts.” From the inside, a club is a small, messy business with a dozen moving parts that all have to agree with each other.

A member books a court. That booking has to know whether they’re on a membership plan, whether they have credits, whether the court is already held for a clinic, whether a coach is assigned, and whether the front desk overrode the price. When they show up, someone rings up a can of balls at the counter — that’s point-of-sale. They sign their kid up for a junior program — that’s events and family accounts. They buy a 10-pack of lessons — that’s a coaching package with its own payout logic to the coach. They refer a friend — that’s a membership funnel.

Most clubs run this on three or four disconnected tools plus a spreadsheet plus a group text. The booking system doesn’t know about the POS. The POS doesn’t know about memberships. Nobody’s numbers match at the end of the month.

Courtlines is the answer to “what if all of that were one system?” It’s not a booking app with features bolted on — it’s a single operating system where the calendar, the memberships, the register, the coaching payouts, and the public event pages are all the same underlying data. That’s the whole thesis, and it’s the tagline on the site: the operating system for clubs and studios.

What Courtlines actually does

At a high level, Courtlines gives a club:

• A drag-and-drop court grid for the front desk — every reservation, clinic, and hold on one screen that an admin can rearrange in real time.
• Booking and open-play for members, including the awkward-but-essential edge cases: recurring reservations, waitlists, cancellation windows, and credits.
• Memberships and billing — plans, family accounts, junior/child logins linked to a parent, and the dunning that keeps revenue from silently leaking.
• Coaching — lesson packages, scheduling, and automated payouts to independent coaches.
• Point-of-sale — a real register for the pro shop and café, tied to the same customer record as everything else.
• Events and public pages — clinics, leagues, and tournaments with public-facing pages people can find and sign up for.

The design goal is that the platform disappears. A club puts its own brand on top, and to its members it just feels like “our club’s app,” not “some SaaS we pay for.” That’s a deliberate contrast with the incumbents in this space — the CourtReserves and Skeddas of the world — where the software is the brand and the club is the tenant.

Pickleland is tenant #1. I don’t get to hide behind a demo; the thing has to actually run a facility I’m personally on the hook for. That constraint has been the best product manager I’ve ever had. You can see Pickleland here — it’s the real-world proving ground, and every rough edge a member hits is a bug I feel the same day.

The part that surprised me: what one operator can now ship

Here’s the honest version of the story, and it’s the reason I’m writing this post rather than just launching quietly.

A multi-tenant SaaS with billing, POS, role-based access, coaching payouts, and a public event system is not a weekend project. Ten years ago, this is a seed-funded team of five to eight engineers for a year. It’s the kind of scope where a solo founder is usually told, kindly, to narrow it down to one feature and raise money.

I built it as one person, with Claude as my primary engineering partner. Not “I asked ChatGPT for a snippet sometimes” — I mean Claude wrote the large majority of the code in this system, working from specifications and product decisions I own. My job shifted from typing the implementation to deciding what’s true: what the data model should be, what a role is allowed to do, what “done” means for a feature, and what is safe to ship.

The interesting shift isn’t speed, though it is faster. It’s scope. AI didn’t make me a 2× developer on the same size of product. It changed the size of product I can credibly build and, just as importantly, operate and maintain alone. A codebase only one human wrote would collapse under its own weight. A codebase where an AI partner holds the implementation detail and I hold the architecture and the guardrails is a genuinely different kind of thing — and it’s the reason a solo operator can now go after a category that used to require a company.

I’m deliberately not publishing my exact operating playbook for Courtlines here — that’s the part I consider a competitive edge, and I’d rather my competitors keep believing this takes a big team. But if you want to see the mechanics of how I run Claude on a real project, in detail, I wrote it all up for a much smaller build: a mobile game I shipped to the app stores. See how I built Quads, a mobile board game, with Claude — same working style, nothing to hide, every trick on the table.

The principles I won’t compromise on

Even keeping the playbook private, a few principles are worth stating because they apply to anyone building serious software with AI:

The human holds the dangerous pens. There are a small number of actions where a mistake is expensive and hard to reverse — schema changes, deploys, anything that touches money or production data. Those stay firmly with me. AI can propose them; it doesn’t get to execute them. Drawing that line clearly is what makes it safe to give AI a lot of rope everywhere else.

Green tests are necessary, not sufficient. A booking flow that passes every unit test can still be visibly broken in a real browser. The most important verification for a product with a UI is a human — or a supervised process — actually clicking through it against realistic data. Tests are a gradient that keeps things from getting worse; they are not proof that a feature works. I learned this one the expensive way, and it permanently changed how I define “done.”

Specifications are the real interface. The leverage isn’t in clever prompting — it’s in maintaining clear, current documents about what the system is and what each part is supposed to do. Time spent keeping those precise pays back many times over across every future session. If you want the deeper version of this, it’s the same discipline I describe in how to write AI agent system prompts that don’t fail in production.

Build the thing you have to live with. The single best decision was making Courtlines run a facility I own. It’s easy to ship a demo that impresses; it’s impossible to hide from software that your own members depend on. If you’re building with AI, point it at a problem you personally feel — the reality check is worth more than any test suite.

Where this fits with everything else I’m building

Courtlines doesn’t exist in isolation. It’s part of a small racket-sports ecosystem I’m building: The Court Scout is a verified directory of pickleball courts, built to be genuinely more accurate than the scraped directories it competes with, and Pickleland is the flagship facility that everything gets tested against. The directory helps players find courts; Courtlines helps the clubs behind those courts actually run.

The connective tissue across all of it is the same operating model: a solo operator amplified by AI, running more surface area than a solo operator historically could. Courtlines is the most ambitious expression of that model so far — a full SaaS platform that, a few years ago, I simply would not have attempted alone.

If you run a racket-sports club or a studio and you’re tired of stitching four tools together, take a look at Courtlines. And if you’re a builder wondering how far you can push AI on a real product, that’s the whole point of this post: further than you probably think.

FAQ

What is Courtlines?

Courtlines is a multi-tenant operating system for racket-sport clubs and studios — pickleball, tennis, padel, and beyond. It combines booking, memberships, coaching, point-of-sale, and event management into one branded platform, so a club runs its whole business from a single system instead of four disconnected tools. You can see it at courtlines.com.

Did Claude really write most of the code?

Yes. Claude was my primary engineering partner and wrote the large majority of the implementation, working from specifications, architecture, and product decisions I own and control. I hold the schema, the deploys, and the definition of “done”; the AI holds the implementation detail. That division of labor is what makes a solo-built SaaS of this scope sustainable to maintain.

Can one person really build and run a SaaS this large with AI?

Building it is now genuinely feasible — that’s the surprising part. The bigger challenge is operating and maintaining it, because a large codebase needs someone who understands the architecture even when an AI wrote the details. The key is keeping clear specifications and holding firm on the small number of high-risk actions a human must own. Done that way, the maintainable surface area for one operator is far larger than it used to be.

Why build your own club software instead of using CourtReserve or Skedda?

Because running Pickleland showed me exactly where the existing tools fall short: the booking system, the register, and the memberships don’t share one source of truth, so nothing reconciles cleanly. I wanted a system where all of it is the same underlying data and where the club’s brand — not the software vendor’s — is what members see. That’s the gap Courtlines is built to close.

Where can I learn how you actually work with Claude day to day?

I keep the detailed Courtlines playbook private for competitive reasons, but I documented the exact same working style on a smaller, fully open project — a mobile board game called Quads. Read how I built Quads, a mobile board game, with Claude for the mechanics, or how I decide whether an automation is worth building for the ROI thinking behind everything I ship.