May 29, 2017
Ah, the age-old question that eludes anyone who wants to build custom software: How long is this going to take and what will it cost me?
I've been on the receiving end of this question numerous times. And until now, I always butchered the answer. Because in order to properly assess cost when we're building software, it's inadequate to assess the cost of building the software you think your business needs. Instead, a great consultant will analyze your business's unique situation and recommend a path resulting in business outcomes that don't strain your budget and get you to market faster.
Ask yourself: What is the value you hope to deliver to your users? Can you deliver a small part of that value with less effort than you’re envisioning presently, and get it to market faster? Are you operating with invalid assumptions about how your users will behave and what they'll expect?
Imagine you go to a software vendor and tell them "I want to build a car!" They give you a specification for building a car and tell you it'll cost $50,000. You cringe at the price, but go forward with it, because you need to build the car.
A great consultant will ask you why you want to build a car. "Because I want to get across town!" you'll say. And then they'll ask you if a bicycle for $500 will get the job done.
When vetting a consultant to take on your MVP project, it's critical to ensure they possess both the hard skills required to build a working application and the experience to know when what you’re asking them to build isn’t in your best interest.
You're trying to find a consultant who will find the simplest solution to your problem, as opposed to building what you tell them. Building the thing is the easy part. The hard part is defining the thing to build that produces the outcome you desire at the lowest cost.
Rather than building a wireframe specification and handing it to a developer to implement as you've specified, you'd be better off to seek a consultant who can unpack your business, analyze its core needs in the context of technology, and then deliver to you working software week after week.
If you're non-technical, you're probably not in a place to understand the technical consequences of what you want to build. When your ideas are placed under that scrutiny, you might change course because there's a more expedient way you didn't see before.