Hoe ik Courtlines bouwde: een SaaS voor clubbeheer, ontwikkeld met Claude

Inhoudsopgave

Bijgewerkt in juli 2026.

Kort samengevat: Courtlines is het besturingssysteem voor racketsportclubs en -studio’s — reserveringen, lidmaatschappen, coaching, kassa en evenementen onder één merkdak. Ik bouwde het als solo-operator met Claude als mijn engineering-partner. De les: AI liet me niet alleen sneller programmeren, het veranderde de omvang van het product dat één persoon geloofwaardig kan lanceren en runnen.

[Blik van de operator] Ik run meer dan 30 productie-agents verspreid over een consultingmerk en Pickleland, de pickleball-faciliteit die ik uitbaat in de regio Austin, TX. Het runnen van een echte faciliteit leerde me precies hoe slecht de software voor clubs zoals de mijne is — dus bouwde ik de software die ik zelf had willen hebben. Dit is het verhaal van Courtlines, wat het doet, en hoe leunen op Claude één persoon in staat stelde om iets te bouwen waar normaal een heel team voor nodig is.

Waarom een club een besturingssysteem nodig heeft, geen app

Als je nooit een sportfaciliteit hebt gerund, is het softwareprobleem onzichtbaar. Van buitenaf ziet het eruit als “mensen reserveren banen.” Van binnenuit is een club een klein, rommelig bedrijf met een tiental bewegende onderdelen die het allemaal met elkaar eens moeten zijn.

Een lid reserveert een baan. Die reservering moet weten of ze een lidmaatschapsplan hebben, of ze tegoeden hebben, of de baan al gereserveerd is voor een clinic, of er een coach is toegewezen, en of de balie de prijs heeft aangepast. Wanneer ze verschijnen, rekent iemand aan de balie een blik ballen af — dat is de kassa. Ze schrijven hun kind in voor een jeugdprogramma — dat zijn evenementen en gezinsaccounts. Ze kopen een pakket van 10 lessen — dat is een coachingpakket met zijn eigen uitbetalingslogica naar de coach. Ze verwijzen een vriend door — dat is een lidmaatschapstrechter.

De meeste clubs runnen dit op drie of vier losgekoppelde tools plus een spreadsheet plus een groepsapp. Het reserveringssysteem weet niets van de kassa. De kassa weet niets van lidmaatschappen. Aan het eind van de maand kloppen niemands cijfers.

Courtlines is het antwoord op “wat als dat allemaal één systeem was?” Het is geen reserveringsapp met er functies bovenop geschroefd — het is één enkel besturingssysteem waarin de agenda, de lidmaatschappen, de kassa, de coachinguitbetalingen en de openbare evenementenpagina’s allemaal dezelfde onderliggende data zijn. Dat is de hele these, en het is de slogan op de site: het besturingssysteem voor clubs en studio’s.

Wat Courtlines echt doet

Op hoofdlijnen geeft Courtlines een club:

• Een sleep-en-neerzet baanraster voor de balie — elke reservering, clinic en blokkering op één scherm dat een beheerder in realtime kan herschikken.
• Reserveringen en vrij spel voor leden, inclusief de ongemakkelijke-maar-essentiële randgevallen: terugkerende reserveringen, wachtlijsten, annuleringsvensters en tegoeden.
• Lidmaatschappen en facturatie — plannen, gezinsaccounts, jeugd-/kinderlogins gekoppeld aan een ouder, en het aanmaanproces dat voorkomt dat inkomsten stilletjes weglekken.
• Coaching — lespakketten, planning en geautomatiseerde uitbetalingen aan zelfstandige coaches.
• Kassa — een echte kassa voor de pro shop en het café, gekoppeld aan dezelfde klantgegevens als al het andere.
• Evenementen en openbare pagina’s — clinics, competities en toernooien met openbare pagina’s die mensen kunnen vinden en waarvoor ze zich kunnen inschrijven.

Het ontwerpdoel is dat het platform verdwijnt. Een club zet zijn eigen merk erbovenop, en voor de leden voelt het gewoon als “de app van onze club,” niet als “een of andere SaaS waarvoor we betalen.” Dat is een bewust contrast met de gevestigde spelers in deze ruimte — de CourtReserves en Skedda’s van deze wereld — waar de software het merk is en de club de huurder.

Pickleland is tenant #1. Ik kan me niet verschuilen achter een demo; het ding moet daadwerkelijk een faciliteit runnen waarvoor ik persoonlijk verantwoordelijk ben. Die beperking is de beste productmanager die ik ooit heb gehad. Je kunt Pickleland hier bekijken — het is de proeftuin in de echte wereld, en elke ruwe rand waar een lid tegenaan loopt is een bug die ik dezelfde dag voel.

Het deel dat me verraste: wat één operator nu kan lanceren

Hier is de eerlijke versie van het verhaal, en het is de reden dat ik dit bericht schrijf in plaats van gewoon stilletjes te lanceren.

Een multi-tenant SaaS met facturatie, kassa, rolgebaseerde toegang, coachinguitbetalingen en een openbaar evenementensysteem is geen weekendproject. Tien jaar geleden was dit een seed-gefinancierd team van vijf tot acht engineers voor een jaar. Het is het soort omvang waarbij een solo-oprichter meestal vriendelijk wordt geadviseerd om het terug te brengen tot één functie en geld op te halen.

Ik bouwde het als één persoon, met Claude als mijn belangrijkste engineering-partner. Niet “ik vroeg ChatGPT soms om een snippet” — ik bedoel dat Claude de grote meerderheid van de code in dit systeem schreef, werkend vanuit specificaties en productbeslissingen die van mij zijn. Mijn werk verschoof van de implementatie typen naar beslissen wat waar is: hoe het datamodel eruit moet zien, wat een rol mag doen, wat “klaar” betekent voor een functie, en wat veilig is om te lanceren.

De interessante verschuiving is niet snelheid, hoewel het wel sneller is. Het is omvang. AI maakte me geen 2×-ontwikkelaar op dezelfde productomvang. Het veranderde de omvang van het product dat ik geloofwaardig kan bouwen en, net zo belangrijk, alleen kan bedienen en onderhouden. Een codebase die maar één mens schreef zou onder zijn eigen gewicht bezwijken. Een codebase waarin een AI-partner het implementatiedetail vasthoudt en ik de architectuur en de vangrails vasthoud, is een werkelijk ander soort ding — en het is de reden dat een solo-operator nu een categorie kan bestormen die vroeger een heel bedrijf vereiste.

Ik publiceer hier bewust niet mijn exacte draaiboek voor Courtlines — dat is het deel dat ik als concurrentievoordeel beschouw, en ik heb liever dat mijn concurrenten blijven geloven dat dit een groot team kost. Maar als je de mechaniek wilt zien van hoe ik Claude op een echt project draai, in detail, dan heb ik het allemaal opgeschreven voor een veel kleinere build: een mobiele game die ik naar de app stores bracht. Zie hoe ik Quads, een mobiel bordspel, met Claude bouwde — dezelfde werkwijze, niets te verbergen, alle trucs op tafel.

De principes waarop ik geen compromissen sluit

Zelfs met het draaiboek privé, zijn een paar principes het vermelden waard omdat ze gelden voor iedereen die serieuze software met AI bouwt:

De mens houdt de gevaarlijke pennen vast. Er is een klein aantal handelingen waarbij een fout duur en moeilijk terug te draaien is — schemawijzigingen, deploys, alles wat geld of productiedata raakt. Die blijven stevig bij mij. AI mag ze voorstellen; het mag ze niet uitvoeren. Die grens duidelijk trekken is wat het veilig maakt om AI overal elders veel speelruimte te geven.

Groene tests zijn noodzakelijk, niet voldoende. Een reserveringsflow die elke unittest doorstaat, kan nog steeds zichtbaar kapot zijn in een echte browser. De belangrijkste verificatie voor een product met een gebruikersinterface is een mens — of een begeleid proces — die er daadwerkelijk doorheen klikt tegen realistische data. Tests zijn een gradient die dingen verhindert slechter te worden; ze zijn geen bewijs dat een functie werkt. Deze les leerde ik op de dure manier, en het veranderde permanent hoe ik “klaar” definieer.

Specificaties zijn de echte interface. De hefboom zit niet in slim prompten — het zit in het onderhouden van heldere, actuele documenten over wat het systeem is en wat elk onderdeel geacht wordt te doen. Tijd besteed aan het precies houden daarvan betaalt zich vele malen terug over elke toekomstige sessie. Wil je de diepere versie hiervan, dan is het dezelfde discipline die ik beschrijf in hoe je systeemprompts voor AI-agents schrijft die niet falen in productie.

Bouw het ding waarmee je moet leven. De allerbeste beslissing was Courtlines een faciliteit laten runnen die van mij is. Het is makkelijk om een demo te lanceren die indruk maakt; het is onmogelijk je te verschuilen voor software waar je eigen leden van afhankelijk zijn. Als je met AI bouwt, richt het dan op een probleem dat je persoonlijk voelt — de realiteitscheck is meer waard dan welke testsuite dan ook.

Waar dit past bij al het andere dat ik bouw

Courtlines bestaat niet in isolatie. Het is onderdeel van een klein racketsport-ecosysteem dat ik bouw: The Court Scout is een geverifieerde gids van pickleball-banen, gebouwd om werkelijk nauwkeuriger te zijn dan de gescrapete gidsen waarmee het concurreert, en Pickleland is de vlaggenschipfaciliteit waartegen alles wordt getest. De gids helpt spelers banen te vinden; Courtlines helpt de clubs achter die banen om daadwerkelijk te draaien.

Het bindweefsel over alles heen is hetzelfde operationele model: een solo-operator versterkt door AI, die meer terrein bestrijkt dan een solo-operator historisch gezien kon. Courtlines is tot nu toe de meest ambitieuze uitdrukking van dat model — een volledig SaaS-platform waar ik een paar jaar geleden simpelweg niet alleen aan begonnen zou zijn.

Als je een racketsportclub of een studio runt en je bent het zat om vier tools aan elkaar te knopen, werp dan een blik op Courtlines. En als je een bouwer bent die zich afvraagt hoe ver je AI kunt duwen op een echt product, dan is dat het hele punt van dit bericht: verder dan je waarschijnlijk denkt.

Veelgestelde vragen

Wat is Courtlines?

Courtlines is een multi-tenant besturingssysteem voor racketsportclubs en -studio’s — pickleball, tennis, padel en verder. Het combineert reserveringen, lidmaatschappen, coaching, kassa en evenementenbeheer in één merkplatform, zodat een club zijn hele bedrijf vanuit één systeem runt in plaats van vier losgekoppelde tools. Je kunt het bekijken op courtlines.com.

Heeft Claude echt het grootste deel van de code geschreven?

Ja. Claude was mijn belangrijkste engineering-partner en schreef de grote meerderheid van de implementatie, werkend vanuit specificaties, architectuur en productbeslissingen die ik bezit en beheer. Ik houd het schema, de deploys en de definitie van “klaar” vast; de AI houdt het implementatiedetail vast. Die taakverdeling is wat een solo-gebouwde SaaS van deze omvang onderhoudbaar maakt.

Kan één persoon echt een SaaS van deze omvang bouwen en runnen met AI?

Het bouwen ervan is nu werkelijk haalbaar — dat is het verrassende deel. De grotere uitdaging is het bedienen en onderhouden ervan, want een grote codebase heeft iemand nodig die de architectuur begrijpt, zelfs wanneer een AI de details schreef. De sleutel is heldere specificaties bijhouden en standvastig blijven op het kleine aantal handelingen met hoog risico die een mens moet bezitten. Op die manier gedaan is het onderhoudbare terrein voor één operator veel groter dan het vroeger was.

Waarom je eigen clubsoftware bouwen in plaats van CourtReserve of Skedda te gebruiken?

Omdat het runnen van Pickleland me precies liet zien waar de bestaande tools tekortschieten: het reserveringssysteem, de kassa en de lidmaatschappen delen niet één bron van waarheid, dus niets sluit netjes op elkaar aan. Ik wilde een systeem waarin het allemaal dezelfde onderliggende data is en waarin het merk van de club — niet dat van de softwareleverancier — is wat leden zien. Dat is het gat dat Courtlines is gebouwd om te dichten.

Waar kan ik leren hoe je dagelijks daadwerkelijk met Claude werkt?

Ik houd het gedetailleerde Courtlines-draaiboek privé om concurrentieredenen, maar ik documenteerde exact dezelfde werkwijze op een kleiner, volledig open project — een mobiel bordspel genaamd Quads. Lees hoe ik Quads, een mobiel bordspel, met Claude bouwde voor de mechaniek, of hoe ik bepaal of een automatisering het bouwen waard is voor het rendementsdenken achter alles wat ik lanceer.