The Crumb Lineage

"You don't invent a resilient capture flow twice. You prove it once, then give it a dedicated home."

Born From a Proven Pattern

Pippa Go didn't start as a blank sketch. It started as a pattern that had already earned its keep somewhere else. In Waystone — the travel client, brainstormed mid-trip on a phone with unreliable signal — there's a small composer called the Crumb: you drop a quick breadcrumb of the moment (a note, a photo, a place) and it commits on-device first, syncing to the backend when it can. It was built because the one thing you cannot do while traveling is lose the moment you just tried to capture.

That Crumb flow — capture a small unit locally, show its sync state, let the network catch up — turned out to be the exact shape a mobile Q/A client needs. Pippa Go is the Crumb concept, lifted out of travel and rebuilt around a single dedicated unit: the question.

Lineage Is a Design Method, Not Nostalgia

Reusing a proven pattern is not laziness; it's the opposite of guessing. The Crumb had already survived the hard case — a spotty connection while its author actually needed it. Carrying that lineage forward means Pippa Go inherits battle-tested answers to questions a fresh design would only discover in production:

What commits first, device or network? Device. (The Crumb learned this the hard way.)
What does the user see while it syncs? A visible, honest status. (Not a spinner that lies.)
What happens when the app dies mid-sync? The captured unit survives and resumes. (Because it was durable before the network was ever touched.)

Same Bones, Different Body

Waystone's Crumb captures a travel breadcrumb; Pippa Go's composer captures a question with images. Different content, identical skeleton: local-first commit, visible sync status, idempotent catch-up. When you find a hard-won pattern in one corner of a system, the highest-leverage move is often not to invent something new next door — it's to recognize the same skeleton and give it the dedicated home it deserves. That recognition is what turned a travel feature into its own product.

Code

One skeleton, two bodies·typescript

// Waystone's Crumb and Pippa Go's question share a shape.
interface LocalFirstCapture<TPayload> {
  localId: string;
  payload: TPayload;              // a breadcrumb, or a question+images
  syncStatus: "pending" | "sending" | "synced" | "failed";
  commitLocally(): Promise<void>; // ALWAYS runs before any network call
  trySync(): Promise<void>;       // idempotent; safe to call again
}

// Waystone: LocalFirstCapture<Breadcrumb>
// Pippa Go: LocalFirstCapture<QuestionWithImages>
// The skeleton is the lineage. The payload is the only new part.

Exercise

Look at a system you've built or used. Find one place where a resilient pattern already exists — a draft autosave, a retry queue, an offline cache. Now find a second place that needs the same resilience but reinvents it (or lacks it). Sketch what it would mean to lift the first skeleton and reuse it. That recognition — same bones, new payload — is exactly how Pippa Go was born.

Hint

The reusable part is almost never the content; it's the lifecycle — commit-locally, show-status, idempotent-sync. If two features share that lifecycle, they can share the skeleton.