I am a programmer, I am developing software expected to be between 50k to 100k line of code. I'd like to hire a company to develop an interface to my tool with other software by writing a plugin. This company has done it successfully in the past and I was recommended to use them.

However I have never negotiated before and I don't know how its done. I heard in retail one side gets lawyers to put in as much things as possible and the other removes as much as possible. In a different industry I heard distributors or publishers will promise large % of royalties however you'll never see them even if the product has done well.

How do I negotiate with a software company on pricing and possibly timeline of this plugin? What do they suspect I'll do? What should I expect them to do?

  • 1
    Just ensure you can walk away at any time without incurring further costs. And be prepared to do so should things start to go wrong. – edA-qa mort-ora-y Jul 6 '11 at 9:58

Negotiation is not a game.

I heard in retail one side gets lawyers to put in as much things as possible and the other removes as much as possible.


In a different industry I heard distributors or publishers will promise large % of royalties however you'll never see them even if the product has done well.


Here's what happens.

You have requirements, they make an offer to fulfill those requirements. They should specify time and money required. You can accept it or you can reject it.

If you accept, that's good. You liked their offer. It was complete enough that you understood it and you have confidence they will deliver.

If you reject, you would do well to suggest improvements they could make in their offer. It may be that your "improvement" is impossible or unwise or bad business. It also may be that your "improvement" is a change to your original requirements that reduces the scope or reduces the risk or somehow makes it cheaper for them to build what you want.

That's all. There's no "negotiation" like you hear about in politics or labor disputes or people's fantasy business magazine articles.

It's simply a conversation about your requirements and their offer.

A bad policy is one request for proposal, one proposal and one final accept/reject pass. That's common in governments and some businesses try to follow this model. It's good public policy but bad business. It's the most fair and even-handed to all the bidders. It's essential for transparent government operations. Businesses don't need this level of transparency, if they quality, services or products are a good fit for the businesses.

A better policy is a protracted conversation where you discuss the possible scope of work, and both you and your vendor act responsibly in defining a scope that gets you what you need, not what you thought you might want. Then you can get a responsible price and schedule for what you actually need.

I've written a lot of proposals for a lot of companies that have a single list of requirements that are laughably vague and yet completely "required". When we suggest that some of the dumber-sounding vagaries be dropped, they treat this as an unwillingness to write a "complete" proposal on our part.


When you negotiate with them, try to get a flat price for what you want. In my experience, companies have a tendency to underestimate the work needed, and you don't have control over how they get that work done. Sometimes, if they think its easy or you are a "smaller" customer, they will put junior programmers on the task or not make it their top priority. If they charge an hourly rate, this can end up costing a lot of money.

Have a concrete description of exactly what you want. Make sure they give you a timeline and check it carefully to make sure it makes sense. Again, try to get a flat price for the end result. Make sure there is a contract that spells out exactly what your expectations are. A good company should be trying to do everything they can to get your business, so make sure you are firm with your needs.

Hope this helps!

  • 1
    Flat rates don't go well with post-release maintenance. At the very least define who owns the source code and is able to make changes that might be required at a later time. If any maintenance or bug-fixing has to be done, who will do it at which cost? – Ray Jul 6 '11 at 9:52

I. Draft. First get a good idea of what you want. Future functions may be unclear, but you should have a very good idea on every part of what you want written now. Discuss with managers/designers of your contractor. They often have some very good ideas and a better clue what the customer might want than the customer has. Of course last word belongs to you, but these people often know "what works", "what is doable" "what is way over budget" and "what others tried and it simply didn't work".

II. Good Specs. This is 80% of the success.

You don't have to design everything yourself, but don't expect these people to magically peek into your head and know what you want. They will say what they are missing and you are to fill in. Even if it seems trivial or unimportant to you, just humor them, better to have too much detail than not enough. As you get the complete scope of the project, try to keep that fixed. There are few things more destructive to productivity than constantly changing specifications. Programmers -can- deal with that, but time will rise, price will rise and final product quality will drop. So plan well ahead, completely and competently, as to -what- you want, try to keep later changes to minimum, and all will be quite happy. If you aren't sure about parts of the project, modularize - "this is a feature we will request at a later time.", "currently unknown/undefined" is perfectly okay and better than something half-defined. This allows programmers to leave hooks for extension while not fumbling with code for something they don't completely know how to write. "Just do it somehow, show me how it works and I'll tell you if it's what I wanted" is the worst approach ever.

III. Deadline.

Arrange for a reasonable deadline and keep 2x as much time for reserve. The common joke is writing the first 90% of the app takes 90% of the allotted time. Writing remaining 10% takes second that much. This is true, as support/debug takes up at least as much resources as creation. Expect the deadline to slip, they always slip, don't panic, be forgiving but keep some pressure. And remember to include support contract in the deal.

IV. License.

Pay attention to license. You can commission work on your code, and purchase it all, codebase, copyright and all - which will be more costly but assures better profits and lower long-run costs. Or you can order the app but just purchase license, the software company keeps the copyright and they can sell the app to others. Nevertheless, arrange for updates and support in contract. This can be skipped with established, reputable software - not with something just-written. Don't agree to infinite price creep due to slipping deadlines, but also don't punish slipping deadlines too severely. It's better if the project is finished late than if you force deployment of unfinished product.

V. Oversight.

Stay in contact, request test versions, stay up to date with the progress, periodically see test versions of the program, to see if what is being created is what you want. Very few people can write perfect specs. It's very unlikely that you can. Programmers will write to specs but what you wrote may not be quite what you wanted, so better inform them early on if they are going in a wrong direction. Some things may appear to be doable much easier some other way than you intended. Listen, rethink, accept if it makes sense. Some things may appear much harder or impossible, so be ready for sacrificing them or deferring for future versions. And as much as you'd be tempted to add features in places where you feel you'd like them, defer that to next version. Bugs are to be mentioned calmly. They occur and should be fixed, that's normal. Specs violations in finished parts are to be pursued aggressively. This is something that should not be happening. (unless of course given part is "not yet implemented" or "work in progress").

VI. Deployment.

Don't expect 100% productivity jump overnight. Feel lucky if the system even starts working on day one. There will be errors. They are to be fixed. Employees will be slow to pick up on the new system. After some two weeks to a month everything should be ironed out to mostly smooth operation with people skilled enough to make identification of bottlenecks possible. Have them fixed in the first update, along with all the (numerous) bugs you will discover. Expect a fully functional and smoothly working application within half a year since deployment.