Mega_Aleksandar's avatar

Writing business proposals and contracts

Hello everyone,

Apologies in advance if I am out of place here with this kind of question.

If you know a better place to ask it, let me know, but you guys are all I've got.

As I am diving deeper into the business world, coding is not enough, understanding systems is not enough. How do I actually get a client, hook them to sign the contract, make the proposal and contract complement each other, not being the same document all over again?

I am trying to bridge a commercial gap here, because I am alone in this and I tend to either explain everything in a proposal or too little. Other times I get bitten by couple of broad words that are too wide and clients tend to catch them or interpret them differently than intended and then I have to work more or develop a feature that sometimes completely changes the output etc.

Thank you for your time and best regards

1 like
7 replies
vincent15000's avatar

To get clients, the approach depends on the country where you work, marketing can need to respect some rules / laws specific to the country.

You say that some words can be interpreted differently by the clients, that's why it's important to sign specifications where you describe all what will be developed with concrete examples. You also need to speak with the client before signing the specifications and inform him / her about all what is important.

Effectively there can be situations where you have to work more, sometimes to work less. More you are precise in the specifications, less there will be possible interpretation.

1 like
Mega_Aleksandar's avatar

The real issue here is time - how/when do I stop myself from doing unpaid research/discovery for a project that I might not even get? I mean, in order to provide a proposal, I need to know that I can actually do it - depending on client requirements.

Technically, if I need more than 1.5h to prove to myself that I can do it, it is a sign I probably should not do it right? ;)

Outlining the problem (the executive summary), timeline, pricing - all of that I am good and can be confident, but it is the outline of the solution that sometimes gives a nail into my own coffin - scope creeps because of my own words, not clients - that is what I want to figure out.

Thank you for your reply @vincent15000

1 like
vincent15000's avatar

How I do myself :

  • I have a meeting with the client to hear his / her project during about 30 minutes to 1 hour

  • I send an estimate to the client for writing the specifications

  • I work on the specifications (paid)

  • if the client wants to develop the application, I send him another estimate for the development

  • if the client doesn't want to develop the application, he has just to pay for the specifications

Then you can (if you want) deduct the estimate from the total price.

The total time for me to write the work on the proposal and write the specifications don't have to be over the estimate to write the specifications. Sure this estimate has to be evaluated according to the estimated work for the proposal (from the initial meeting).

Mega_Aleksandar's avatar

Ah, that is a nice one, getting paid for specification (the discovery phase) - that way, even if you do not land the project, you got something for your time. That is a perfect one I have not even considered.

Yeah, if the client picks you for the project, you can decide if you want to give them a "discount" since they already paid for the proposal and specification.

Nice, thank you so much for this, this is going into my SOP :)

1 like
Snapey's avatar

you have to invest some time to create sales, whether that is writing proposals, attending calls, research, etc etc.

So some of what you earn has to be put to one-side to reinvest to win more business in the future.

This is all down to experience unfortunately, both in sizing of the project and knowing which projects to chase.

Early in my career, someone said something to me that has stuck and that I remind myself over and over "Don't assume they can't afford it". Its far better to let them tell you your price is too high than to make the assumption and cut your price before you even ask.

Also when pricing remember, they are not paying you to do the job, they are paying you so that they don't have to do the job.

Regarding contracts and specifications, you don't have to repeat it, just have the contract reference the specification(s) (versioned).

2 likes
Mega_Aleksandar's avatar

Hi @snapey ,

Thank you for those words of wisdom. Those two lines - "Do not assume they cannot afford it" and "They are not paying you to do the job, they are paying you so that they do not have to do the job" - pure revelations, shifting my mindset when it comes to thinking of bureaucracy.

Yes, the experience part is what I am struggling a bit, but that will come with time (and actual work).

Do you write detailed specifications or just a high overview of the minimal functionalities? Do you do them in word/pdf or some other helper software?

Thank you so much for this.

1 like
vincent15000's avatar

According to me, it depends on the contract type.

In France we have 2 main types of contracts for web application development :

  • a standard contract where the functionalities to be developed are all written, useful when the client knows exactly what he needs

  • an agile contract where the functionalities to be developed can evolve during the project, useful when the client has an idea, but doesn't really know the real functionalities he needs in his application

Please or to participate in this conversation.