Shibuya

The intersection of the product team in the AI era.

Shibuya is named after the world famous crossing in Tokyo. This platform is meant to be the crossing point of the entire product team: the one place where everyone's work meets, now that the way we build products is changing.

---

Why Shibuya

In the AI era, a working prototype is the new spec. Instead of writing a document and waiting for engineering, a product person can generate a clickable prototype in an afternoon. That shift is powerful, but most product teams are not set up for it: prototypes end up scattered across laptops, chat threads, and one off deploy links, and the "old school" way of working (write a spec, hand it off, wait) quietly persists.

Shibuya helps a team make that transition:

1. It hides the engineering. Publishing a prototype normally means creating a Git repository, pushing code, wiring a build, and deploying to a cloud platform with some form of versioning. Not everyone on a product team does that. Shibuya does all of it for you: you drop a folder, and it comes back as a live, versioned, shareable link.

2. It turns comments into shared context. Each prototype is really a new feature idea. The comment thread on it gathers everything the team learns (from a business review, a tech discussion, a user test) in one place, so anyone can open a prototype and immediately understand what is going on with it.

3. It generates the KPIs of an AI era product team. When prototypes are the unit of work, the metrics change. Shibuya is built around the numbers that actually matter now: how many prototypes reach production, how long they take from first version to production, how many are stopped, and how the team's throughput trends over time.

The result: less "where is the latest link?", a shared source of truth for in flight ideas, and a team that ships and reacts to real, clickable work.

---

What you get

• Drop a folder, get a live prototype. A whole project folder is pushed to a private repository, built, and deployed to a shareable URL automatically. A single .html file or a link to something already hosted works too.
• Versioning and rollback. Upload a new version whenever a prototype evolves; roll back instantly if a newer version is not better.
• Team and personal spaces. Every prototype is organized by team and by owner, so people find the latest thinking fast.
• Comment threads on every prototype for shared context.
• A team dashboard with the product KPIs (see below).
• Access control. Everyone can see all prototypes; only a prototype's members can change it. Non members can request access.

---

How your team uses it

1. Sign in with a company email and set a name and photo.
2. Add a prototype (+ Add a project): drop a folder or an .html file, or paste a URL. Assign it to a team, add collaborators, describe it.
3. Watch it go live. For a folder, Shibuya shows the deploy steps and then activates a shareable link.
4. Share and discuss. Send the link; capture meeting takeaways and decisions in the comments.
5. Iterate. Download the current version, edit, upload a new one; roll back if needed; move the status from in progress to in production (or stopped).
6. Browse the team space to see everything in flight and the KPIs.

---

Set it up for your company

A complete walkthrough to stand up Shibuya for your own product team. You do not need to be an engineer to follow it, but you will touch a few technical dashboards. Plan about 30 minutes.

What you will need

• A GitHub account (to host the code).
• A Vercel account (free tier is fine) to run the app.
• A Supabase account (free tier is fine) for the database, sign in, and file storage.
• Optional, only for the automatic folder deploy feature: a GitHub organization and a Cloudflare account. You can skip this and still use .html files and pasted URLs.

Step 1. Get the code

Fork this repository into your own GitHub account or organization, then clone your fork:

git clone https://github.com/<your-account>/shibuya.git
cd shibuya
npm install

Step 2. Create your Supabase project

1. At supabase.com, create a new project. Pick a region close to your team and save the database password somewhere safe.
2. Open the SQL Editor, paste the entire contents of supabase/schema.sql, and run it. This is idempotent and creates the tables, the security rules (Row Level Security), the storage buckets for prototypes and avatars, and three placeholder teams.
3. Go to Authentication -> Sign In / Providers -> Email and:
   • turn off "Confirm email" (people sign in with a password, no confirmation email),
   • turn on "Allow new users to sign up".
4. (Optional) To restrict sign ups to your company domain at the database level, open supabase/schema.sql, find the commented enforce_email_domain block near the bottom, set your domain, uncomment it, and run that block. You can also gate it in the app (Step 3).
5. Go to Settings -> API and copy two values: the Project URL and the publishable key (it starts with sb_publishable_).

Step 3. Configure environment variables

Create your local env file from the template:

cp .env.example .env.local

Fill in the two Supabase values, and optionally your allowed email domains:

NEXT_PUBLIC_SUPABASE_URL=https://<your-project>.supabase.co
NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY=sb_publishable_xxx
# Optional: comma separated. Leave empty to allow any email.
NEXT_PUBLIC_ALLOWED_EMAIL_DOMAINS=yourcompany.com

Tip: with no Supabase values set, Shibuya runs in a zero config demo mode using built in sample data, so you can preview it before committing to a backend (npm run dev, then browse). As soon as the two variables are set, demo mode turns off and the app talks to your project.

Step 4. Run it locally

npm run dev

Open http://localhost:3000, click Sign in, and create the first account with your company email. You now have a working Shibuya on your own backend.

Step 5. (Optional) Turn on automatic folder deploys

This is what lets a non technical teammate drop a whole project folder and get a live URL with no manual steps. Without it, members can still add prototypes as a single .html file or as a link to something already hosted.

It uses a shared GitHub App (to create and push repositories on your behalf) plus Cloudflare Pages (to build and host). Full detail lives in docs/deploy-pipeline.md; the short version:

1. Create a GitHub App owned by your organization with Administration (create repositories) and Contents (read and write) permissions. Note its App ID, generate a private key (a PEM file), then install the app on your organization and note the Installation ID.
2. In Cloudflare, note your Account ID and create an API token with the "Cloudflare Pages: Edit" permission. One time, install the Cloudflare "Workers and Pages" GitHub App on your organization with access to all repositories.
3. Add these server side variables to .env.local (and later to Vercel):

GITHUB_ORG=your-org
GITHUB_APP_ID=...
GITHUB_APP_INSTALLATION_ID=...
GITHUB_APP_PRIVATE_KEY=...   # the PEM, with newlines written as \n on one line
CLOUDFLARE_ACCOUNT_ID=...
CLOUDFLARE_API_TOKEN=...

Step 6. Deploy to Vercel

1. In vercel.com, import your fork as a new project (framework is detected automatically).
2. In the project Settings -> Environment Variables, add every variable from your .env.local for the Production environment.
3. Deploy. You can also deploy from the terminal:

vercel deploy --prod

Your team now has a live URL.

Step 7. Bring your team in

1. Rename the teams. The seed ships with placeholders (Team 1, Team 2, Team 3). Rename them to your real teams either by editing the seed in supabase/schema.sql, or in the app when adding a prototype (the team selector can create a new team).
2. Invite teammates. Share the URL. Each person clicks Sign in, chooses "Create an account", and signs up with their company email (restricted to your domains if you set that up).
3. Ship the first prototype so the team sees what "good" looks like.

That is it. From here the team just drops folders and shares links.

---

The new product KPIs

When prototypes are the unit of work, the questions change from "is the spec done?" to "is the idea working?". The team space is built to answer that. Today it surfaces the live counts (total prototypes, in progress, in production, stopped), and the underlying data model (per prototype status, created and updated dates, version history) is designed to track the metrics that define an AI era product team:

• Prototype to production rate: the share of prototypes that reach production.
• Time to production: how long a prototype takes from its first version to going live.
• Failure rate: the share of prototypes that get stopped, which is healthy signal, not waste.
• Throughput: how many prototypes the team starts and ships over time.

These make the team's real velocity and learning visible, rather than hiding it inside documents.

---

Make it yours

Shibuya is white label and has no third party UI kit. Everything is a small, self authored design system:

• Colors live in one file, src/design-system/tokens.css. Change the palette constants and the light and dark neutral ramps and the whole app follows. The default palette is #780000, #c1121f, #fdf0d5, #003049, #669bbc.
• Type scale is src/design-system/typography.css; fonts are set in app/layout.tsx via next/font. Body text is Ubuntu; the wordmark uses Space Grotesk (components/Wordmark.tsx).
• Product name appears in the wordmark, the sign in screens, and page metadata.
• Avatars are deterministic initials discs (lib/avatar.ts), no image assets.

---

Tech

Next.js (App Router) with TypeScript and Tailwind v4, a Supabase backend (Postgres, Auth, Storage, Row Level Security), and an optional GitHub App plus Cloudflare Pages pipeline for the drop a folder deploy flow. Nothing to self host on the server side; Supabase is managed and the app runs on Vercel.

Key paths: app/ (routes), components/ (app UI), src/app/components/ (design system primitives), src/design-system/ (tokens and type), lib/ (Supabase clients, GitHub and Cloudflare helpers, demo data), data/ (server queries and types), supabase/schema.sql (backend), docs/deploy-pipeline.md (deploy internals).