Software development · Offshore

Do you pay development shops by the hour or by the task?

Lorenzo Polacco Snr Director, Sales & Advertising Operations at Yahoo!

February 22nd, 2016

It's challenging to deal with dev shops, especially as the estimate they give you for work you send them, ends up always being too low and they try to charge you more. How do you deal with this? Do you pay by the hour and trust their hours-spent reports? Or do you pay them by the task, regardless of hours taken? OR how else?

Patrick O'Leary Helping digital media companies "sell smarter to get their unfair share of the budget"

February 22nd, 2016

One way to mitigate this is to pay time & materials for the requirements and/or design, then ask for a fixed price estimate for build & test.  This may be tedious on small items but absolutely works for larger features and projects.


February 22nd, 2016

I really prefer scrum.  Build the most important things first.  Pay weekly.  Pay for results.  By week 2 or 3 you should really start to have a strong release build and even if you only get 1/2 way before you run out of money, you have done the most important 1/2 to a great quality and have a bad arse launch no matter what!  If you don't get a great immediate result, but really like the people let them start over.  Doing the first 10% a few times is way better in the long run than doing the last 10% a few times.  High fives of awesome, -J

Kevin Chugh Founder, Main Street Computing

February 23rd, 2016

You will inevitably pay someone for their time.  Either you're going to hire someone directly, and pay them per week, or you're going to hire a shop and seek the lowest price and a fixed fee, and inevitably the deal becomes one sided and they leave you or you leave them.  This cycle repeats until you develop a bitterness toward freelance developers and professional dev shops.  The only long term solution is to find someone you trust (who is competent and honest), and pay them hourly. You should both invest the time to scope and implement checkpoints and procedures, but per-task or per-project is nearly impossible to pull off, and it is usually a one time engagement because one party inevitably leaves the relationship.


February 23rd, 2016

Thank you for the bump Josh McCormack!  If you are just interested in creating amazing software and making sure you cannot lose, you will go my route.  You can have predictable cost, predictable time to market and be a little flexible on the features.  You can work with others to build the most amazing thing you can all thing of together, all along the way, instead of trying to have a few people think it all up in advance when everyone knows the absolute least.  I can build 4 products in the time it takes you to do a proper useful job of planning one, which makes it not useful anymore.

Rich Guess IT Leadership, Product Management and Design, Music

February 22nd, 2016

If your app is well defined and you can really get to the task level, an estimate could be accurate. 

If you are working an MVP, take the approach above and include a maximum budget and specific handling for change controls. 

Peter Bray CEO at Bray & Co

February 22nd, 2016

Pay by project. Flat fee, to an agreed scope

A S Co-Founder

February 22nd, 2016

Hi Lornezo, I have been on both sides of the table so let me present this from both perspective. As a provider, I have seen clients who were not sure about the requirements and features changed midway during the project execution. Some of them understand the cost escalation if changes are introduced halfway through the project, some don't. As a client, I have seen hours-spent reports where the bloat is too obvious. Being a developer gives me a fair idea of how much time a particular task should take for a given level of experienced dev. My view is - make your tasks well defined and ask for a fixed cost project. Any worthy dev-shop would agree to fixed cost project if the task is well defined and no significant changes are introduced midway. Even larger projects can be broken down into smaller units of well defined tasks, each with a fixed cost. If you are going with hours-spent report, then having a technical advisor by your side will help you in going through those reports for bloats. Thanks, Animesh.

Darpan Dhamija Investor looking to invest

February 22nd, 2016

What I have seen to work the best is, to break down the project into features and use different dev shops to develop different features and finally integrate either yourself or get it done by another dev shop.
This way you get cheaper/less important feature develop in cheap.
Another thing, that even I have done before is, find a local person who controls the dev overseas, helps mitigate a lot of your problems. I used to have my own startup to provide resources like you desire and did the project management from here with face to face meetings with clients. Under the hood, I had my own devs and many more dev shops I had personal relations with. Helped me distribute my workload and handle multiple projects at the same time and clients were happy meeting me and not spending odd hours as per devs' timezone as all that was handled by me.
I always integrated all the features myself before delivery ensuring quality of the final product. I don't do it anymore, but I do know a few friends who have this model running.
Try to find such devs, let go of some control over devs as devs perform better with less management, have more control over product instead. If you are not technically that sound, hire a person who is, it'll help you immensely.
just my 2 cents.

Ajay Agrawal

February 22nd, 2016


We are a New Delhi, India based bespoke software and solution provider with a focus on ERP, Supply Chain Management and Warehouse Management for several domains.


We approach this issue slightly differently.


We encourage our customers to define their business processes and then grade (on a scale of 1 to 10 where 1 is the minimum and 10 is the maximum) these business processes according to the pain they cause in their business (in the absence of appropriate software) and the reports that could be helpful to them in mitigating these pain points.


Our costing team creates a matrix defining each business process and the estimated time with the associated cost. Our team also defines the business processes which would be pre-requisites for the subsequent processes.


This methodology enables our customers (and us) to have a sign-off sheet and a fixed cost contract so that both of us know what is being paid for, and how much and when. During the execution of the project (or afterwards), in case any additional requirements come up, we quote a per hour cost. While estimating the time for these changes, we also give a ‘Not to exceed’ cost for the approval of the customer.


This approach eliminates the uncertainty for both - our customer and us. The biggest benefit of this approach also is that the customer need not necessarily have a technical co-founder. Effectively, we are part of their team without them having to dilute their equity.

Paul Chambers Founder, Nymble Technology

February 22nd, 2016

TL;DR: I've been on both sides of the table. The key is great communication and the trust it builds - without it, the project will run aground whatever the terms of payment.

What most folks don't understand is that 'small details' of a task's definition can have significant impact on the work required. What may be 'obvious' to the specifier can easily be assumed to be different (or unimportant) to the implementer.

You should always assume that you don't understand the problem well enough to specify it completely and unambiguously. If you think you do, chances are you're in for a rude awakening, whomever ends up doing the work. If it's not you, it's harder to understand the trials and tribulations an external team is experiencing, and much easier to point fingers.

Good software engineers think differently to the general population. One of the reasons they shouldn't define a user interface :). They communicate differently too, which is only reinforced by spending a good portion of their waking hours expressing themselves in code (which is very precise and unforgiving) and about code to others engaged in the same discipline. What you said and what they heard can easily differ, even more so than routinely happens in business communications.

In my opinion, there is no 'magic formula' or 'best practice' for guaranteeing a successful outcome. It's all too easy for bad assumptions and poor communication to undermine the relationship, and amplify any doubts and mistrust that exists.

When consulting, I'm happy to bid on a fully-specified job, but the reality is - I have yet to see one, in more than three decades. Usually it isn't hard to generate a lengthy list of open questions that impact the level of effort. If I ever were to come across such a project, I highly doubt my bid would be competitive - a good part of the value I offer is in resolving both the known and unknown unknowns, not in translating a spec into code.

Something I've run into many times in my career is the difficulty of proving that your actions or advice contributed to the successful outcome. In other words, it's impossible to prove you anticipated problems and prevented potential disasters.

Rarely is the genius in an elegant solution recognized, because it's consideredobvious -in hindsight.