I guess if I had five days to produce a "tech discovery" document like you describe for a non-technical audience, it would be breaking down the tasks and providing detailed estimates. Software estimation is very hard; I'm no good at it, but when I've been close to the mark, it's been because I broke down the tasks into 1- or 2-day chunks.<p>If I were to work on it, I would start by reading their wireframes and building a mental model -- at a high level, how the app must work. Then, if applicable, I would search for libraries which will save lots of time; the presence of an important library may pull me strongly towards certain languages, platforms, or architectures.<p>Once I had decided on platform and architecture (not in stone), I would start writing out the details of the tech into a document. I would put in all the technical stuff I thought I might need at first, because it's more for me to build my model right now than to give to the client. I'd spend two or three days on this, focusing on identifying the risks. If the risk is huge or easy to research, I would research it at this time and see how to mitigate it. I would also not be shy about calling them up if I think I might have a misunderstanding, as a few minutes on the phone might save hours or days.<p>Anyway, the last step is to distill the document for the audience. At this point I should have all the information to produce a document that includes an estimate, risk analysis and implementation plan.<p>[Edit: I probably sound obnoxious by using "I would" everywhere rather than "you should". (Sorry!) But I have no actual experience doing this sort of thing, so I feel dishonest giving prescriptive advice.]