How do you quote for embedded software development?

[ricko_uk]

Hi,
I am curious about the various ways you could quote for a firmware development job.

Until now I always provided a fixed quote but some projects might be delivered with more bugs than others and sometimes it take a lot longer to debug after you think the project is completed.

How do you account and quote to cover yourself financially for such situations?

Thank you

[AndyC_772]

Always think about this from the customer's point of view.

Sometimes the nature of a job is that the thing you're working on is experimental and may simply not work, or not work well, or not work as well as it could do without further effort. This is completely OK provided both you and the customer are agreed that you're doing R&D, and that there's an element of risk involved. You can charge for all of your time, including time spent revisiting the design and making it better.

(As an aside, this is exactly what R&D tax credits are for under UK company law).

If, however, you're being asked to deliver a complete, working design, and you're confident that it's something that's within your capabilities, then any bugs are your responsibility. Only you know how good you are at writing good quality code and getting the bugs out of it before it's delivered to the customer, and you should use your own experience to quote accordingly.

If it then turns out that the first draft of your code actually works better than you expected, then that's great - you win. If, on the other hand, it has some nightmare bugs that take you ages to track down and fix, then they're absolutely 100% your problem and not your customer's. Spend the time on fixing them, make sure you're 100% happy with the end result, and deliver the proect to your customer with a smile. Provided your wins and losses balance out, you're doing it right.

The real problem with quoting for firmware isn't bugs, it's feature creep. This can be the dreaded "can you just make it do...?" after you've already quoted a price, but it can also be a spec that turns out to be incomplete, such as one which covers all normally expected conditions but omits unexpected or error states. Spot these in advance, and you'll end up with a much better relationship with your customer.

[SiliconWizard]

Yeah, first thing is spending a little more time studying the customer's specs BEFORE signing anything. Of course that may imply not getting the job if the customer won't give you complete enough specs or you decide that it's not going to work out for some reason - but this will save you a lot of pain down the line. Sometimes turning down a job is much more profitable than taking it.

The benefit of this extra step is that, not only you'll have a clearer view of what the customer wants, but you'll get to see how easy or how hard it is to work with them, before even "starting".

Also, for future unknown events that may change the execution time and that are not under your own control, you should always have a contract clause about this. Do not just hope you'll manage to arrange something with your customer if you haven't anticipated it in the contract.

In particular, events that could fall into this category would be customer requirements that were not given upfront, or difficulties to get complementary requirements/answers from the customer you might need during the project's execution. Any "unreasonable" delay in getting required information from your customer should be duly noted, and then you can use this to remind your customer the contract clause, and  negociate extra fees for instance.

OTOH, obviously, bugs that are pure implementation bugs (and not due to erroneous or incomplete specs) are your own concern. They are by definition very hard to anticipate, but you can anticipate you'll have bugs, and take this into account in your quote.

[rstofer]

IBM used to estimate that a good programmer could produce 100 lines of debugged and documented code per day.  So, 12 lines per hour...  And that assumes you already know about the component choices.  If you have to learn about a CPU in order to program it, the output could be less.

If you estimate the job will require, say, 12,000 lines of code, it should take about 1000 hours to produce.  Then you just need to decide what your labor rate (pre-tax) should be.  Is it $50 per hour?  $100 per hour?  Whatever, just multiply by 1000 hours.

Then add 20% for contingency - there will always be problems.  The thing is, everybody wants to eliminate the contingency from an estimate.  I always bury some contingency in every line item and then let them delete the block contingency at the end of the quote.  I'm still covered.

When estimating projects, I find it useful to come up with as many distinct line items as possible.  It's a lot harder to attack the total when it is composed of dozens of line items.  The customer may not like the price but it's difficult to attack the detailed breakdown.

I spent most of my career working on projects.  Not computer projects but, rather, building construction projects.  My customers were almost always internal.  It's amazing how money moves around inside a company.

Nevertheless, the approach is sound.  Many small line items which individually include contingency add up to the project budget which should include some additional contingency which will always be attacked.

Sometimes the customer doesn't want to know about details.  That's fine but it doesn't change the total.  If I had to code a display driver and I thought it would take 12 hours, that's what I would include in my internal estimate.  If the keypad driver was estimated at 6 hours, so be it.  If the interrupt handlers would take another 10 hours and porting FreeRTOS would take 40 hours, that's what goes in the estimate.  I would list as many 'tasks' as I thought the project would have.  Among other things, this approach prevents me from missing major pieces of work.

There is also a strategy of bidding:  You bid low and hope for change orders when you need to keep working or keep your crew working.  You bid high when you are busy and don't really want the job but you don't want to lose the long term relationship.  If you get the job, be worried that you forgot something!  Don't assume your competition is incompetent!

[bson]

Depends on your role.

If you're a contract worker, working on their product, bill hourly.

If you're a business and are licensing software, then there's a license fee paid up front and a separate support agreement that's recurring.  You should let them evaluate what you have, and they may require specific changes or a support period.  Figure out how much you'll want to charge for that on top of the base license and give them a quote.

It sounds like the former would be more applicable.  Basically, as long as you work for them they pay you by the hour.  If they don't feel you're productive enough or don't need you anymore they can end the agreement.  (So can you.  It takes two to tango.)

If you bill by the hour be very specific about any existing code you bring in, like libraries or such - that needs to be spelled out plain text that you only give them a license and what the scope of that license is.  Otherwise you may find they own it, but didn't pay you to create it.  It's VERY common for contractors to reuse existing code developed outside of contract work, exactly to get stuff done rapidly.  This can be a major selling point!

I'd strongly recommend incorporating if you do a lot of contract work.  It makes it easier to structure agreements, hire additional help, license existing code bases, etc.

[NorthGuy]

Fixed amount is the best for everyone. Fixed requirements even more so.

Bugs are your responsibility. You have to fix them for free. Even after the project is over.

[bson]

Oh, and I should mention if it's not a commodity item (i.e. not something listed on a website they can stick in a cart, or the IRL equivalent) - then the  license price needs to be high.  They will demand things like support, maybe various changes, and such - and you want pricing headroom without having to increase the license fees.  It also gives you room to negotiate, and the customer will be MUCH happier having talked you into a 35% discount than you having tacked on 40% for various asks - even if the total is the same!  So "base" here means BOTTOM LINE.  You never go below the bottom line; this is a predetermined price at which point it's no longer worth your while and you walk away.  Not every deal will close; if they do, you're leaving money on the table.  Some you will simply walk away from, or the other party will.  You should set and continuously adjust your base price accordingly.  And never share it with anyone.  Never yield on it during a conversation.  You can always adjust it when you have time to sit and think it over, never adjust it during a meeting.  Then go to the next meeting with your adjusted base price (or, bottom line if you prefer that term).

[mikeselectricstuff]

Bugs are your responsibility. You have to fix them for free. Even after the project is over.

Debatable for the case of bugs discovered after the customer has tested & approved the code though.

[mikeselectricstuff]

but it can also be a spec that turns out to be incomplete, such as one which covers all normally expected conditions but omits unexpected or error states. Spot these in advance, and you'll end up with a much better relationship with your customer.

If you don't raise multiple queries about missing/ambiguous/incompleteness issues in a customer-supplied spec, then you've probably not looked at it carefully enough. As someone who will be implementing it, you will see things that haven't been considered from the functional design/spec angle.

IME I usually have to write a complete new spec based on what the customer has told me & get them to agree, as theirs is typically woefully inadequate and incomplete.

[SiliconWizard]

Bugs are your responsibility. You have to fix them for free. Even after the project is over.

Debatable for the case of bugs discovered after the customer has tested & approved the code though.

A decent contract usually includes some warranty period after the execution is over, so that includes possible bugs discovered during this period. That period may be anywhere from a few weeks to a few months depending on the project. A customer that would accept signing without such a clause would be pretty dumb.

[nctnico]

Bugs are your responsibility. You have to fix them for free. Even after the project is over.

Debatable for the case of bugs discovered after the customer has tested & approved the code though.

A decent contract usually includes some warranty period after the execution is over, so that includes possible bugs discovered during this period. That period may be anywhere from a few weeks to a few months depending on the project. A customer that would accept signing without such a clause would be pretty dumb.

Indeed. Once the customer has signed off the project is done. Any changes that need to be made are a new project / contract.

Fixed amount is the best for everyone. Fixed requirements even more so.

Yes. In reality there ain't not such thing as a blank cheque to develop for as long as you want. Try to avoid such situations because in the end nobody will be happy. IOW: any kind of price you mention will be considered a fixed price even if you state it is an estimation. An exception is doing small jobs for a customer where there is enough mutual confidence that price versus the amount of work will be reasonable. But that is rare.

[T3sl4co1l]

If you bill by the hour be very specific about any existing code you bring in, like libraries or such - that needs to be spelled out plain text that you only give them a license and what the scope of that license is.  Otherwise you may find they own it, but didn't pay you to create it.  It's VERY common for contractors to reuse existing code developed outside of contract work, exactly to get stuff done rapidly.  This can be a major selling point!

Could you recommend any standard license terms for this?

Tim

[nctnico]

If you bill by the hour be very specific about any existing code you bring in, like libraries or such - that needs to be spelled out plain text that you only give them a license and what the scope of that license is.  Otherwise you may find they own it, but didn't pay you to create it.  It's VERY common for contractors to reuse existing code developed outside of contract work, exactly to get stuff done rapidly.  This can be a major selling point!

Could you recommend any standard license terms for this?

You have to define what the customer is paying for, what kind of third-party libraries you intend to use (beware of GPL code!) and which part of the code falls under your own copyright (libraries). By default the copyright of any software you develop entirely by yourself at your own premises is yours even if someone is paying you to do so. Not everyone is aware of that. In my terms & conditions I have defined that the client becomes the copyright owner after they have paid the sum in full, except for third-party and my libraries. For my libraries they get a non-transferable license for use.

[ricko_uk]

Thank you very much to all, very interesting feedback and useful information!!

Appreciated as always!!

[passedpawn]

Fixed amount is the best for everyone. Fixed requirements even more so.

Bugs are your responsibility. You have to fix them for free. Even after the project is over.

Utter nonsense.  Fixed is worst for everyone.  I've been consulting for a long time, electrical design, layout, firmware, software.  I refuse to do a fixed-price job anymore. 

For experienced developers, it's pretty easy to quote a project as an "estimate" and be fairly close to target.  But in my quotes, I state that "scope creep", unexpected difficulties, and the normal difficulty of inventing the customer's time machine could push the costs to 2x. 

[NorthGuy]

Fixed amount is the best for everyone. Fixed requirements even more so.

Bugs are your responsibility. You have to fix them for free. Even after the project is over.

Utter nonsense.  Fixed is worst for everyone.  I've been consulting for a long time, electrical design, layout, firmware, software.  I refuse to do a fixed-price job anymore. 

For experienced developers, it's pretty easy to quote a project as an "estimate" and be fairly close to target.  But in my quotes, I state that "scope creep", unexpected difficulties, and the normal difficulty of inventing the customer's time machine could push the costs to 2x.

Contractor is a business, not an employee. The business sells products or services and takes full responsibility for the things it sells. This is not customer's concern how the services are produced. If there's something unexpected, the business absorbs the cost. The business may actually lose money if the costs are much higher than expected. And conversely, If there's a mission creep, it's up to the business to agee or refuse. You may agree to do extra for additional pay, but you may refuse as well, for example if you're busy doing other stuff.

What you portray, looks more like employer - employee relationship, where the employers buys your time and then he decides what to do with it - he can push any mission creep on you as he wants. If something goes wrong, even if you fail to produce what he wanted, even if you do nothing, he still pays you for your time.

[Siwastaja]

The business sells products or services and takes full responsibility for the things it sells. This is not customer's concern how the services are produced.

Except that outsourcing HW/FW engineering usually isn't providing a black box product. It can be, but often this is design and implementation in cooperation with the customer. Customer may directly participate, for example write another layer of software. At least it's completely normal for the specification to flex during the project, which immediately makes the process completely different to that of just selling a product.

So it really depends, fixed cost can be very good if the work is mostly as you say delivering a product to the customer, but if it's more about working together with the customer then it's closer to the employment as you say.

It's not black&white, it can be a strange mix of those approaches.

[aandrew]

Contractor is a business, not an employee. The business sells products or services and takes full responsibility for the things it sells. This is not customer's concern how the services are produced.

IF the spec is clear.

IF the acceptance criteria is clear.

IF the customer actually knows what they want.

Those are some enormous ifs.

No, fixed-bid is a fool's errand. Every customer wants it, but damn near every customer also refuses to sit down and develop (at their cost!) a full specification, including acceptance criteria. Every customer wants some scope creep as things progress.

So no; much like building a house, you hire contractors (who are ALL paid hourly), and as it's being built you realize you want that wall moved a little, or you want something that wasn't in the original plans, or want something that was in the plans changed or removed. Development, like construction, is a highly dynamic process. You can't realistically bid a fixed price without also absolutely locking down the requirements and clearly defining the finish point, which is damn near impossible. And yes, you can stipulate that changes require re-bidding, but then you get into pissing matches over "it's not THAT big a change" -- it's not worth it.

I've been doing this a long, long time now. Fixed bid contracts are a unicorn.

[T3sl4co1l]

¿Por que no los dos?

Contracts are malleable, simply a statement of what the parties have agreed upon; if they are open to the option, milestones can always be added onto an initial "fixed" bid.  It needn't be a dichotomy, there's a continuum of possibilities between fixed-at-start bid and pure hourly.  Could even do hourly with different rates for different segments, etc. (though I'm not sure why you'd bother, heh).  And it can be written in that all steps are mandatory (so for overall project purposes, it doesn't matter if it's broken into stages; what amounts to structuring of payments), or that some steps are optional (given that some can't be done out of order, some will be dependent on completion of earlier steps).

The way to deal with feature creep in fixed projects, is to simply remind the client what they agreed upon, and suggest that, if they are interested, such features can be added on for this-and-that additional time and cost.

Tim

[nctnico]

Contractor is a business, not an employee. The business sells products or services and takes full responsibility for the things it sells. This is not customer's concern how the services are produced.

IF the spec is clear.

IF the acceptance criteria is clear.

IF the customer actually knows what they want.

That is why you have to turn things around. My motto is 'don't make what the customer wants but make what the customer needs'. Usually there are only 2 things clear to the customer: the budget and what a product may cost. So what I do is listen and observe the processes and wishes from the customer very carefully. From there I make a detailed description of what is going to be delivered and how much it is going to cost. From there the customer can accept the quotation, negotiate to make it cheaper or hire someone else.

Whatever needs to be altered or added later on, goes into a new quotation and basically is a new project.

[ejeffrey]

You have to define what the customer is paying for, what kind of third-party libraries you intend to use (beware of GPL code!) and which part of the code falls under your own copyright (libraries). By default the copyright of any software you develop entirely by yourself at your own premises is yours even if someone is paying you to do so. Not everyone is aware of that. In my terms & conditions I have defined that the client becomes the copyright owner after they have paid the sum in full, except for third-party and my libraries. For my libraries they get a non-transferable license for use.

Be careful that this isn't legal advice because that varies from jurisdiction to jurisdiction and the exact nature of the relationship.  Sometimes in the US at least, things can qualify as a "work for hire" and copyright defaults to the person paying the bills.  But it's always best to have an explicit ownership statement in the contract to avoid confusion.

The way we usually do it is that there is a general statement about "background IP" vs "developed IP".  Then there is a section to list each parties background IP that they expect will be used in the project.

[ejeffrey]

Contractor is a business, not an employee. The business sells products or services and takes full responsibility for the things it sells. This is not customer's concern how the services are produced.

IF the spec is clear.

IF the acceptance criteria is clear.

IF the customer actually knows what they want.

Those are some enormous ifs.

No, fixed-bid is a fool's errand. Every customer wants it, but damn near every customer also refuses to sit down and develop (at their cost!) a full specification, including acceptance criteria. Every customer wants some scope creep as things progress.

Fixed bid a good way to avoid scope creep?  Jumping into a non-trivial project on time and materials basis without a clear goal is a way to have an unhappy customer.  Even if you are doing hourly, you need to have a well defined goal so that you can give an estimate that the customer understands.  It doesn't have to be all or nothing, if your customer doesn't understand enough to build a detailed spec, you can charge them consulting fees to develop the spec.

So no; much like building a house, you hire contractors (who are ALL paid hourly), and as it's being built you realize you want that wall moved a little, or you want something that wasn't in the original plans, or want something that was in the plans changed or removed. Development, like construction, is a highly dynamic process. You can't realistically bid a fixed price without also absolutely locking down the requirements and clearly defining the finish point, which is damn near impossible. And yes, you can stipulate that changes require re-bidding, but then you get into pissing matches over "it's not THAT big a change" -- it's not worth it.

I'm not sure what your point is, construction projects are very often done fixed bid.  I just did one. Yes, the trade workers are paid hourly, but the general contractor bids a fixed price and the subcontractors generally bid fixed price to them.  Part of the job of the contractors is to be able to accurately estimate the amount of work. Fixed price puts them on the hook to do a good job. If you want to make a change that materially affects cost, they do a change order.  Not everything needs to be set ahead of time, our contractor put in allowances for things  like carpet and tile choices and then updates the bid when they were chosen, and since it was an addition to an existing structure they identified specific cases that might need to change based on what was discovered during construction.  It was fine. 

[peter-h]

If you are good and know the hardware, and there is a clear spec, quote fixed price, plus an hourly rate for additional work.

If you will be learning on the job, and/or aren't good, quote hourly The customer will probably not be happy though...

This is a very difficult area. Most customers will feel ripped off by any contractor who is less than very good, and of course most contractors are considerably less than very good.

[westfw]

Contractor is a business, not an employee.

Actually, it could be either one.  At least, the US is full of "contracting agencies" that will rent you a person with supposed expertise in some area, at prices very much like normal wages, but apparently with a lot less "red tape" for the company getting the end work.

You can also say "I'm an expert at XYZ and can make and license you an obvious variant of that for a fixed fee and it will have this list of features for flat $$$", and that's cool too.
The good relationships are the ones where both the contractor and the person/company that is hiring them are in good agreement as to which thing they are getting (time, or product.)

[Kjelt]

Split the project up in a couple of deliveries and get feedback.
So if there are ten "features" create 5 deliveries, 5 terms of  payments and demand feedback from the customer, being agreed sign off or not ok need rework or different implementation.
Agree that between deliveries both parties are allowed to break up the contract if there serious reasons.

The reason I would do it lije that is that most customers do not have a 100% understanding of what they want at the start. Accept that and take it into account. As the work progresses they get a better understanding and change requirements. In the above contract you can then also adapt the schedule (project adds more deliveries and payments or less depending)

The reason that both parties should be able to break up is for the customer the project in total will cost way more then expected or the result is not what they would like. In your case it could be lack of timely payment but also fir instance you find out that what the customer wants is just not feasible, for instance the choosen and provided microcontroller is too light weight for the task or other hardware or software restrictions you encounter.

[nctnico]

also fir instance you find out that what the customer wants is just not feasible, for instance the choosen and provided microcontroller is too light weight for the task or other hardware or software restrictions you encounter.

I never let customers determine which parts to use. That never ends well because if they had the real expertise to choose the components, they could also design the entire product.

[Siwastaja]

also fir instance you find out that what the customer wants is just not feasible, for instance the choosen and provided microcontroller is too light weight for the task or other hardware or software restrictions you encounter.

I never let customers determine which parts to use. That never ends well because if they had the real expertise to choose the components, they could also design the entire product.

Exactly this, and if they really had a clue how to design things they would know to let you choose important parts like the microcontroller, because a designer usually is hugely ineffective with parts they are not familiar with.

So they are asking for the specific MCU only because they are totally clueless. Maybe somebody in the management just saw a nice Powerpoint presentation, or heard some name in some casual discussion, that's all.

Of course you can still do it but you need to communicate very clearly that your quote includes 200 hours of buffer for working with an unknown-to-you MCU and why you think this is an extremely inefficient idea.

[nuclearcat]

also fir instance you find out that what the customer wants is just not feasible, for instance the choosen and provided microcontroller is too light weight for the task or other hardware or software restrictions you encounter.

I never let customers determine which parts to use. That never ends well because if they had the real expertise to choose the components, they could also design the entire product.

Sometimes i search compromise in such situations.
If the client asks for, for example, ARM Cortex-M, or even STM32, this is not a problem. (unless it is something exotic or they ask for part that doesnt fit the job)
It might be reasonable, if he has plans of further software support for the product "in house", and he chooses according to the availability of programmers in his team.

[peter-h]

Yes; one should not be too hard-line about hardware choice.

For a company, the choice of hardware is a critical job. These days, almost nothing is multiple-sourced (except resistors, capacitors and trivial analog chips ) so you have to think long-term. In the old days, Z80 etc, you often ran right on the edge of what the hardware could do. I did consultancy for years and often used an FPGA (Xilinx 3k/4k) to make it possible. Today, an ARM 32F4 is probably 10x-100x fast enough for most jobs, and 1000x fast enough for the "Z80 jobs" especially if floats are involved. But at £5 each (500-off, 32F417, just placed the order) there is no point is going for less power unless it is something cheap (which will usually be massive volume then i.e. a lot of custom silicon).

Also the customer may well have an EMC-qualified product which they don't want to totally re-do following lab tests.

So the customer may well specify much of the BOM, like CPU, ETH chip, 3.3V LDO regulators, ADCs, DACs, and such like, for you to use.

But this goes both ways, because a consultant familiar with the chip will do a much better job (within a given budget) than one who isn't. The customer should simply not employ someone who needs to learn this. As an example, I am working on a project on which another programmer spent a number of man-months sorting out bugs in ST drivers. That kind of thing (having a solidly debugged hardware+software platform) will make that consultant worth 10x more.

I think a company needs enough expertise to make hardware (and basic software architecture) decisions and then needs to find a consultant/contractor who is already familiar with that stuff.

I have known plenty of cases where somebody had a product which they had demand for but could not make anymore because it was full of weird chips, which nobody would use in their own business One example was a box containing a transputer (yes the Inmos chip: https://en.wikipedia.org/wiki/Transputer) and for no reason; it was obviously doable with a 4MHz Z80 which pre-dated the transputer by maybe 10 years! The contract designer just loved this chip and this was an excuse to play with it. The company ended up buying up museum samples on Ebay. After many years they threw money at it and got it redesigned.

If you let the contractor choose hardware at this level, you tend to end up with - at best - a different chip for every product and in most cases with negligible overlap in the BOMs which will make your stock levels much bigger than needed. Even stocking a 1k 0805 and 1k 0603 is a PITA because if you extend that across the board you end up stocking 2x more passives. Or 1k 0603 and 1.1k 0603 where the 1.1k is probably pointless.

[Kjelt]

also fir instance you find out that what the customer wants is just not feasible, for instance the choosen and provided microcontroller is too light weight for the task or other hardware or software restrictions you encounter.

I never let customers determine which parts to use. That never ends well because if they had the real expertise to choose the components, they could also design the entire product.

Agreed if the customer wants you to do HW + SW.
But that is not this topic, it is SW only which probably means the customer had another person do the HW or if you are lucky it also still needs to be designed and you get a say in which uC etc.

[nctnico]

also fir instance you find out that what the customer wants is just not feasible, for instance the choosen and provided microcontroller is too light weight for the task or other hardware or software restrictions you encounter.

I never let customers determine which parts to use. That never ends well because if they had the real expertise to choose the components, they could also design the entire product.

Agreed if the customer wants you to do HW + SW.
But that is not this topic, it is SW only which probably means the customer had another person do the HW or if you are lucky it also still needs to be designed and you get a say in which uC etc.

Well, the right order is to prototype the software using a development board first and then commit to hardware.

[Siwastaja]

Well, the right order is to prototype the software using a development board first and then commit to hardware.

Completely depends on the project. If the HW is "trivial" (i.e. something that can be built in hours on breadboard and jumpered to the devboard) and the application is software control heavy, that's a very good approach; you save time because you can start developing SW right away with the devboard proto while working on the final PCB in parallel.

OTOH if the "meat" of the project is, say, a motor inverter, a complex switch mode converter or similar, you can't quickly do it on a breadboard. It's all about proper engineering, PCB layout, and so on. So if done in the way you suggest, you would create a custom prototype PCB which does everything else except the MCU, and wire it up to the development board. While this is doable and I have done it because the customer wants such step in the process*, in my experience this just wastes time being an unnecessary extra step; if you commit directly to the prototype of the actual product, you are one step closer to finishing it.

*) or it's typically because the customer wants a small sub-project, because they are also subcontracting to someone else, and they don't want to provide too much in order to have another project in the future! In such case, thinking about the "big picture" is definitely forbidden.

[nctnico]

It also depends on the volume of the end product. Or put differently: if a product is going to be produced for less than 1k to 10k units it really doesn't matter whether you spend 1 euro or 5 euros on a microcontroller. The NRE costs will swamp the price difference. So better start with a microcontroller which is on the safe side of having enough performance. One of the critical errors I have encountered in my carreer is to (excessively) cost optimise low volume products which then leads to spending a crap load of time on getting the software optimised to a platform which isn't capable enough.

Taking this back to the topic: quoting for software development also includes a good insight on hardware abilities versus what is being required from the software.

[aandrew]

My motto is 'don't make what the customer wants but make what the customer needs'.

I try to do that but plenty of customers aren't interested in listening, the just want you to do what they ask. I'm fortunate in that I am mostly at a position in my career where I can be choosy about my customers, and I tend to avoid these. Still, fixed-bid is oftentimes way more hassle than it's worth. If the customer isn't understanding that this is a fluid process or feels that I am going to "run the clock" to milk them, then I really don't want to work with them. In the end it's a game of mutual trust.

[SiliconWizard]

My motto is 'don't make what the customer wants but make what the customer needs'.

I try to do that but plenty of customers aren't interested in listening, the just want you to do what they ask.

Well. That's what you're kind of entitled to as a customer. Now if what they want is not technically feasible, or some other solution would make more sense, it is your responsibility to make that clear to them. If at this point, they don't want to listen, you just don't take the job. The point is not even whether you are *right* or not. Even if it's indeed unusual, the customer may have a good reason after all. But if you take the job while you are convinced it's bound to fail, then you're going to take both of you down. Just don't do that.

I'm fortunate in that I am mostly at a position in my career where I can be choosy about my customers, and I tend to avoid these. Still, fixed-bid is oftentimes way more hassle than it's worth. If the customer isn't understanding that this is a fluid process or feels that I am going to "run the clock" to milk them, then I really don't want to work with them. In the end it's a game of mutual trust.

Fixed-bid works well when the project is well defined. Right from the start. If it's not, then it's of course risky.

Sometimes, the customer is not necessarily witholding information, but they don't know/have the resources to properly specify what they want. In this case, if you think the project may still be worth it, you can offer the customer to help them with the specs. You can make that a first milestone with a go/nogo status.

[CatalinaWOW]

The IBM estimate was based in large projects with multiple software team members and a range of skills (not including newby or incompetent.  YMMV.  Make sure you know your own productivity if bidding your services.  Errors can price you out of the market or cause you to work inordinately hard to make your commitments.  The largest merit of the IBM estimate is that it has widespread credibility, and if you can do better can result in excellent profits for you.  But beware, starting programmers seldom can.

[Kjelt]

My motto is 'don't make what the customer wants but make what the customer needs'.

I try to do that but plenty of customers aren't interested in listening, the just want you to do what they ask.

Yup very common and everyone can recognize this