Explaining money to a child without lying through simplification

While building SouSou, my kids' financial education app, the hardest constraint wasn't technical. It was figuring out how to explain a financial concept to a 6-year-old without simplifying it to the point of making it wrong.

The temptation of false simplicity

"Saving means putting money aside" is true, but incomplete in a way that ends up creating a misunderstanding later: it says nothing about why you save, or about the fact that money sitting idle doesn't work the same way as money that's invested. A 6-year-old doesn't need to understand compound interest, but they can understand that a euro set aside today can, over time, become a bit more than a euro. That's a difference in level of detail, not a difference in truth.

The criterion I try to hold to

The rule I set for myself while writing SouSou's educational content: every explanation must stay true if it's made more complex later, never just more precise. "Needs are what you truly need, wants are what you'd like to have" stays true at age 6 as much as at 40; it gets refined (the line between the two gets subtler as you grow), but it never gets contradicted. By contrast, an explanation that will need to be "corrected" later isn't a simplification, it's an error being postponed.

What that changes in the app's design

This constraint has concrete consequences for SouSou: no mechanic that suggests money appears without effort (a concern I've already raised about gamification in general, see the note on why I build my kids' education apps), and vocabulary chosen to stay valid even as a child's understanding gets more refined. Daily missions ask concrete questions rather than stating abstract definitions, because a child retains a principle applied to a recognizable situation better than a general rule learned by rote.

A lesson that goes beyond money

The same discipline applies to any technical explanation given to someone less experienced: the question is never "how far can I simplify", it's "what can I omit without what remains becoming false". Explaining counterparty risk to a developer with no finance background, as I do on Finance for Engineers, poses exactly the same constraint, with a different audience.