i wanted to share a little snippet from a client that landed in my inbox today:
"after six months with our fancy engineering and design shops, I decided to cut them loose and build my own team through a trusted network of independent consultants. ive worked with them all in the past and just think we can build faster, with higher quality, and for less money. These fancy shops just had too much overhead. like we were paying for a business relationship manager, who essentially picked up the phone to give me updates. uh..."
we at dojo4 hear this over, and over, and over. and over.
so many times we've talked with clients, given them a solid quote, and seen them get wooed by talk of fancy processes, doubling up on developers, or how test-driven scala makes unicorns poop rainbows out of which mobile apps sprout. a year later they always come back. despite a bid of 70-100k they have always spent 300k. this is a magic number in software and yes, it always at least 300k. in return these clients have pile of software poop, not great products.
it's sad that this is normal in our industry: people are either drawn to the lowball bids because they don't care about quality, or they are drawn to the the highball bids that decorate solid software with massive overhead on invoices because 'it has to be better if i pay more, right?' the middle path bids--the ones that can produce quality software for reasonable amounts of money--are simply ignored. this is a common consumer behavior in many markets and, although unfortunate in those domains, it's not fatal. in software this kind of cost/benefit analysis is deadly to the consumer because:
software either works, or it doesn't. going cheap makes you risk buying a pile of nothing.
process doesn't make better software. going expensive funds many things, but making better software isn't one of them.
in case #1 the consumer pays money and has nothing. in the second case the consumer pays way too much for what they needed and spends too long getting there.
in engineering, constraints are always a good thing.
constraints on money are no different, they are a good thing too. they let people focus on what matters and cut what doesn't. too much money wastes time: it let's people sit around in meetings debating whether or not their pet feature should be in or out. too much money let's engineers build auxiliary code that adds nothing to the business value and detracts from the codebase's agility. the way to know the right price is simply to aim for a price that is:
"the least amount possible, but no less."
if you have a good idea, enough great engineers, and just enough money you will hit your target sooner than people that have more of all three.
p.s. if anyone would like direct evidence of this please contact me. i'm happy to connect you with entrepreneurs that can attest personally to this syndrome--and how dojo4 has bailed them out. as you can imagine, no one is proud of having gone through this experience and so i've left the victims un-named ;-)
p.s.s. i got some great comments about this post from facebook:
"very insightful. i concur 100%. one other thing to note...even if you do all these things and have built the software properly, things still have a high probability to not work out sadly. market fit, timing, macro trends, micro trends can get in the way. if you have bad software and your business is built around software you have 0 chance." - https://twitter.com/kcbigring
Tweet