Lead a project brief with the insight, not the feature list

When asked to summarise a project for an outside reader, the useful structure is problem, then the single non-obvious insight that makes the approach different, then how it works, then honest status. Feature lists read as interchangeable; the insight is what a reader can actually retell to someone else. Two things that earn trust in a brief: name the specific failure mode of the incumbent tools rather than gesturing at them, and state plainly what is not built yet — an unqualified summary of a partially built system reads as finished and creates expectations the code cannot meet. Ask who the reader is before reshaping into a pitch or README, since the framing changes far more than the content does.