JOY PLANET

JOY PLANET turns interests, mood, free time, budget and trusted relationships into safe, realistic plans, then helps people save, schedule, share and enjoy them from Japan to a localized world.

Comment

Inspiration

JOY PLANET began as a question I have carried for more than ten years: why do people with interests, relationships, and precious free time still struggle to turn that potential into genuinely enjoyable moments?

Our calendars record obligations. Search engines return lists. Social feeds compete for attention. Event sites optimize discovery, and matching products optimize meeting people. None of them begins with the whole human context: What do I enjoy? How do I feel today? How much time and money do I have? What is realistic in this weather and location? Would this be better alone, with family, or with trusted friends?

I imagined a JOY PLANET: a service where small possibilities orbit each person's real life, and where the right one can become an actual plan. The purpose is not to maximize scrolling or introduce strangers. It is to help people notice, plan, and experience more of the time that makes life feel rich. When that happens, relationships can deepen naturally around shared experiences.

OpenAI Build Week and Codex finally made it possible to turn that decade-long concept into a working product rather than another document.

What it does

JOY PLANET is a mobile-first planning companion. A lightweight onboarding flow learns only enough context to be useful: area, who the user often spends time with, interests, available time, budget, mobility, notifications, and a safe visibility default. Users can skip and change everything later.

The app then presents explainable JOY suggestions. A user can mark interest, save a suggestion without committing, turn it into a dated plan, choose who may see that plan, export it to a calendar, and leave a short reflection afterward. Saved items and plans are intentionally separate. Visibility is also separate from the plan itself, so it can be changed later without rewriting the experience.

Privacy is part of the product, not a settings afterthought. Every plan starts as Only me. Family, friends, friends-of-friends, groups, nearby users, and public visibility are modeled as distinct scopes; broader scopes are gated and never promoted as defaults. The connections screen can show authorized plans and nearby plan spots, but the map loads only after an explicit action and does not turn the product into live people tracking.

The current prototype also includes Google sign-in and Calendar integration paths, feedback collection for pre-service learning, PWA support, post-plan reflections, responsive interaction states, and a source-aware event pipeline. The Japan dataset currently contains 149 events from 22 source systems across 29 regional shards, with official-media review gates and attribution. Crawling is kept outside the product runtime so future localized editions can switch by country and region without increasing app complexity.

How we built it

The client is a dependency-light HTML/CSS/ES Modules SPA with explicit boundaries for configuration, data, services, state, and UI. Python scripts build static production and test bundles, collect and normalize public event facts, audit sources, generate regional catalogs, package releases, and verify deployments. An optional same-origin PHP endpoint stores pre-service feedback append-only outside the document root.

The domain model separates JoySuggestion, SavedItem, JoyPlan, PlanVisibilitySetting, Review, CalendarExportState, and ShareState. That separation is what makes the interaction honest: curiosity is not commitment, saving is not scheduling, and scheduling is not consent to share.

The access-controlled test environment runs on CORESERVER with HTTPS, Basic authentication, noindex, SPA fallback, security headers, a versioned service worker, backup-first FTPS deployment, release manifests, and rollback artifacts. The repository contains more than 24 dependency-free contract and release checks covering the major user flows, security boundaries, content policy, and deployment behavior.

How Codex and GPT-5.6 helped

Codex became the persistent engineering partner for the project. It read the original specification, reviewed the UI before changing it, maintained product decisions and unresolved questions, implemented features, operated browser checks, tested releases, and prepared the deployment. The collaboration remained traceable through specifications, decision records, change logs, contract tests, and TODO_SPEC_CONFIRM items.

GPT-5.6 reasoning was focused where it mattered most: converting a broad human vision into precise product semantics, designing safe visibility and map behavior, separating calendar consent from authentication, reviewing media rights, resolving conflicting requirements, and deciding what must fail closed before a test release. Lower-risk work such as static builds, data normalization, and release verification was pushed into deterministic scripts. That division kept token and infrastructure cost low while reserving deeper reasoning for decisions that affect trust.

Codex accelerated months of coordination into a runnable prototype, but it did not replace judgment. The strongest result was a disciplined loop: intent, implementation, browser evidence, tests, documentation, and a reversible release.

Challenges we faced

The hardest challenge was protecting the original idea while making it concrete. A recommendation product can easily drift into an ad feed. A connections feature can look like dating. A map can become invasive. Calendar integration can request too much access. Event aggregation can ignore source rights. Fast AI-assisted development can also create a polished demo whose internal concepts do not agree.

We addressed those risks structurally: experiences remain the subject of every screen; default visibility is private; broader visibility is gated; precise location is not continuously collected; calendar authorization happens only at export time; personal/blog photos are excluded; crawler limits and caches reduce source load; and state concepts are separated and tested.

Deployment added another challenge. The target is conventional shared hosting rather than a managed JavaScript platform. We built a static release path with Apache SPA fallback, security headers, environment injection, backup-first deployment, authenticated verification, and rollback instead of weakening the product to fit the host.

Accomplishments that we're proud of

  • A coherent end-to-end flow from discovery to saving, planning, private sharing, calendar export, and reflection.
  • Privacy and safety rules expressed in data, UI, tests, and deployment gates rather than policy text alone.
  • A real nationwide prototype feed with 149 events, 22 source systems, 29 regional shards, and 125 official-media references under review-aware display rules.
  • An access-controlled HTTPS test service with PWA update handling, feedback intake, automated release verification, and rollback artifacts.
  • A codebase whose decisions remain understandable even after very rapid iteration.

What we learned

AI speed is most valuable when paired with explicit product principles. Codex could implement quickly, but the ten-year vision supplied the compass: JOY is the goal, planning is the mechanism, and connection is a possible result. We also learned that privacy defaults shape the emotional character of a product. “Who can see this plan?” creates a very different service from “Who can I meet?”

Finally, localization cannot be a translation pass. A global JOY PLANET must adapt its event sources, language, cultural rhythms, seasons, calendars, mobility assumptions, safety norms, and privacy rules. The country/region shard architecture is the first practical step toward that future.

What's next

We will begin with a small Japanese pre-service cohort and learn directly from how people save, plan, abandon, reschedule, and reflect. Next come production authentication, durable consented data, moderation, stronger recommendations, calendar synchronization, and broader official-source coverage.

From there, JOY PLANET will localize country by country. The ambition is global: a shared product foundation that helps people everywhere turn local culture, free time, and trusted relationships into more meaningful experiences, while each edition remains native to its community.

Ten years of imagining this service led to one week of unusually concentrated building. This prototype is not the end of that story. It is the first time the JOY PLANET is truly in motion.

Built With

Share this project:

Updates