keoyyo85/FoundPhone-Studio

FoundPhone-Studio is worth trying if you have a story idea that fits the "found phone" format and want a ready-made phone interface instead of designing one yourself. It is a browser-based authoring framework, not a runtime AI narrative engine; the AI works during production, turning your premise into structured story data.

The problem

You want a playable story where the reader opens a lost phone and pieces things together through chat logs, notes, photos and lock screens. Building that means implementing a believable phone shell first: a lock screen, home grid, notifications, folders, App Store and dozens of app pages. FoundPhone-Studio starts you from a working 49-app shell and a story file, so your effort goes into writing characters, messages and branches rather than rebuilding the interface.

What's different

The design deliberately separates the phone UI from story data. The default story lives in stories/template/story.json, and the runtime only reads the generated JSON, with no model called online while a player reads. That has a practical consequence: a reader needs no account, API key or connection after the first cached load, and the author can regenerate or edit story data without touching UI code.

The README pushes a low-code workflow: fork or use the template, open it in an AI coding tool such as Codex, WorkBuddy or Claude Code, and give the AI the story premise plus instructions to read AGENTS.md and edit the story JSON. The interface supports interactive choices, password clues, simulated calls, notifications, multiple endings, and links between apps. That link structure is what makes the format work for mystery writing, but it also fences you into phone-shaped storytelling. This is not a general visual-novel engine, and some of the 49 entries are registered shells whose pages are not equally complete.

Who should try it

A good fit is a writer or small team with a contained mystery or character drama who wants a polished phone surface and is willing to iterate through an AI assistant plus the validation scripts. Someone comfortable hand-editing JSON can also use the story schema and AI guide directly. A poor fit is anyone expecting to type prose into a web form and hit publish, or anyone who needs every one of the 49 apps to behave like a full replica of the real service; the README says those pages are not real service clients and coverage differs.

Requirements and limitations

Local work needs Node.js 22 and the standard npm ci, validation, test, preview and build commands, and you must not open the HTML directly from disk. Publishing is a build plus a static host deploy; the project documents GitHub Pages and notes that Actions and Pages must be enabled in your own repository. Browser saves are per-player and per-browser, so clearing site data can erase progress, and the README advises bumping the story revision after large narrative changes so old saves do not mask the edit. Natural-language input is converted by an AI at authoring time; if your AI tool cannot access files, you save and place its output yourself.

Ongoing work is mostly data maintenance: validate the story, walk through chats, passwords, calls and every ending in preview, then rebuild. The framework does not execute embedded HTML or JavaScript in story scripts, so narrative content is data-driven rather than free-form code.

HotRepo's take

HotRepo recorded 114 total stars and a #12 position on its NEW-REPOSITORY board for TypeScript on 2026-10-26, one day after the repository's 2026-10-25 creation date. That is a single dated snapshot of a new-project board, not a daily-growth series, so persistence cannot yet be judged. Before investing, check whether the app pages you need are complete in the online demo and read the story schema to see how much branch authoring you will be doing yourself.