In my tenure of running software projects, I’ve seen many budgets blow up. This is a guide to fix your overbudget projects based on how I fixed mine.
There is a famous (infamous) line in the software development world that goes something like this, “I’ll know it when I see it.” There is obviously truth behind this sentiment, but operating with such a motto has ramifications. These words most often come up during the design (UX/UI) phase of projects, because, unlike true feature development, design can feel...squishy. “Do you like the feel of this UI?” VERSUS “Does the form submit (yes/no)?”
When I was running software development teams back in my early days at Bluetent, I used to allow for flexibility (and subsequent budget risk) because I thought there was no other way to do product design. I thought I had to wait until we landed on something everyone “liked." Now, after seeing how that generated too many budget mishaps, I do things differently.
Let me offer a thought experiment that will help show how this isn’t the way to design products. Imagine using the, “I’ll know it when I see it” with a building contractor. If the contractor doesn’t get it quite right and puts the bathroom where the kitchen should be, it’s going to be expensive to rebuild. Redoing cement work can be hard, and so can redoing design work.
I understand this example isn’t quite apples to apples, but it’s helpful in illustrating the point that redoing work is expensive. It’s sometimes necessary, but more often than not it is not. We should do our best to avoid it. In order to do so, the first step is to create clear design guidelines for what you need. Here are some examples:
I'm not trying to say you should be able to pay for a full-service agency that's charging $250 / hr+. After all, one of the reasons I started my freelance business was to give business owners an option to work with custom software development teams without paying agency rates. Still, the reality is you that you need a decent-sized budget; otherwise, you’ll get halfway through something and the team will either cut a bunch of corners or lose their momentum because the budget is drying up. I currently turn a lot of projects down because they don’t have the budget necessary to reach critical momentum on the path to MVP.
Agencies can be cagey about how much this stuff costs, so I’ve put together a list below that’s a rough** outline of what you should expect to pay with a freelance team. For agency rates, expect 2x / 3x what is below.
When I first started hiring developers, I used to look for ones that were agreeable and had a polished pitch. When I hire developers now, I look for the ones who have strong opinions, even to the point of being grumpy. You want a team that is confident enough to stand up and tell you if what you are doing could harm the product build. And, it follows that developers who care enough about their craft to have a strong opinion are going to have invested the time to be competent, as well. If this doesn't make sense, think about a doctor. Do you want a doctor who doesn't have a strong opinion on how to treat a disease? Do you only want the doctor who has a good bedside manner? Here are some examples of how this might play out.
Without preamble, just know that momentum is your friend. For projects with slow feedback cycles, I typically predict 30% more for budget. I’d much rather have a client who is pushy about deadlines, due dates, etc. than one who isn’t. Software development teams thrive on pace.