What Pippa Go Is (and Is Not)

"It's not a smaller chat app. It's the fastest honest path from a question in your head to a real answer."

One Job, Held Tightly

Picture the actual moment Pippa Go was built for. You're on a train, one bar of signal, and a question lands in your head that you want to ask Pippa right now — with a photo of the thing you're looking at attached. You open a phone app, type, attach, and send. That single flow — capture a question, carry its image, get a real answer, and never lose the question if the link dies — is the whole job. Everything in this quest exists to protect it.

Most "mobile client" projects fail this moment. They treat the send button as the save button, so a dropped connection eats your input. Pippa Go inverts that: the send is a transport, and the save already happened, locally, a moment earlier.

Three Sharp Negations

The fastest way to see a thing's shape is to name what it deliberately is not:

Not a miniature full chat. Branching, councils, artifacts, administration, full transcript replay — those live in the canonical backend. Cramming them onto a phone would make a worse version of something that already exists.
Not a second Pippa. There is exactly one Pippa: her identity, memory, judgment, and model routing all live in the backend. Pippa Go grows no parallel soul, no second model router, no rival source of truth.
Not an offline chatbot. It works beautifully offline for capture, but a real answer still requires reaching the real Pippa. Offline never means "make something up locally."

What's Left Is the Product

Remove those three and the actual product stands clear: a resilient, question-first projection. It owns durable device-local capture, retry state, an offline outbox, macro cache, and connection settings. It presents a focused Q/A surface. Behind it, every conversation is canonical in the backend from birth, with normal context replay and branching semantics — the phone is simply the most reachable window onto it.

Hold that word: projection. A projection shows you the thing without being the thing. A shadow on the wall moves when the object moves; it never decides to move on its own. Pippa Go is that shadow — faithful, reachable, and never mistaken for the body that casts it.

Code

One Pippa Go turn, as the phone holds it (shape sketch)·json

{
  "device_turn_id": "d7f3c1a2-9b4e-4c8a-bf10-2e5a6d0c1234",
  "question": "Which of these two lenses is the 35mm?",
  "attachments": [
    { "local_id": "img-01", "media_type": "image/jpeg", "bytes_ref": "idb:blob:img-01" }
  ],
  "sync_status": "pending",   // pending -> sending -> answered | failed
  "created_at_device": "2026-07-16T09:14:02Z"
}

// The question and its image are ONE aggregate, saved on-device first.
// sync_status is a flag the network flips. The network never owns the data.

Exercise

Recall a mobile app that lost your input — a form that cleared on a bad connection, a message that vanished mid-send, a photo upload that failed and took your caption with it. Write down exactly what got lost, then ask: was the 'save' tied to the network, or to the device? Nearly every lost-input story is a save that was really a send in disguise.

Hint

If closing the app or losing signal erased your work, the app never committed it locally first. The fix is almost always 'save on device, then transport' — the exact inversion Pippa Go is built on.