Example
How to finish an indie game demo without expanding it into the whole game
Ravi's problem is not a lack of effort. It is that Ship a demo with one true loop, a trailer that only shows what exists, and extras explicitly cut rather than half-present has outgrown scattered reminders, tabs, and memory. This fictional playbook shows a concrete Board, the Cards inside it, one consequential Room, and the line Ava does not cross.
This fictional example was created with AI assistance from a structured editorial brief and reviewed by the You.one Editorial Team for usefulness, distinctness, and product truth.
Ravi is an explicitly fictional portrait, not a customer or testimonial.
The Demo slice Board gives one mission a visible field; the Choose crafting’s fate Room keeps its evidence, conversation, state, and decision together.
Current Superboard provides the durable structure and explicit, bounded Ava paths described here; broader proactive or external work is not a current promise.
Ravi's pressure is ordinary—and still heavy
Ravi is a fictional 27-year-old solo developer preparing a festival demo in Waterloo, Ontario. Ravi’s festival page wants a build in three weeks. The vertical slice has a combat loop that works and a crafting system that does not. A Discord suggestion would add a second enemy type that would feel great and miss the date.
Ravi can build. Every extra system makes the page lie. The date does not care that the crafting UI is almost right.
A Trello from last year, a bug list in a text file, and Discord comments all look like the demo.
The festival requires a short trailer. Trailer shots currently assume the unbuilt crafting bench.
A demo is a true slice, not a smaller whole game
The mission is specific: Ship a demo with one true loop, a trailer that only shows what exists, and extras explicitly cut rather than half-present
The consequential choice is not something a board or an AI should quietly make: Whether to cut crafting entirely, ship combat-only with a “coming” card, or miss the festival and keep both systems
That distinction matters. Superboard can make the work, evidence, waiting, and decision visible. Ravi still owns the purpose, tradeoff, and final call.
Available today
Demo slice: one Board shape to adapt
A useful Board gives this mission one durable operating picture. Ravi does not have to convert life into project-management jargon or decide the perfect taxonomy first. Lists separate kinds of attention; Cards keep each meaningful item visible and movable.
The Cards are deliberately mixed. Some are tasks, some are decisions, some hold a person or promise, and some are reference points. Current Superboard supports that flexibility without flattening the mission into one long to-do list.
| List | What belongs here |
|---|---|
| Mission | Festival date and the one-loop rule |
| In slice | Systems that will actually ship |
| Cut | Good ideas that are not this build |
| Bugs | Blockers in the loop that remains |
| Waiting | Festival upload and trailer shots |
Available today
The Cards make the operating picture concrete
A Board becomes useful when the Card titles sound like the actual situation. These are not generic placeholders; they show what Ravi would need to see to run this mission without carrying every open loop in memory.
| Card | List | Job |
|---|---|---|
| One true loop by the date | Mission | Keep the festival date beside the rule that almost-systems do not ship |
| Choose crafting’s fate | In slice | Compare cut-crafting, coming-card, and miss-festival options |
| Combat loop playable | In slice | Name the system that already works |
| Crafting UI almost | Cut | Hold a tempting extra so it cannot linger as fake content |
| Trailer shot of the bench | Waiting | Stop the trailer from advertising an unbuilt bench |
| Blocker: dash into walls | Bugs | Keep a true loop bug above new enemy types |
Available today
Available today: Choose crafting’s fate becomes a Room
Opening the Card gives the visible item durable depth. Stage can hold Scope-cut brief: Place festival date, working combat, and cut / coming-card / miss-date options on one page. Chat keeps the request and response beside that artifact instead of in a detached thread. Pulse can show Waiting for Ravi to choose what the demo actually contains. Activity preserves the attributable Card record supported by the current product.
A useful Card Chat request would be: “Using only this Board, compare cutting crafting, shipping a coming card, and missing the festival. Do not change the build or choose for me.” When live AI is configured, current Ava can respond to an explicit Card mention using supported context and can make limited reversible product changes. She does not deeply reason over the whole Board by default, and she does not gain authority over the decision merely because the context is organized.
Ravi's call remains explicit: Ravi chooses the slice, fixes bugs, and owns the build and festival upload
| Surface | Job in this example |
|---|---|
| Stage | Scope-cut brief: Place festival date, working combat, and cut / coming-card / miss-date options on one page |
| Chat | Keep Ravi's request and Ava's attributed response with the work |
| Pulse | Waiting for Ravi to choose what the demo actually contains |
| Activity | Preserve attributed Card changes and the supported record around the request |
What to ask Ava—and what not to assume
These are useful requests to adapt, not claims that current Ava automatically surveys the whole Board, prepares every comparison, or follows up on her own. The relevant facts must be present in supported Board/Card context, and the human still checks the result.
Ravi owns the design, the cut, and the upload. Ava does not write code, ship a build, or submit to a festival.
The modest outcome is not that Ava lives Ravi's life. The modest outcome is a demo that tells the truth: combat is the loop, crafting is cut or later, and the trailer does not show a bench that is not there.
- Request idea: summarize in-slice systems, cuts, and bugs already on the Board
- Request idea: compare crafting-fate options using the festival date Ravi captured
- Request idea: help keep unbuilt trailer shots in Waiting
A leftover Trello plus a Discord thread may still be enough
A leftover Trello plus a Discord thread is enough when the slice is already true
It starts to break when a trailer, a crafting almost, and a festival date disagree about what exists
Superboard earns a place only when the responsibility needs a durable picture around the list: the reason, artifact, conversation, current state, decision, and history.
A starter recipe to adapt, not obey
Use the names that already make sense in Ravi's world. The recipe is successful when the Board reduces remembering and exposes the real decision—not when every Card is perfectly categorized.
| Step | Action |
|---|---|
| 1. Name the date and the loop | One true system |
| 2. Move almosts to Cut | Almost is not content |
| 3. List loop bugs only | New enemy types wait |
| 4. Audit trailer shots | Show what exists |
| 5. Decide the extra system | Open a Room before Discord expands the slice |
Direction
Direction, not a current promise
Later, Ava may help this Board notice when a trailer Card still depends on a Cut system, still leaving every ship call with Ravi.
The unified You.one and Superboard runtime, cross-product personalized Memory Spine, broad proactive coordination, realtime shared editing, and general external execution are not available today. Future actions would still require the applicable capability, connection, grant, and human authority.
What this realistic example does not claim
- Ravi is fictional and is not a customer, testimonial, research participant, or disguised real person.
- This is not a steam, festival, or sales claim.
- It does not show Ava coding, uploading a build, or contacting a festival.
- It is not a measured player result.