[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"blog-courtside-alley-venue-booking-lessons-philippines":3,"blog-nav-courtside-alley-venue-booking-lessons-philippines":26},{"slug":4,"title":5,"description":6,"body":7,"category":8,"readTime":9,"tags":10,"coverImage":13,"coverImageAlt":14,"heroImage":15,"heroImageAlt":14,"metaTitle":16,"metaDescription":17,"ogImage":18,"noindex":19,"published":20,"publishAt":21,"sortOrder":22,"updatedAt":21,"status":23,"path":24,"bodyHtml":25},"courtside-alley-venue-booking-lessons-philippines","Courtside Alley: venue booking lessons from a live Philippine platform","What we learned running pickleball bookings in production — availability as the product, venue-specific domain, two surfaces, one brain. Not the origin story.","People search **Courtside Alley** because they want to play — or they want to know how a Philippine venue actually takes bookings online. This is the second kind of article: **production lessons** from a live pickleball booking platform, not the origin story.\n\nThe origin story is already written: [from spreadsheets to production](\u002Fblog\u002Fbuilding-courtside-alley-from-spreadsheets-to-production). The product is live at [courtsidealley.com](https:\u002F\u002Fcourtsidealley.com). Here is what we would repeat — and what we would not skip — on the next venue build.\n\n## Lesson 1: Availability is the product\n\nPlayers do not care about your CMS. They care whether **the slot they see is still free** when they tap pay.\n\nThat forced us to treat the schedule as a domain, not a calendar plugin:\n\n- Court rental vs open play are different products on the same clock\n- Club-reserved time must disappear from guest booking without mysterious 404s\n- Mobile is the default client — desktop-only admin thinking leaks into the player flow and they leave\n\nIf your venue still confirms in Viber after the website says “available,” you do not have online booking. You have a brochure with extra steps. Same pattern as [booking ops on mobile and web](\u002Fblog\u002Fbooking-ops-apps-mobile-web).\n\n## Lesson 2: Model the venue, not “a generic booking SaaS”\n\nGeneric booking UX assumes one resource, one timezone, one price, one “appointment.” Pickleball (and a lot of PH venues) does not:\n\n| Concept | Why a template fights it |\n|---------|--------------------------|\n| Open play | Pay per player, drop-in, level mixing |\n| Court rental | Hourly, group-owned, you control games |\n| Club portal | Roster and locked slots, not consumer accounts |\n| Location growth | Second site should not fork the schema |\n\nWe spent the time on **states and permissions** before pretty cards. That is the same habit as [modeling the domain before controllers](\u002Fblog\u002Fwhy-we-model-the-domain-before-writing-controllers). Copying a foreign gym app and slapping a peso sign on it is how you get double-books.\n\n## Lesson 3: Two surfaces, one brain\n\n**Nuxt** for players: browse courts, see what is on, book in a few taps. **Laravel** for the platform: courts, sessions, clubs, payments, staff tools.\n\nPlayers get a fast public site. Operators get software that matches how a club actually runs. When those two disagree, trust dies in a group chat. API-first is not architecture theater here — it is how you avoid two sources of truth. See [how we build](\u002Fblog\u002Fhow-we-build-scalable-web-applications).\n\n## Lesson 4: Launch is an operations event\n\nGoing live meant:\n\n- Staff using the admin on a real Saturday, not a staging script\n- A path for closures and “what’s happening at the courts” so players are not surprised at the gate\n- Staying after cutover — venue software fails in the first month of edge cases (rain, no-shows, walk-ins)\n\nA demo that books one happy path on Wi-Fi is not production. Production is the awkward Saturday.\n\n## Lesson 5: Do not turn the case study into the only product\n\nCourtside Alley is a specific club and a specific platform. The reusable part is the **pattern**: live inventory, clear products, operator tools, mobile-first players.\n\nIf you run a clinic, court, or studio, your rules will differ. The questions stay:\n\n- What is the unit of inventory?\n- Who may override a booking?\n- What happens to money when plans change?\n- Can a staff member trust the screen without opening a spreadsheet?\n\n## What we would not do again\n\n- Starting from a page builder and “adding booking later”\n- Treating open play as a blog post with a GCash number\n- Shipping player UI before club and staff workflows exist\n- Assuming one location’s rules will survive a second site without a model\n\n## Straight next step\n\nIf you want the story of how it started, read the [Courtside Alley case study](\u002Fblog\u002Fbuilding-courtside-alley-from-spreadsheets-to-production) and the [work page](\u002Fwork\u002Fcourtside-alley). If you want to know whether *your* venue needs the same shape of system, [tell us how you book today](\u002Fcontact) — spreadsheet, Facebook, or a tool that almost works. We will be direct about custom software versus tightening what you already have.","Case study",7,[8,11,12],"Booking","Philippines","\u002Fimages\u002Fjournal\u002Fcourtside-alley-venue-booking-lessons-philippines-cover.webp?v=20261013b","Courtside Alley online booking screen showing live court availability","\u002Fimages\u002Fjournal\u002Fcourtside-alley-venue-booking-lessons-philippines-hero.webp?v=20261013b","Courtside Alley Booking Lessons | PrimeCode","Courtside Alley venue booking lessons for Philippine operators — live availability, open play vs rental, and what not to skip after launch.","\u002Fimages\u002Fjournal\u002Fcourtside-alley-venue-booking-lessons-philippines-og.webp?v=20261013b",false,true,"2026-09-18T01:00:00.000Z",40,"live","\u002Fblog\u002Fcourtside-alley-venue-booking-lessons-philippines","\u003Cp>People search \u003Cstrong>Courtside Alley\u003C\u002Fstrong> because they want to play — or they want to know how a Philippine venue actually takes bookings online. This is the second kind of article: \u003Cstrong>production lessons\u003C\u002Fstrong> from a live pickleball booking platform, not the origin story.\u003C\u002Fp>\n\u003Cp>The origin story is already written: \u003Ca href=\"\u002Fblog\u002Fbuilding-courtside-alley-from-spreadsheets-to-production\" rel=\"noopener noreferrer\">from spreadsheets to production\u003C\u002Fa>. The product is live at \u003Ca href=\"https:\u002F\u002Fcourtsidealley.com\" rel=\"noopener noreferrer\">courtsidealley.com\u003C\u002Fa>. Here is what we would repeat — and what we would not skip — on the next venue build.\u003C\u002Fp>\n\u003Ch2>Lesson 1: Availability is the product\u003C\u002Fh2>\n\u003Cp>Players do not care about your CMS. They care whether \u003Cstrong>the slot they see is still free\u003C\u002Fstrong> when they tap pay.\u003C\u002Fp>\n\u003Cp>That forced us to treat the schedule as a domain, not a calendar plugin:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Court rental vs open play are different products on the same clock\u003C\u002Fli>\n\u003Cli>Club-reserved time must disappear from guest booking without mysterious 404s\u003C\u002Fli>\n\u003Cli>Mobile is the default client — desktop-only admin thinking leaks into the player flow and they leave\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>If your venue still confirms in Viber after the website says “available,” you do not have online booking. You have a brochure with extra steps. Same pattern as \u003Ca href=\"\u002Fblog\u002Fbooking-ops-apps-mobile-web\" rel=\"noopener noreferrer\">booking ops on mobile and web\u003C\u002Fa>.\u003C\u002Fp>\n\u003Ch2>Lesson 2: Model the venue, not “a generic booking SaaS”\u003C\u002Fh2>\n\u003Cp>Generic booking UX assumes one resource, one timezone, one price, one “appointment.” Pickleball (and a lot of PH venues) does not:\u003C\u002Fp>\n\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>Concept\u003C\u002Fth>\n\u003Cth>Why a template fights it\u003C\u002Fth>\n\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\u003Ctr>\n\u003Ctd>Open play\u003C\u002Ftd>\n\u003Ctd>Pay per player, drop-in, level mixing\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Court rental\u003C\u002Ftd>\n\u003Ctd>Hourly, group-owned, you control games\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Club portal\u003C\u002Ftd>\n\u003Ctd>Roster and locked slots, not consumer accounts\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Location growth\u003C\u002Ftd>\n\u003Ctd>Second site should not fork the schema\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003C\u002Ftbody>\u003C\u002Ftable>\n\u003Cp>We spent the time on \u003Cstrong>states and permissions\u003C\u002Fstrong> before pretty cards. That is the same habit as \u003Ca href=\"\u002Fblog\u002Fwhy-we-model-the-domain-before-writing-controllers\" rel=\"noopener noreferrer\">modeling the domain before controllers\u003C\u002Fa>. Copying a foreign gym app and slapping a peso sign on it is how you get double-books.\u003C\u002Fp>\n\u003Ch2>Lesson 3: Two surfaces, one brain\u003C\u002Fh2>\n\u003Cp>\u003Cstrong>Nuxt\u003C\u002Fstrong> for players: browse courts, see what is on, book in a few taps. \u003Cstrong>Laravel\u003C\u002Fstrong> for the platform: courts, sessions, clubs, payments, staff tools.\u003C\u002Fp>\n\u003Cp>Players get a fast public site. Operators get software that matches how a club actually runs. When those two disagree, trust dies in a group chat. API-first is not architecture theater here — it is how you avoid two sources of truth. See \u003Ca href=\"\u002Fblog\u002Fhow-we-build-scalable-web-applications\" rel=\"noopener noreferrer\">how we build\u003C\u002Fa>.\u003C\u002Fp>\n\u003Ch2>Lesson 4: Launch is an operations event\u003C\u002Fh2>\n\u003Cp>Going live meant:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Staff using the admin on a real Saturday, not a staging script\u003C\u002Fli>\n\u003Cli>A path for closures and “what’s happening at the courts” so players are not surprised at the gate\u003C\u002Fli>\n\u003Cli>Staying after cutover — venue software fails in the first month of edge cases (rain, no-shows, walk-ins)\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>A demo that books one happy path on Wi-Fi is not production. Production is the awkward Saturday.\u003C\u002Fp>\n\u003Ch2>Lesson 5: Do not turn the case study into the only product\u003C\u002Fh2>\n\u003Cp>Courtside Alley is a specific club and a specific platform. The reusable part is the \u003Cstrong>pattern\u003C\u002Fstrong>: live inventory, clear products, operator tools, mobile-first players.\u003C\u002Fp>\n\u003Cp>If you run a clinic, court, or studio, your rules will differ. The questions stay:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>What is the unit of inventory?\u003C\u002Fli>\n\u003Cli>Who may override a booking?\u003C\u002Fli>\n\u003Cli>What happens to money when plans change?\u003C\u002Fli>\n\u003Cli>Can a staff member trust the screen without opening a spreadsheet?\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2>What we would not do again\u003C\u002Fh2>\n\u003Cul>\n\u003Cli>Starting from a page builder and “adding booking later”\u003C\u002Fli>\n\u003Cli>Treating open play as a blog post with a GCash number\u003C\u002Fli>\n\u003Cli>Shipping player UI before club and staff workflows exist\u003C\u002Fli>\n\u003Cli>Assuming one location’s rules will survive a second site without a model\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2>Straight next step\u003C\u002Fh2>\n\u003Cp>If you want the story of how it started, read the \u003Ca href=\"\u002Fblog\u002Fbuilding-courtside-alley-from-spreadsheets-to-production\" rel=\"noopener noreferrer\">Courtside Alley case study\u003C\u002Fa> and the \u003Ca href=\"\u002Fwork\u002Fcourtside-alley\" rel=\"noopener noreferrer\">work page\u003C\u002Fa>. If you want to know whether \u003Cem>your\u003C\u002Fem> venue needs the same shape of system, \u003Ca href=\"\u002Fcontact\" rel=\"noopener noreferrer\">tell us how you book today\u003C\u002Fa> — spreadsheet, Facebook, or a tool that almost works. We will be direct about custom software versus tightening what you already have.\u003C\u002Fp>\n",{"prev":27,"next":44,"related":60},{"slug":28,"title":29,"description":30,"category":31,"readTime":9,"tags":32,"coverImage":35,"coverImageAlt":36,"heroImage":37,"heroImageAlt":36,"metaTitle":38,"metaDescription":39,"ogImage":40,"noindex":19,"published":20,"publishAt":41,"sortOrder":42,"updatedAt":41,"status":23,"path":43},"laravel-vs-wordpress-performance-philippines","Laravel vs WordPress performance on Philippine mobile","Which stack is faster on mid-range Android and mobile data? Plugin creep vs engineered Nuxt — and the fixes to try before you replatform for speed.","Performance",[31,33,34],"Laravel","WordPress","\u002Fimages\u002Fjournal\u002Flaravel-vs-wordpress-performance-philippines-cover.webp?v=20261013b","Code and terminal on a laptop used while reviewing site performance","\u002Fimages\u002Fjournal\u002Flaravel-vs-wordpress-performance-philippines-hero.webp?v=20261013b","Laravel vs WordPress Performance Philippines | PrimeCode","Laravel vs WordPress performance for Philippine mobile — LCP, plugin weight, and when caching beats a rewrite.","\u002Fimages\u002Fjournal\u002Flaravel-vs-wordpress-performance-philippines-og.webp?v=20261013b","2026-09-16T01:00:00.000Z",39,"\u002Fblog\u002Flaravel-vs-wordpress-performance-philippines",{"slug":45,"title":46,"description":47,"category":48,"readTime":9,"tags":49,"coverImage":51,"coverImageAlt":52,"heroImage":53,"heroImageAlt":52,"metaTitle":54,"metaDescription":55,"ogImage":56,"noindex":19,"published":20,"publishAt":57,"sortOrder":58,"updatedAt":57,"status":23,"path":59},"philippine-firms-ai-ready-not-in-production","Philippine firms look AI-ready. Production results are the real test","The 3 September Tribune piece put numbers on a gap we see in calls: initiatives and KPIs without connected data. How to tell a pilot from production.","Trends",[50,48,12],"AI","\u002Fimages\u002Fjournal\u002Fphilippine-firms-ai-ready-not-in-production-cover.webp?v=20261013b","Business leaders in a meeting reviewing AI initiative status","\u002Fimages\u002Fjournal\u002Fphilippine-firms-ai-ready-not-in-production-hero.webp?v=20261013b","PH Firms AI-Ready but Not in Production | PrimeCode","Philippine firms lead AI readiness surveys but stall before production — Tribune 3 Sep 2026, tool sprawl, and a one-workflow test.","\u002Fimages\u002Fjournal\u002Fphilippine-firms-ai-ready-not-in-production-og.webp?v=20261013b","2026-09-21T01:00:00.000Z",41,"\u002Fblog\u002Fphilippine-firms-ai-ready-not-in-production",[61,79,94],{"slug":62,"title":63,"description":64,"category":65,"readTime":66,"tags":67,"coverImage":70,"coverImageAlt":71,"heroImage":72,"heroImageAlt":71,"metaTitle":73,"metaDescription":74,"ogImage":75,"noindex":19,"published":20,"publishAt":76,"sortOrder":77,"updatedAt":76,"status":23,"path":78},"idempotency-keys-webhooks-side-effects","Idempotency keys: one webhook, one side effect","Retries are normal. Store the key with the result and enforce it with a unique constraint so a second delivery cannot create a second row.","Engineering",6,[68,69,33],"API","Webhooks","\u002Fimages\u002Fjournal\u002Fidempotency-keys-webhooks-side-effects-cover.webp?v=20261013b","Person writing on a printed form","\u002Fimages\u002Fjournal\u002Fidempotency-keys-webhooks-side-effects-hero.webp?v=20261013b","Idempotency Keys for Webhooks | PrimeCode","How an API stores an idempotency key so a retried webhook updates one record instead of creating a second side effect.","\u002Fimages\u002Fjournal\u002Fidempotency-keys-webhooks-side-effects-og.webp?v=20261013b","2026-10-19T01:00:00.000Z",53,"\u002Fblog\u002Fidempotency-keys-webhooks-side-effects",{"slug":80,"title":81,"description":82,"category":65,"readTime":66,"tags":83,"coverImage":85,"coverImageAlt":86,"heroImage":87,"heroImageAlt":86,"metaTitle":88,"metaDescription":89,"ogImage":90,"noindex":19,"published":20,"publishAt":91,"sortOrder":92,"updatedAt":91,"status":23,"path":93},"api-rate-limiting-before-traffic","Rate-limit the API before the expensive routes exist","Login, OTP, search, webhooks, and unbounded page size are the routes to limit first. OWASP API4:2023 is the control, not a new security product.",[68,84,33],"Security","\u002Fimages\u002Fjournal\u002Fapi-rate-limiting-before-traffic-cover.webp?v=20261013b","Padlock resting on a laptop keyboard","\u002Fimages\u002Fjournal\u002Fapi-rate-limiting-before-traffic-hero.webp?v=20261013b","Rate-Limit the API Before Traffic Grows | PrimeCode","Where a Laravel API needs rate limits first — login, OTP, search, and webhooks — and what OWASP API4:2023 actually asks for.","\u002Fimages\u002Fjournal\u002Fapi-rate-limiting-before-traffic-og.webp?v=20261013b","2026-10-16T01:00:00.000Z",52,"\u002Fblog\u002Fapi-rate-limiting-before-traffic",{"slug":95,"title":96,"description":97,"category":65,"readTime":66,"tags":98,"coverImage":101,"coverImageAlt":102,"heroImage":103,"heroImageAlt":102,"metaTitle":104,"metaDescription":105,"ogImage":106,"noindex":19,"published":20,"publishAt":107,"sortOrder":108,"updatedAt":107,"status":23,"path":109},"queues-work-outside-the-http-request","Queues: work that does not belong in the HTTP request","The request commits the booking or the order. Mail, PDFs, webhooks, and exports belong on a worker, and that worker must be safe to retry.",[33,99,100],"Queues","Architecture","\u002Fimages\u002Fjournal\u002Fqueues-work-outside-the-http-request-cover.webp?v=20261013b","Warehouse aisles of packed orders waiting to move","\u002Fimages\u002Fjournal\u002Fqueues-work-outside-the-http-request-hero.webp?v=20261013b","Queues: Work That Leaves the HTTP Request | PrimeCode","Which web-app tasks belong in a Laravel queue — mail, webhooks, exports — and why a timeout is the wrong place to notice.","\u002Fimages\u002Fjournal\u002Fqueues-work-outside-the-http-request-og.webp?v=20261013b","2026-10-14T01:00:00.000Z",51,"\u002Fblog\u002Fqueues-work-outside-the-http-request"]