If you are looking for a custom software company to build a web, mobile or desktop application, you may find these Seven Deadly Sins invaluable.
Deadly Sin #1: Basing your decision primarily on price
There’s a reason this is the first deadly sin. It’s committed more than all the other deadly sins combined. People have a tendency to think that all developers are the same, so cost becomes the major determinant in who they hire. It’s a big mistake, and I’ve seen people make this mistake repeatedly.
Hiring the wrong company starts a vicious cycle. First, when you hire the wrong company, you almost always commit one or more other deadly sins. For example, maybe you also pay too much in advance. Or you don’t set realistic milestones. And once you’ve paid out enough money, you sort of get stuck. Welcome to software hell. It’s almost like a bad marriage. You start rationalizing that staying is better than leaving, even though your spouse is hitting you. It is this sort of victim thinking that keeps you with a bad software development company far longer than you should.
So how do you avoid this deadly sin? For starters, develop Sete pecados Capitais a checklist to rate the companies you are considering, based on factors other than cost. Sure, you want to check references, review similar projects, etc. Those are obvious items. Here are some you may not have thought of:
- Ask them how you are going to monitor their progress of your project?
- Ask them if they use Subversion (or any other repository)? All reputable developers know what this is.
- Ask them about Continuous Integration, and which tool they use to manage their builds?
- Verify the exact coding standards they’ll be using when creating and documenting your code.
I have interviewed many developers over the years and I am shocked how many get all 4 of these wrong. I give you many more questions in our free downloads section.
Deadly Sin #2: Paying too much in advance
If you committed sin #1, I can just about guarantee that you’ve committed this one too. Understand that I am not just talking about the initial retainer. You want to pay for progress you can see and verify. You need to avoid the situation where the developer is stuck with a lot of work, and little or no future revenue to look forward to. But what about the money you already paid them? It’s gone. It was used to finish another project before yours that also turned into a disaster.
Structure the payment schedule around deliverables, or milestones. In other words, pay for results. It is critical that you understand how much of the project has been completed, and then make payments corresponding to that amount.