If you find yourself in this position, you’re probably pretty stressed. If you have done it more than once, you’re probably also getting pretty jaded.

If you haven’t commissioned custom software before, here’s a few questions that may be familiar:
  • I got 3 quotes for this project, and they range from $2,000 to $20,000 – how can this possibly be, and how do I make this decision?
  • I have 3 different companies telling me that each of their 3 different technologies are the best ones to use, how do I know?
  • When we started the project, features came out steadily at a good pace, but now it seems to take forever to even get the simplest thing done. Are the developers getting complacent?
The typical pattern here is you have an idea, and you want to build it out into software. You need to dig up some money to fund it, so you need some idea of what it will cost to build. You scope out the best requirements document you can, and you send it to a few dev teams for a “quote”, you see what kind of money you can drum up, and you choose the team that provided the best quote.

It sounds simple, and for things like installing an air conditioner, this approach works well. Why does it fail so completely for software projects?

First and foremost, software development isn’t a commodity. Oh there’s pressure to commoditize it, especially from offshore agencies, but this is a dangerous facade. The moment you begin down the path of comparing individuals or dev teams on their hourly or per-diem rates, you’ve fallen into this trap.

You have to remember as an entrepreneur, that this is all a highly creative and collaborative exercise. Your original idea is a product of speculation, perhaps drawing upon a lifetime of experience, well researched and thought through, but speculation nonetheless. Until you have a community of paying clients, your idea remains unproven.

The goal here, is to get you from zero to paying clients as quickly as possible. Once your business is up and running, with a bit of listening you can easily seek out the flaws in your original ideas and tune them to fit the clients you want. The goal here is to develop what author Ken Blanchard calls Raving Fans. These are your clients who will propel your explosive growth, and make your venture successful.

If this formula were as simple as picking up the manufacturer-recommended parts and installing them, we’d have a lot more successful ventures out there.

The challenge is finding a dev team that you can talk to and with whom you can connect. A team that can help you with creative problem solving in finding what Eric Ries (founder of the Lean Startup movement) champions as the Minimum Viable Product. That product you can bring to market that will successfully gather your base of Raving Fans, who will propel your venture to success.

If you find a team you like, but don’t understand why their hourly or per-diem rate seems high compared to others, ask them why.

Focus not on the price, but on the team itself.

  • How many people are on the team?
  • How long have they been together and how many projects have they delivered together?
  • What would the impact be on your project if one of them left the team? Got ill?
  • When you talk to them, ask them questions about your project to see how much they understand your context. Do they challenge your position, expose your assumptions, offer alternate suggestions?
  • What, beyond their time, do they offer to contribute to the success of your project?
    • experience?
    • software tooling?
    • test environments?

So back to our original 3 challenges: price variance, technology choices, sustainability.

Price Variance

You’ll probably find that the higher quotes have a more holistic viewpoint on your project. You may find that the lower quotes are a little naive or risky, especially if the developer or team is new in business – developers have an awful habit of underestimating effort, and underestimating their cost of doing business. So often I see people working with inadequate equipment or poor tooling because they can’t afford better. If the rates are high, ask about what’s included in the rates – don’t just assume they’re gouging, if they’re experienced chances are they’ll be able to explain them and that can be an opportunity to negotiate.

Ask them why they charge that rate, look for some business insights in their response.


Technology choice is very rarely the cause of project failure. Personally, I can’t put my finger on a single project that outright failed due to the technologies chosen. If a team is confident to recommend a technology, it’s likely they’ll have their own best chance of success using that technology. How that weighs against a different team on a different technology often says more about the teams than it does about the technology. Be wary of a team that won’t explore beyond their technology comfort zone, because their own technology preference will shift underneath them and abandon them one day.

Ask them why they use that technology, look for an answer other than “because it’s the best one,” or “it’s what we learned in school.”


Being a professional developer goes far beyond simply knowing the syntax and lexicon of a programming language. It touches on communication, and a number of design principals that promote sustainable development and aren’t yet taught in any institution I’ve ever seen (i.e. the S.O.L.I.D. principles). Developers struggling with syntax and lexicon lack the capacity to put the higher order design principles into play. Writing software sustainably takes experience, and someone who closely tracks the current state-of-the-art of software development, not a particular programming language.

Ask them about their longest running project – software requires maintenance over the years. How do they feel about maintaining systems over the long term? How do they feel about discarding previous work to re-write it anew?

Ask for references and follow up with them. Look for references that are unbiased but loved working with the team. Check up on a mix of long-running and short-term project references to get an idea how quickly the team clicked, how they dealt with conflict, and see if you can relate to the reference.

And finally, if you think you’ve found your team, give them a try first on a short-term engagement to ensure your personalities mesh well, before you begin swimming in the deep end with your new venture.

Hopefully this has given you something to think about and to help in your decision. Remember, building a software product should be a fun and rewarding exercise!

Categories: Blog