> The philosophy behind Documentation-Driven Development is a simple: **from the perspective of a user, if a feature is not documented, then it doesn't exist, and if a feature is documented incorrectly, then it's broken.**  [^fn1] [^fn1]: [Documentation Driven Development](https://gist.github.com/zsup/9434452) by zsup on GitHub The above definition is kind of aimed at existing product teams, but I think this concept could be useful at the idea inception stage by an entrepreneurial developer. Documentation-Driven Development could be a form of [[Lean methodology]] for a software product idea for which documentation is front and centre of the product itself. API-first products are good candidates for this. So the entreprenuerial developer, armed with a new idea, would do something like the following: 1. Create marketing website describing the product 2. Write the docs and make them prominent on the marketing site 3. Promote the site to get feedback on the API contract and dcoumented usage scenarios 4. Write first line of production code 🙂 --- ## References - [An introduction to spec-driven API development](https://blog.apideck.com/spec-driven-development-part-1) by Tim Haselaars - [Readme Driven Development](https://tom.preston-werner.com/2010/08/23/readme-driven-development.html) by Tom Preston-Warner