A worked case study using PLAYON Indoor Playground at Downtown East, Singapore — covering market research, content modelling, site construction, and equipment selection. All Markdown configuration samples are copy-paste ready.

1. Why an indoor playground makes a useful case study

Singapore has over seventy indoor playgrounds in operation. Most look alike: ball pits, slides, trampolines, climbing nets, aimed squarely at the under-sixes. Their websites look alike too — a hero image, a paragraph of adjectives, an opening-hours table, a booking button.

The category is worth studying because it contains almost every problem a local physical business hits when it goes digital:

• High SKU count. A venue running twenty-odd attractions needs a page per attraction to capture search traffic at all.
• Online must map to offline. If the website’s categories do not match the venue’s physical zones, visitors get lost on arrival.
• Layered buyers. Walk-ins, birthday parties, school groups and corporate bookings are four different sales conversations.
• Uneven demand by time slot. Weekends sell out; weekday daytime sits empty. Site structure determines whether that empty capacity is addressable at all.
• Real regulatory exposure. Licensing, fire safety, planning approval — precisely the areas where AI should stay quiet.

This article uses PLAYON, an indoor playground inside the Downtown East complex in Pasir Ris. It targets an older age band than most competitors and runs 26 distinct experiences on the floor.

The value of the case is not that the business is unusual. It is that the problems it exposes are common.

2. Step one: market research with AI

Most people research with AI by opening a chat window, typing “how is the indoor playground market in Singapore,” and receiving a correct and useless overview. The problem is not the tool. It is that the research was never broken into answerable questions.

2.1 Research should resolve a decision, not a topic

Useful research output is a table that supports a decision, not an essay. Before starting, establish which decision this round of research serves — pricing, site selection, an equipment purchase, or which keywords the site should target. Different decisions require entirely different questions.

For a venue like this one, research typically needs to answer four clusters:

2.2 Encoding research as a skill

If research happens once, asking in a chat window is enough. In practice it recurs — once a season, once per new site, once every time a competitor cuts prices. At that point the process belongs in a skill.

A skill in Claude Code is a Markdown file containing knowledge or a workflow. Skills load on demand: invoked directly with a slash command, or picked up automatically when Claude matches the task to the skill’s description. Unlike CLAUDE.md, which loads in full every session, only a skill’s description occupies context until it is actually used.

That makes skills the right home for procedures that run occasionally — market research, page audits, pre-launch checks.

.claude/skills/venue-research/SKILL.md

---
name: venue-research
description: Research the local family entertainment venue market.
  Use for pricing decisions, site selection, competitor monitoring,
  and keyword planning.
---

# Venue Market Research

## Establish before starting

Ask, do not assume:
1. Which decision does this research support?
   (pricing / site selection / equipment / keywords)
2. Geographic scope? (island-wide / one district / mall catchment)
3. Which age band is the benchmark?
4. Any known direct competitors already identified?

If the decision is unclear, stop and ask. Research done
"to understand the market" never gets used.

## Research sequence

### 1. Competitor inventory
List every comparable venue in scope first, then filter. Do not
start with the three "main competitors" — the one that gets
missed is often the closest on price.

Record for each:
- Location, mall, floor level
- Entry price, session length, per-head or per-slot
- Age positioning (as stated on site, and as judged from photos)
- Attraction count and type mix
- Party package entry price and capacity
- Catering included, outside food permitted

### 2. Price band distribution
Plot every competitor's unit price (currency per hour) in one
column. Identify clusters and gaps. A gap is not automatically
an opportunity — it may be a band others have tested and
abandoned. Flag it; do not conclude.

### 3. Audience and time slots
Obtainable from public sources: opening hours structure,
weekday/weekend price split, holiday schedules, whether a
group booking page exists at all.
Anything not obtainable (actual footfall, repeat rate) gets
marked "requires site visit or internal data". Do not infer it.

### 4. Keywords
List target keywords with search intent classified:
- Venue discovery ("indoor playground singapore")
- Occasion ("birthday party venue for kids")
- Price comparison ("indoor playground price")
- Group ("school excursion venue")
For each, note whether competitors have a matching page and
whether any has a dedicated page. Terms with no dedicated
competitor page are structural opportunities.

## Output format

One competitor comparison table, one keyword opportunity table.

Every figure carries a source link.
Fields that cannot be sourced are written "not published".
Never estimate them.
Close with three actionable recommendations, each tied to a
specific page or action.

## Do not

- Do not treat marketing copy as fact. Write "the site states".
- Do not infer floor area, capacity or equipment counts from photos.
- Do not infer anything about whether a competitor holds a licence.

Those last three constraints are the most important part of the file.

The most common way local-business research goes wrong is treating a competitor’s own marketing copy as data. “Largest in Singapore” and “over 50 attractions” are claims, not measurements. A comparison table contaminated with a rival’s promotional language leads directly to mispriced tickets and wrong equipment choices.

A research tool earns its value by refusing to fill blanks, not by always having an answer.

3. Step two: translating physical space into information architecture

Between research and writing code sits a step that is routinely skipped: defining the content model.

3.1 Volume is itself the problem

PLAYON runs 26 distinct experiences — bowling lanes, archery, VR, racing simulators, billiards, an infrared target range, a basketball arcade, motion-sensing stations.

In physical space, volume is a selling point. On a website, volume is a navigation problem.

Twenty-six items in a flat list is unusable. Mobile visitors — and most family-attraction research happens on mobile — read the first four and leave. Putting all 26 on a single page produces a wall of text that ranks for nothing in particular, because the page has no clear subject. Search engines resolve a page to one primary topic, and a page with 26 topics has none.

3.2 A three-tier structure

Tier 1   /experiences              overview
Tier 2   zone groupings            Sports / VR / Shooting / Motion
Tier 3   /experiences/{slug}       one page per experience

This is standard practice in e-commerce — catalogue, category, product page. It is uncommon on attraction sites, which tend to collapse everything into a single “What’s Inside” page.

The direct consequence of giving each experience its own URL: a page dedicated solely to bowling can target bowling queries. A page dedicated solely to archery can target archery queries. A combined page targets neither.

3.3 Zones must correspond to real areas

The more important point is that the zones should not be a website invention. They should map to physical areas of the floor.

A visitor who reads about the Sports zone online and then walks into the venue encounters the same grouping, in the same order, under the same names. The caged basketball court, the bowling lanes and the billiards tables sit together physically, and they sit together in the navigation.

This produces two effects:

• Lower cognitive load on arrival. A family that browsed the site has already built a mental map. They do not re-learn the layout at the door.
• The site stays useful during the visit. Visitors pull out phones mid-session to decide what to do next. A site organised around the physical floor answers that question; a site organised around marketing categories does not.

The principle generalises beyond playgrounds. Any venue with a complex physical layout — a food hall, a multi-tenant retail space, a museum — benefits from a site structure that mirrors the space rather than inventing a parallel taxonomy.

3.4 Specificity as a design constraint

PLAYON’s physical design leans on real equipment rather than screen simulation, and that turns out to matter for the website.

The bowling area holds two real lanes, real balls, real pins, with lighter balls available for smaller players. The archery lane uses real bows firing real arrows fitted with soft cylindrical rubber tips, at digital targets that score by hit zone. The basketball arcade runs five real hoops in a row, each with a screen tracking a live score against a 1,000-point clearance target, with the house record displayed at the top.

Every one of those descriptions contains a number or a concrete noun: two lanes, real pins, rubber tips, five hoops, 1,000 points.

Specific detail outperforms generic description on two fronts. It gives search engines something to match against long-tail queries, and it gives readers a reason to believe the page. “An exciting bowling experience the whole family will love” is unverifiable and appears on several hundred other sites. “Two real lanes, lighter balls available” is a claim a parent can act on.

The constraint runs the other way too. A venue built entirely from generic arcade cabinets has nothing specific to write about, and its pages will read exactly like every competitor’s. Physical design decisions determine what the copywriter has to work with.

3.5 Age gradient and conversion split

Two fields in the content model look trivial and decide conversion.

The first is the age floor. Most Singapore indoor playgrounds serve under-sixes. Interest drops off around eight, which creates a documented gap for older children. PLAYON sits in that gap without being exclusive to it: the infrared target range fires light beams and nothing physical, open from age four; archery from eight; higher-intensity VR for older children and adults.

That spread is a commercial decision — a family with a four-year-old and an eleven-year-old can visit together, which a single-age venue cannot capture. But it imposes a requirement on the site: every experience page must state its age floor, because the first question a mixed-age parent asks is whether everyone can take part. Age information buried in an FAQ fails that test.

The second is conversion routing. PLAYON separates walk-in admission (a pricing page) from group business (/parties, which further divides into birthday parties, school trips and corporate events).

The split reflects genuinely different buyers. A parent booking two hours on a Saturday is making a small, fast decision. A teacher booking an excursion for forty students, or an HR manager booking a team event, is making a considered decision requiring approval, and needs entirely different information: capacity, duration, supervision ratios, catering arrangements, invoicing.

Collapsing both into one “Book Now” page serves the fast buyer and loses the slow one. The group buyer abandons a page that cannot answer the questions their approver will ask.

This is also where weekday capacity gets sold. An indoor playground’s Monday-to-Thursday daytime hours are structurally quiet for family traffic. School and corporate bookings are what fill them. A site with dedicated group pages can capture that demand; a site without one waits for the phone to ring.

Site structure determines which revenue is findable.

4. Step three: building the site with Claude Code

The structure above is easy to describe and tedious to implement. Twenty-six experience pages, each with consistent fields, consistent metadata rules and consistent internal linking, is exactly the kind of repetitive build where hand-coding introduces drift: page nine gains a field page fourteen is missing, and nobody notices until an audit six months later.

Claude Code, Anthropic’s terminal-based coding tool, handles this category well — provided the project conventions are written down first.

4.1 CLAUDE.md: conventions loaded every session

Claude Code reads a file named CLAUDE.md at session start and keeps its contents in context for every request in that session. Official guidance is to keep it under 200 lines; longer files consume context and instruction adherence drops. Reference material needed only occasionally belongs in skills, which load on demand.

For a venue site, CLAUDE.md holds the structural rules — the things that must hold on every page, so they need not be restated in every prompt.

CLAUDE.md

Writing this down matters because it survives the session. Conventions stated once in a chat window are gone when the window closes; conventions in CLAUDE.md load every time.

Note the “never invent equipment counts” rule. On a venue site, plausible-sounding specifics are worse than blanks. A page claiming four racing rigs when the floor has six is a correction waiting to happen, and a visitor who spots it stops trusting the rest of the site.

4.2 Skills: on-demand workflows

.claude/skills/new-experience/SKILL.md

That closing checklist matters more than it looks. Character counts are a common failure point: estimated counts drift, and a title truncated in search results loses its closing brand token. Instructing the tool to count rather than estimate removes the problem entirely.

4.3 An audit skill that reports rather than fixes

A site this size warrants a third file — one that sweeps all 26 pages and reports violations instead of silently repairing them.

.claude/skills/audit-pages/SKILL.md

The “do not fix” instruction is deliberate. An audit that silently rewrites gives no signal about where the process is failing. An audit that reports lets the team see that, say, description length fails on nineteen of twenty-six pages — which is a template problem, not twenty-six individual mistakes.

5. Step four: using AI to expand the equipment floor

The second application has nothing to do with the website.

An indoor playground is not a fixed asset. Equipment ages, dwell time on a given station falls as regulars exhaust it, and the competitive set moves. A venue running 26 attractions is continuously evaluating replacements and additions — and most of that evaluation currently happens by walking trade shows and reading supplier PDFs.

The decision is harder than it looks, because a new machine must clear several constraints simultaneously: floor area, ceiling height, power, the venue’s age floor, throughput per hour, supervision load, and whether it duplicates something already on the floor.

That is a structured evaluation problem, which means it can be written down as one.

.claude/skills/evaluate-equipment/SKILL.md

Two things here are worth noting for anyone adapting the pattern.

The first is the repeated instruction not to estimate. Supplier specifications routinely omit the play envelope, state throughput under unrealistic assumptions, or give a footprint that excludes the queue. A tool that fills those gaps with plausible numbers produces a confident, wrong comparison table. A tool that marks them “not stated” produces a list of questions for the supplier — which is the actually useful output.

The second is the regulatory section, which explicitly refuses to conclude. Licensing in Singapore turns on specifics — what a machine physically does, not what category it is marketed under — and the answer comes from the relevant authority, not from a model reasoning over a spec sheet. The skill’s job is to flag that a candidate touches a licensing question, and stop there.

6. The boundary: what AI should and should not do

That boundary generalises.

The useful division of labour is to automate the structured, repetitive, rule-checkable work — field completeness, character counts, duplicate play patterns, missing spec fields — and route the judgement calls to people. A workflow that respects the line is faster. One that does not is faster at producing things that have to be redone.

That last row deserves emphasis. Every specific figure in this article — two lanes, five hoops, 26 attractions, the age floors — is a fact verifiable on site. AI can organise them into structure. It cannot go and look.

The most common failure in practice is not AI writing bad copy. It is a venue’s own copy being wrong about its own equipment, then getting replicated verbatim into the website, the press release, and every derivative piece after that. One error describing real bowling lanes as a simulation travels into a media write-up and gets syndicated three more times.

Verify the physical reality first, then automate. Reverse the order and automation only replicates the error faster.

7. Summary

PLAYON is not an unusual business. It is an indoor playground in a suburban mall complex competing for weekend family spend.

What makes it instructive is the degree to which its site structure and its floor plan were allowed to inform one another: zones that exist in both, experience pages that exist because the experiences are physically distinct, a pricing page that is short because the pricing model is simple, and group pages that exist because group revenue is a separate business.

The tooling follows from the structure, not the other way round. Once the content model is explicit — every experience has an age floor, a player count, a zone, a body of 120 to 200 words — the build becomes mechanical, and mechanical work is what these tools are for. Teams that skip the model and prompt their way through 26 pages individually end up with 26 pages that drift.

The alternative — a website commissioned after the fit-out is complete, from a vendor who has never walked the floor — produces sites that describe venues accurately and sell them poorly.