I've been asked to give a quote to extend a piece of software i'm currently giving away for free for use by a company. They tell me they are using it in-house at the moment in conjunction with some "post processing" steps, which they would like to incorporate into the application proper.

What should I keep in mind when writing quotes for custom or bespoke software requests? How can I ensure all my bases are covered? What aspects of a custom software quote are things that are often overlooked?


I am unclear on what you mean by "the typical engineering approach" but would caution strongly against proceeding without some written agreement on what work is to be done and for what compensation. I highly recommend creating a functional spec rather than a "programming tasks" spec, as per Joel Spolsky's functional spec article series (http://www.joelonsoftware.com/articles/fog0000000036.html).

Basically the spec will help you and the client agree on what the final behavior of the program will be. The functional spec should contain enough detail that you can verify the final program against it. This way there can be no doubt that you've delivered what was agreed and payment is now due.

Be very careful about "Can you just add one more feature / tweak this feature slightly" requests. Usually they start with a minor tweak here or there and if you do them for free, you start getting more frequent, less reasonable requests until you are doing whole projects at no extra charge. My recommendation is to build a few hours of extra consulting / programming time into the initial quote for tweaks to the finished product, and once this time is exceeded do a new spec and quote for changes. Thus the client gets some reasonable tweaking on the final product but doesn't start believing that all future changes should be done for the initial quoted amount.

  • 1
    "Be very careful about "Can you just add one more feature / tweak this feature slightly" requests. Usually they start with a minor tweak here or there and if you do them for free, you start getting more frequent, less reasonable requests until you are doing whole projects at no extra charge." This happens EVERY SINGLE FRIGGIN TIME. This is why it is best to avoid fixed-price projects unless the scope is small, well understood and open to little interpretation.
    – maple_shaft
    Jun 16 '11 at 13:17
  • 1
    Fixed bid projects fail for a number of reasons. Primarily: it is impossible to gather all the requirements at the start of a project, and whatever requirements you do gather are guaranteed to change. "Can you add just one more feature" isn't just something to "be very careful about", it's the way software development works. Jun 16 '11 at 17:08
  • @Rein - If it's impossible to gather all the requirements then I submit the project is doomed from the beginning. The client must have some idea of what they want and the programmer's task is to interpret the business requirement and design program functionality that will meet it. Sure there will always be room for improvement but if there is not consensus on what will be delivered, expect a lot of frustration on both sides.
    – Bork Blatt
    Jun 17 '11 at 13:03
  • not at all, or every project ever would be doomed. It's just a reality of software development. There are ways to manage it. Pretending that it is otherwise is just folly, and is the real reason that so many projects do fail to deliver reasonably on time and in budget. Jun 17 '11 at 17:09

For a small project the best quote is a fixed price however you need to be careful and make sure that you have a full understanding of the scope and time you will invest in the project.

Identify all scope in a Work Breakdown Structure and make sure that it is signed off on by the company. This is an agreement that YOU understand what you will deliver, and THEY understand what they will receive.

Determine time estimates, pad for the unknown, and bill a percentage more than the going contractor rate to reflect your risk.

  • 1
    In terms of a WBS do you think it is sensible to disclose estimated man hours and therefore hourly rate, or simply identify the tasks, dependencies, completion date and total cost?
    – Scott
    Jun 16 '11 at 11:40
  • Hmmm... thats a good question. I would probably do the latter, a WBS which lays out tasks and dependencies, completion date and a price. This isn't your project plan, its just your WBS and quote, but if they are insistent on seeing your detailed project plan then they will be able to figure out your hourly rate, which I WOULD NOT want to disclose on a fixed price project. They shouldn't need to know HOW you came to the price you did. If they don't like your price they can shop around or negotiate with you on the final price. Bottom line is, that I would try not to disclose my detailed PP.
    – maple_shaft
    Jun 16 '11 at 12:09
  • 1
    Yes, do not disclose too many details about how your bid was constructed. I've had potential customers turn around and take that to less qualified people who then underbid me.
    – Bob Murphy
    Jun 16 '11 at 18:15
  • 1
    @Bob, Thats straight up poor business ethics right there, and yet another reason who you don't want to disclose your project plan to your client.
    – maple_shaft
    Jun 16 '11 at 18:32
  • 1
    @maple_shaft: No kidding. :-) For about the last decade, when a potential customer has wanted details beyond a simple bid, I've offered to provide them at my "design-only rate", which is several times my normal rate. So far, everybody who's heard that has changed their minds and decided the bid was sufficient.
    – Bob Murphy
    Jun 16 '11 at 19:28

Having done bespoke software development for about 20 years, here's what I'd do in your shoes:

  1. If I hadn't done so, determine an agreed-upon list of the deliverable software changes - individual features, bug fixes, etc.
  2. Estimate how long I think each of those tasks will take, individually. You get a much better estimate that way than looking at the project as a whole. In fact, the more you can break it down, the better your estimate will be. But don't give those individual task estimates to the customer.
  3. Add those up, and double that to account for unknowns. Call that doubled amount X.

Then I'd send a simple email or letter saying:

  • Here's the list of changes we agreed on. I estimate this will take at most a total of X hours.
  • I work on a time-and-materials basis, with time billed at $Y per hour.
  • If - due to unforeseen factors - the project reaches 90% of X and it's not complete, I will stop work and contact you to discuss whether to proceed.

I've found this approach is a win for both sides. The customer gets the fixed-price advantage of a "cap" on their financial exposure, and you aren't stuck doing an endless amount of work for a fixed price.

This is also very easy to embody in a contract. In the US, you can typically use a very simple two-page contract that refers to a "scope-of-work" addendum. Then that addendum is a simple, single page that lists the changes and an estimate of Y hours maximum.

Other than your hourly rate, the only objection most reasonable people can raise would be that X is too long. The counter to that is to explain that you don't actually expect the project to take that long, but you wanted to account for unknowns and still give them a cap you're comfortable that you won't exceed. Under no circumstances should you tell them your original, unmodified estimate; it could become a bargaining point (e.g. something the customer can argue about) that would not be to your advantage.

As other people have mentioned, a common problem with fixed-price projects is the customer can "one more little thing" you into the poorhouse. A nice thing about this approach is that for simple requests, you can just get verbal agreement to bill them for a few more hours, and for more complicated requests, you can add more scope-of-work pages as further contract addenda.

You're in a very fortunate position: they need you more than you need them, so you can pretty much dictate the contract terms. If you propose something reasonable like this, they should be happy. If they're not happy - and especially if they demand a fixed-price contract despite the cap I suggested above - that's an early warning that they're going to be a pain in the neck to deal with, so I'd just say, "Sorry we can't come to an agreement," and walk away.


If you can estimate how much money or value they would save if you automatize the preprocessing step, you would know how much to charge.

Will you provide the work as exclusive or do you have some potential in selling the same code to other customers? This can influence the price you ask.

Is the value you can generate for them is worth at least the double of what you would be paid for your just selling your time (consulting)? Decline the offer if you are under that, it would be too risky. Unless they are willing to pay more money that the value they get from the output.

Not the answer you're looking for? Browse other questions tagged or ask your own question.