How Little Plains built a knowledge layer and AI product on top of years of archived work

Summary

A detailed case study by three founders at Little Plains on building a searchable knowledge centre from years of archived internal material and then shipping an AI-powered product on top of it. The essay covers why naive "chat with your files" approaches fail, how to structure knowledge in layers (fast vs. deep), why splitting retrieval paths by user intent outperforms one catch-all query, how to keep models from improvising by using deterministic structured rendering, and why designing and testing in code instead of Figma unlocked interaction patterns that mockups could not reveal. Read the full essay via the original post.

Key Claims

• "Chat with your files" interfaces fail because useful knowledge requires editorial judgment: deciding what matters, what is public, what deserves research, and who approves changes. Skipping this yields a chatbot that confabulates about its own history.
• Splitting the archive into "fast knowledge" (small versioned curated set of what the system needs now) and "deep knowledge" (full corpus for research) is more effective than treating every question as a retrieval problem. Fast knowledge at Little Plains contains four maintained documents covering who they are, how they work, sales questions, and agent rules.
• Rendering structured project facts deterministically from approved CMS fields (title, slug, problem, approach, outcome, deliverables) prevents models from improvising and is faster than asking a model to describe each project on demand.
• Splitting the interface by intent—Explore (browse via text or image), Ask (structured Q&A), Voice (conversational)—and giving each its own retrieval path and latency budget is more effective than one catch-all modal.
• Evaluation should freeze test scenarios, run each several times, have a stronger model judge all outputs against the actual UI contract, and farm a failure list rather than optimise for a score; the constraint is interface behaviour, not metric.
• Reducing median latency from 6.1 to 3.6 seconds cost roughly 1.9 times as much (moving from Standard to Fast processing tier), but was worth paying because API latency was the bulk of the wait.
• Model-generated interpretation will outrank a team's own writing unless weighted against it; authored language and editorial judgment must be weighted to win.
• Prototyping in code (using Claude Code or Codex to build working variations in parallel) is faster than designing in Figma and surfaces interaction decisions (state, timing, motion, focus) that static mockups cannot show.
• The single most valuable part of the knowledge layer project was writing the fast layer by hand before touching embeddings or models, not the technical infrastructure.

Quotes

• "Architecture built for a real need stays honest. Architecture drawn first goes looking for a product to justify it."
• "A model proposes line-level changes, and a human accepts, rejects, or rewrites. Publication creates immutable versions. Nothing said in a meeting quietly becomes public truth."
• "Once you experience this model of creating [from idea to clickable prototype in minutes], it's hard to go back."
• "Most side projects won't ship, and that's fine, most shouldn't. But you won't find the version of your product that surprises you if every hour has to be justified in advance."