You need to pick up pen and paper and create diagrams and flowcharts, if you can't chart it out, it probably doesn't make any sense. If you get confused, grab your senior developer and explain to him one on one what you are trying to achieve. It doesn't matter that you are a non-tech founder, your working with developers, you need to adapt your processes to how developers think and work.
Bullet-points work great and provide easy references to things like intended file-names, and also provide an easy way to break down a conditional statement.
You need to look into psuedo-code, because in a way, that's what you're looking to provide. Otherwise, you might as well just give the developers and the client a one on one and get out of the way. You have to be providing something that makes the developers life easier then handling all the interaction themselves and that something provided has to be something other than just time.
We need to understand the purpose of the system, how it works into the overall program, how it should look, how it should feel, intended program flow, intended results, we need to know a lot of everything not a little of everything.
You also need to be almost constantly available to answer a quick question. There are just too many issues that may crop up while working on a program, case in point I was working on a project earlier today which featured two different types of an overall master type inside a record of a database. I made a (highly educated) assumption of which type I was using based on context but I could have been wrong. Knowing which sub-type to use was something that wasn't available to me immediately with the information I had on hand and didn't appear to be an issue during our requirements meeting, it only popped up when I was re-checking program flow, specifically error catching. These little things can happen all the time, and the only real way to beat them is communication.