Project Quotation/Estimate

[visibleman]

Evening All,

I've been asked by a friend to produce a quote/estimate* (i appreciate these are possibly two types of documents) for a web application project, however it's been 10+ years since i worked in an agency and i'm fairly rusty with documentation that gets sent out to clients (don't see it now other than internal documents).
So other than a brief outline of project, client requirements, application/project breakdown alongside time estimates (development + overall project deliverable/turn around), costs/fees and any information and costs related to future maintenance/support/stack hosting/staff training etc - what other information needs to be included?
Do i need to include any information regarding myself/usual company spiel? Or detailed scope of work, deliverables, technical specification on stack/platform/application etc?

Secondly, this application has to integrate with a third-party platform. And whilst they do offer an API, comms with the third-party (me to them; friend hasn't seen this) has revealed there are a fair number of concerns and potential issues - particularly that a lot of documentation is incomplete, out-of-date and generally you're on your own to probe endpoints and find out what's what.
Is this something that needs to officially be mentioned in the quote/estimate as a 'risk'/'challenge' or even feasibility of the project? Or to make clear there would need to be a preliminary research and discovery phase of the project because of this?

Thanks for any help

* Yes, i'm wondering too why i need to do this but it's a favor to a friend and keeps everyone sweet and happy.

 

[morbid42]

Quick and random 2 minute brain dump:

Third-party is going to add high risk and has potential to upset timeframes and feasibility. On one side its crucial its mentioned, on the other, if its too major it could stop the project. It will cause headaches when you cannot complete your goal due to other parties

Client will mainly be interested in high level "how much" and "how long", which can be backed up by other documentation pages

Requirements and technical specifications very important, not just happy path but also what happens if something goes wrong.

Stability of all systems, patch frequency etc need to be considered.

Disaster Recover needs considered.

Clear indication of what is out of scope, and impact of change requests.

Give options where possible - low, medium , high alternatives

Sometimes its best to ask - what do you want to see in the documentation eg detail level

Research phase is required

Cover security and data privacy

Cover key contacts

Seperate development, QA, UAT costs etc

 

[visibleman]

@morbid42 Much appreciate that, helped massively with a few bits i had completely overlooked/missed!