An essential attribute of a good software is that it gets the job done. This means that it can do the required functions in an acceptable way to the user(s). As a result, we could say that, if you know:
1 - What needs to be done (system objectives, constraints, functions, use cases, business rules, etc.)
2 - Which user can do what (security, authorization, etc.)?
3 - When each function can be performed (schedules, workflows, etc.)?
4 - How to implement the above in an acceptable way (architecture, friendly GUI, data modeling, framework adoption, etc.)?
5 - Who will do the work?
and if your user is happy about your prototyping, presentations, understanding of buiness, then chances are you are good to go and can produce an first cut plan for the code development part.
I recommend that you separate analysis, design and coding.
I also recommend that you have a stable data model and good detail about the majority of the system functions. It is not very harmful if you discover that you are missing a function (assuming that it is local to your system domain and won't require external APIs), and it is OK if you are missing some business rules when you start but it hearts more to discover that your data model is wrong or missing significant pieces because this usually fires back on the GUI work not only on the data layer.
Depending on the methodology you use, you could find estimates on how much effort you dedicate for requirements and design. I am very tempted to say that front work would eventually consume at least 25% of the total project work but any estimate I will come up with will be wrong because it really depends on too many factors.
Agile and XP methods have things quite different than what I suggest. In fact even on the database side, there is Agile Modeling approaches that you may want to consider. The advice above are not based on those techniques.