Ask HN: What should I include in a tech discovery phase?

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.]

I've been in this kind of situation, but with less expertise on the client's side.<p>My (successful) angle of attack was to review the documentation provided as a kind of "requirements dump" rather than a "this is how it should work" definition. I then applied my own knowledge and experience to generate a document that said "these are the features you asked for, here's how to provide them in a user-centric manner."<p>As your client apparently has the IA and graphics person on their side, you may be more constrained. I'd still put forward some ideas, in a conversational manner. Two reasons for this. First, maybe I have a better idea than them. Second, it shows that I'm more than a code monkey (or a bunch of code monkeys calling itself a consultancy).<p>The work product should include some idea of how you're going to attack the problem, and a sense of how long it'll take (fixed bids are for the devil), and prioritization based on client requirements and prerequisites that those requirements may have.

I should add that the client here is a non technical person. He basically has a decent idea, and some money to get it going.