Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

phpMick's avatar

Writing a Software Proposal

Has anyone got any tips? List of headings would be great.

Never had to do one before.

Mick

0 likes
6 replies
shez1983's avatar

quick excerpt of what the software is to do to give your users an idea..

functionality requirements

UML diagrams etc if necessary (Class diagram perhaps to show interactions and properties/methods)

some UI diagrams to show the flow

DB diagrams if appropriate

Zenith2012's avatar

I used to work with a friend developing PHP applications for clients, he did the design work and I did the programming. He would have a meeting with the client to figure out what problem they were trying to solve, then together we would put a project specification together similar to the following:

Client Proposal

  • Outline in a paragraph what the software needs to achieve, this is the top level overview of what the client has asked for.
  • Outline individual features, e.g. user registration, what happens during this process. If the site sells things, how are the products listed, how are they added to the basket, how is the order completed etc.
  • Continue to break the system down into sections/features and explain each feature.

For us, the client did not care HOW something worked from a programming perspective but they did care how it would work from the visitors point of view.

Once all that was done we usually had a extra section outline what other features we felt the site would benefit from. E.g. whilst writing the initial proposal often you'll think "Hey, if it can do that, then it would be nice if it also did this". Often, this extra functionality isn't something they client has specifically asked for, so we listed it at the end of the proposal as an added value thing and usually a way to charge more money.

My colleague would come up with mock designs of the UI interface and key features, sometimes as HTML template that you can click on and it pretends to add items to a basket etc so they can see the flow of the application.

Finally, we would come up with a Development Proposal. This is what outlined HOW we would write the application, what hosting requirements would it have, where would it be hosted and what environment was it running on. What models/methods/relationships would we have etc (even though I was the only developer on 99% of the projects this still helped us both understand what was going on under the hood).

A lot of our clients stating that the extra things we put into our proposals (such as they "hey, how it did this" features) were above an beyond what others had put forward. We had some projects that nearly doubled in size (and cost) because of the extra features we proposed that the client hadn't even considered. The proposal essentially said "What you've asked for this is... it will cost this £... but it can also do this, this and this for an exta £...."

Hope that helps, best of luck to you.

douglasakula's avatar

@phpmick "Software Proposal" is generic and can mean a lot. To add to what @shez1983 has said the document you could be referring to could be a Software Requirements Specification document - and can get very detailed depending with objectives you want to achieve.

https://krazytech.com/projects/sample-software-requirements-specificationsrs-report-airline-database

If "Software Requirements Specification document " looks like the document you have in mind then you could further your search along those lines. There is plenty of resources on this.

D9705996's avatar

This is a really open ended question as it depends entirely on the type of work, one off, continuous delivery, etc. However the documentation I usually fall back to is a statement of works. It's a non te technical document on what you are going deliver, when and most importantly how YOU get paid and is fairly universal

https://www.smartsheet.com/how-write-statement-work-any-industry

You often have to back up a SoW with a technical design document TDS. The SoW is normally fir the guy paying your bill and TDS is the engineers reference.

I use this at work for very large deals and works really well.

Please or to participate in this conversation.