I have a potential client who has sent me the functional spec for their app idea. The spec is a PPT, which does a pretty good job at specifying the features, design and flow of information within the app. Of course, by just reviewing the spec you cannot be sure to be 100% certain you have acknowledged all requirements.

No contract has been signed, but they are very interested in working with me. We've agreed this would be a fixed-rate contract.

I'm considering suggesting to meet with their team and determine all requirements based on the spec. This seems like a lot of work for both teams (plus I wouldn't be paid yet) and something that should only be done after the contract is signed. Plus, it may turn them off from working with me.

Otherwise, does it make sense to send them a proposal with an estimate based on the spec, sign a service agreement based on the estimate, then meet with their team to formally review requirements in detail, then re-evaluate the cost?

My question is when in the process do you determine the "final" requirements for the project, and when do you determine what to charge for the work?

2 Answers 2


You said "they are interested to work with me", but the real truth is that they are interested IF your price if fine with them. Clients would always work with good programmers if the price meets their budget. If not, then suddenly they no longer want to work with you.

So what to do? Definitely DO NOT go to their premises and research project if it will incur costs to you. You will NEVER get paid for this. Not unless you put these costs later hidden under some other task, which is morally (and maybe legally) wrong.

So in projects like this, always go with some bulk costs to simply test the clients if they are aware of the potential costs.

For example, you can tell them "I would need to come to your premises and meet with your team to research what you need and to calculate costs of the project. But before I do this, I would like to tell you the rough costs of the project if I compare it to other similar projects I did in the past. The cost will be from X to Y dollars. Is this something that you expected and do you have the budget to cover the costs up to Y?"

With this approach you will get the immediate answer. If they say "this is way over our budget", then you can propose cutting off some features to meet their budget.

But DO NOT incur yourself extra costs before you know what their budget is. If they reject you with the bulk price, they would reject you in the end as well + they would get free idea analysis with costs.

  • Just wanted to update that I started with the range as you suggested, they sent me their specs, we went through a few rounds of revised estimates and today they have agreed to move forward with signing a contract. It's a big contract, I didn't sell myself short, and I'm super excited to get started. Thank you for your advice!
    – ryd3r
    Commented Jun 23, 2017 at 15:25
  • @ryd3r congratulations man!
    – Peter MV
    Commented Jun 23, 2017 at 16:57

'Final requirements' may be a problem, as customers virtually always want to make changes as soon as they actually see the product the first time. Regardless of the time spent, I have never seen 'final requirements' that turned out to actually be 'final'.

If at all possible, an iterative project model should be preferred instead of trying to hammer out all requirements beforehand. Having a short feedback loop, where the client monitors progress often is a good way to ensure the project stays on course.

Whether to bill by the hour or a pre-determined fixed-price depends on the client's and your needs. If their budgets are written in stone and they MUST have an unchangeable price quote, you'll need to go fixed price. Since this incurs a lot of risk on your side due to the almost inevitable 'scope creep', you should multiply your initial estimate by a factor which depends on your experience with the technology and the potential for unexpected surprises.

Personally, I would attempt to have the client accept a fixed hourly rate. However, this works better if the client has previous experience with IT-projects and accepts being part of the day-to-day process. One huge advantage with having an hourly rate is that it minimizes the 'gold plating' late in the project. If the client is billed for ALL small changes, they tend to think in terms of need-to-have versus nice-to-have, as opposed to the fixed price where they naturally will try to extract as much work from you as possible.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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