35 years of theatre, online in 4 days
I designed and built a Next.js + Claude Code platform for one of Mumbai's most important theatre companies — 113+ plays, decades of multilingual archive — in four days. It keeps building itself: drop a folder, Claude produces a researched, multilingual, SEO-optimised production page, and Vercel deploys.
ROLE
Designer · Developer · Content Strategist
TIMELINE
4 days
TEAM
Solo + Claude Code
SCOPE
Web, Data Architecture, Agentic AI
Ideas Unlimited Productions is a Mumbai theatre company founded in 1990 by Manoj Shah — director, actor, producer. 35 years of continuous work, 113+ plays across Gujarati, Hindi, English, and Marathi, performed in 2,300+ shows across 35+ cities. Notable work: Mohan No Masalo (featuring Pratik Gandhi before Scam 1992), Mareez (the longest-running Gujarati play, at Prithvi since 2004), and Bombay Flower(an NCPA co-production). I've been associated with the company since I was sixteen.
What I built is not a website — it's an agentic publishing system. Eight Claude skill files encode design rules, data schema, research methodology, content standards, and validation. Every new production is a folder drop away from a fully researched, translated, SEO-optimised page. The website is a consequence; the system is the product.
Scope, stated plainly: I built the system — the relational schema, the skill files, the pipeline, and the surfaces. A parallel content team of two to three researches plays, translates regional-language source material, and surfaces press clippings. AI does synthesis; humans hold the cultural memory.
Three platforms tried and abandoned. All broke on the same problem.
A theatre company's data is inherently relational. A person is not simply “an actor.” They are the actor in play A, the assistant director in play B, the writer in play C — many-to-many, with the role as an attribute on the join. Every no-code CMS broke against that exact shape.
WordPress
Too technical to maintain
Every design change required a developer. Fine at 10–12 productions; not at 113.
Webflow
Can't express relational data
A person can act in one play and direct another. Webflow can't attach a role to a person per production.
Framer
Even more limited CMS
One tag per person. The relational problem got worse, not better.
Next.js + Claude Code
No CMS ceiling
Code has no CMS constraints. The relational model designed correctly from the start; Claude compressed weeks into 4 days.
The real brief, self-imposed: build a permanent digital home for one of India's most significant theatre institutions — and design it so it can keep building itself with minimal human effort.
The constraint was never design skill. It was data architecture.
Three platforms didn't fail because they were ugly. They failed on data shape. The temptation is to read this as a tooling problem — pick a better CMS — but a better CMS doesn't fix it, because the limitation is the data model itself. Webflow can attach a tag to a person; it cannot attach a role to a person per production. A theatre archive is many-to-many with attributes on the join, and no-code platforms can't express that.
In code, it's trivial: a production has a cast_crew array where each entry carries both a person_id and a role. The entire structural limitation that killed three platforms was solved in a single JSON schema decision on day one. That was the unlock — not a design tool or a framework, but getting the relational model right before writing any UI. Remove the CMS ceiling, and the constraint moves to where it should be: design and content quality.
Eight skill files. Zero coding per new production.
The system is the product — eight skill files, written before any UI.
The 4-day build was possible because the agentic workflow was designed before a line of code. Eight Claude skill files encode everything — design rules, data schema, research methodology, content standards, animation, code conventions, and deployment validation.
Claude
orchestrator
EIGHT SKILL FILES · ONE ORCHESTRATOR
Skill file
Encodes
design-system.md
Typography, colour, spacing, component patterns.
data-layer.md
JSON schema — productions, people, press, festivals.
production-pages.md
Full workflow for adding a new production.
person-pages.md
Research + profile generation for cast & crew.
blog-pages.md
Editorial guidelines, SEO structure, longform standards.
animations.md
Framer Motion patterns — consistent motion behaviour.
code-standards.md
TypeScript standards, component structure, naming.
singleton-pages.md
Rules for Home, About, Contact, Festivals pages.
The pipeline — folder in, production page out.
Drop a folder of raw materials — synopsis in any language, photos, YouTube links, cast list, newspaper clippings — and Claude reads the skills, translates, researches the production externally, finds backlink-worthy SEO sources, adds new people with researched profiles, writes a rich synopsis and a longform blog post, builds the JSON entry, validates relational integrity, and pushes. The pipeline doesn't replace work — it makes work tractable that would otherwise be impossible for one person on a 113-production archive.
✔ Reading production-pages skill✔ Translating Gujarati synopsis — Hindi, English✔ Researching cast — 8 sources cross-checked✔ Sourcing photos — public databases✔ Writing productions.json entry✔ Writing blog post — bombay-flower.mdx✔ Validating relational integrity — 0 errors$ git commit -m "add: Bombay Flower" && git push✔ Vercel deploying...✔ Live — ideasunlimited.productions/productions/bombay-flower# elapsed: 4m 12sThe surfaces — every production composes against four page types.
The site should feel like entering a theatre, not a corporate brochure: dark editorial, a Manoj Shah portrait, ambient sound, an upcoming-shows ticker, “35 Years of Fearless Theatre” stated up front.
The people directory is the relational model that broke every CMS: each profile lists every production with the exact role — actor here, assistant director there, narrator in a third — and even pulls in external work (Pratik Gandhi's Scam 1992, films, TV) into the same profile. The archive doesn't end at the theatre door.
Architecture to deployment. One person, four days.
The 4 days were execution because the architecture was decided first. Day one was the data model and the skill files — the part that actually determined whether the project would work. The UI was a view layer over decisions already made.
DAY 1 · DATA + SKILL FILES
Next.js initialised. Data architecture from first principles — productions / people / press / festivals JSON. Each cast/crew entry carries a person_id and a role — the relational model no-code couldn't express. 8 Claude skill files written before any UI.
DAYS 2–3 · PRODUCTIONS + PEOPLE
15 productions with full detail pages — researched synopsis, cast/crew linked to people profiles, gallery, press, ambient music. People directory populated. Blog seeded. The Manoj Shah essay built as the deepest page on the site.
DAY 4 · SINGLETONS + LAUNCH
Home, About, Contact. Legacy-numbers count-up, performed-at marquee, newsletter. Responsive validation. GitHub push → Vercel auto-deploy → live.
Five decisions that made four days possible:
Decision
What it reveals about how Janam thinks
Designed in code, not in Figma.
At this build speed, the design tool and the build tool have to be the same. Static comps would have slowed the loop without improving the outcome.
Relational JSON over a CMS.
CMS limitations are data-model limitations. Hand-rolled JSON with a typed schema is faster, more correct, and removes the ceiling that killed three earlier attempts.
8 skill files written before any UI.
The system is the product, not the website. Encoding the rules into Claude skills made the agentic pipeline reproducible.
Dark editorial, 5/7 split, ambient music per production.
Theatre lives in the dark and sounds like sound. The site should feel like entering a theatre — Playfair for cultural seriousness, an ambient track for sense memory.
Janam-reviews-then-pushes commit gate.
AI accelerates implementation, not architecture. Claude writes files; I review the diff and push. The override moment lives at the commit, not the prompt.
Why the system, not the site.Designing the system was harder than building the site — and it's the part that keeps paying off, because the 98 remaining productions are now a folder drop each, not a rebuild. The skill files turn one schema decision into a reproducible pipeline: design-system.md holds the aesthetic, data-layer.md enforces relational integrity, production-pages.md runs research-to-page.
A system that keeps building itself. One designer-developer, four days.
Cost transparency. About $200/month to run and publish (Claude Code Max) plus ~$20/year for the domain. Next.js + TypeScript and Vercel (hobby) are free. Reproducible by anyone with the same toolchain.
Scope boundary — where the AI stops and humans start. I built the system: the schema, the skill files, the pipeline, the surfaces. The content track is human work by design — a small team researches plays, translates Gujarati / Hindi / Marathi source material, and surfaces press from physical files and old hard drives. The platform problem was solvable in four days; the 35-year content problem is ongoing.
The website is a consequence. The system is the product. This is the pipeline I'd hand to any regional theatre, music school, or gallery sitting on three decades of unscanned material — AI in service of art, not commerce.