Question-First, Not Miniature Chat

"Scope is a feature. The thing you refuse to build is what makes the thing you build good."

The Temptation to Shrink

When someone says "we need a mobile version," the default reflex is to take the desktop app and shrink it: same sidebar, same conversation list, same everything, at 40% the size. It feels safe — you're not "leaving features out." But a shrunk desktop app is a worse desktop app. On a phone, on a train, one-handed, you don't want a sidebar. You want to ask a question.

Pippa Go makes the opposite bet: pick the one interaction that matters most on a phone and make it excellent, rather than making every interaction available and mediocre. The primary unit is a question and its answer. That constraint isn't a smaller feature set — it's a sharper product.

What Question-First Actually Buys You

Choosing a single primary unit pays off everywhere downstream:

The capture flow can be bulletproof. One input type (a question plus optional images) is small enough to save atomically and retry cleanly. A whole editable conversation tree is not.
The offline story is simple. "Hold this one question until the link returns" is a promise you can actually keep. "Sync an arbitrary branching conversation offline" is a research project.
The screen stays honest. A focused surface has room to show sync status, retry buttons, and pending state clearly — the things that build trust when the network is flaky.

The full conversation still exists — it's canonical in the backend, browsable and branchable there. Pippa Go just declines to be the place you do that. It's the place you ask.

Focus Is Not Feature-Poverty

A camera app that only takes photos isn't "missing" video editing; it's being a camera. Pippa Go being question-first isn't a stripped chat client apologizing for what it lacks. It's a tool that knows its job. Every time you're tempted to add "just a small conversation list" or "just inline branching," ask whether it serves the one job — a question, answered, never lost — or whether it's the shrink-the-desktop reflex sneaking back in.

Code

The whole surface, as a type·typescript

// Question-first means the core state is small and legible.
type PippaGoTurn = {
  deviceTurnId: string;
  question: string;
  attachments: StagedImage[];
  syncStatus: "pending" | "sending" | "answered" | "failed";
  answer?: string; // populated ONLY by a successful canonical call
};

// Notice what is NOT here: no conversation tree, no branch pointers,
// no council state, no artifact store. Those belong to the backend.
// The phone holds a queue of these, and that is the entire model.

Exercise

Take an app you use on both desktop and phone. List the top 3 things you actually do on the phone version. Now imagine a client that does ONLY those 3, beautifully, and refuses the rest. What gets better — speed, reliability, one-handed use? What would you genuinely miss? Most of the 'missing' features turn out to be desktop reflexes you never use on mobile.

Hint

The features you'd truly miss reveal the real primary units. The ones you listed only because 'the desktop has them' are exactly what a focused client should decline.