Why We’ll Never Win the Best Software Development Proposal Contest
A proposal can be a lot of things, but in the software industry it primarily refers to a detailed plan for development with a financial expectation. When looking to hire a development team, you’re on the hunt for the best software development proposal. How will you know when you’ve found the right one?
Managing Client Expectations
Living on the front lines of new business for Revelry over the past 2 years has given me a lot of perspective about client expectations. And it seems that in each conversation with a potential customer, it is most often expected that we will prepare a proposal.
Even though the folks who have experience hiring software designers will readily acknowledge that the development of software is a fluid process, they still ask for a detailed plan of what we’re going to do and how much it will cost.
Yes, they readily admit that they don’t expect every last detail in the proposal.
And true, they know that I won’t be able to tell them what the cost will be.
It seems that nevertheless, they’re looking for a fixed bid proposal. There are plenty of software development firms willing to provide proposals, and appearing to be willing to build the requested features for the lowest amount of money.
How the Software Development Industry Bills for Projects
Revelry is set up as your typical consultancy and we bill by the hour. Many of our competitors do not operate this way and instead provide clients with fixed bid proposals. Fixed bid proposals are my nemesis, and let me tell you why.
After a few conversations with someone who’s looking to build a software solution, I find myself having this conversation:
- Why I cannot tell you exactly how much time and money your application will cost.
- That I can’t tell you exactly how we’ll get there.
Why can’t I just guess and give you these answers?
- I don’t have enough information from you at this juncture.
- I’d be doing you a disservice to presume to know what we will face as we develop your solution.
But, it’s very likely that a competitor has provided a detailed roadmap with an exact price tag even though they have no more information than I do. Let me share some trade secrets with you:
- If you received a fixed bid from someone else, they simply gave you their best guess as well.
- The bid will either be over, and create quite a profit for the development team, or it will be far under, and shortcuts will need to be taken to make up for a potential bloodbath.
The truth is that no matter how much time you invest in research or diligence, you still can’t predict the future.
What Agile Development Means at Revelry
I value your time and I hope to earn your business. So, at this point, I have to decide whether to cave and create a fixed bid proposal, part as friends and hope to work together on the next project, or help you understand why that proposal is not really a helpful piece of paper.
Revelry is an agile development company working by the hour. We do Design Sprints as one of our core offerings, and we encourage any new product build to start with a 2 week design sprint that we charge between $12,000 – $16,000 for. We do a ton of work within those 2 weeks to prepare for development, and a core deliverable is the development roadmap.
We believe that participating in a design sprint and creating a development roadmap is the best way to get to a product roadmap. And while the development roadmap is still an estimate – and it’s still subject to change – we’ve put valuable research and diligence into the product at this point and we believe this is more valuable than any fixed bid proposal you could get after a handful of conversations.
Our timelines tend to be longer and our cost estimates can be many multiples more than the estimate this client already received from our competitor. This distinct difference in approach is completely by design.
The truth is that even after each Design Sprint, we still can’t predict the future. We have a lot of experience building companies and products, but no two are the same. Another project may have had the same list of features, but this doesn’t mean we’re repeating what we did in that other project.
We design and build everything based on a business case, on user research we conducted, and on assumptions that we spent the time to validate or disprove. On top of all that, we still allow ourselves to stay agile. We insist on stepping back and questioning and rethinking EVERYTHING. Along the way we will learn new things, new ideas will come to light, and someone will have a profound light bulb moment.
We Don’t Expect to Win the Best Software Development Proposal Contest.
The sticker shock that usually accompanies the review of our estimate has lost us more deals than it has won us. But we’re proud to say with confidence that we’ll never be the company that over promises and under delivers.
We’d rather prepare you for the worst, and gain a customer for life when we finish early and under budget. The customers that hire us know they can trust us and continue to hire us again and again.
Our past and former clients will tell you to trust in our process, and I’ll spend endless time and energy trying to earn that trust. But until you have that firsthand experience working with us, we’re asking you to take a leap of faith.
Everyone agrees that you get what you pay for in this world. If someone is proposing to do a job in half the time for half the cost, there is a disconnect happening, or worse. I’m reminded of this rant alleging a staggering amount of technical debt that adds up when teams overpromise while appearing to deliver productivity.
When clients tell me they are “shopping around” for a development firm to build their product and gathering various proposals, I always tell them the same thing – that if you’re basing the decision of who to work with on who sends you the best proposal, you’re better off not going any further with Revelry. We’d rather prepare you for the worst, and gain a customer for life when we finish early and under budget.
We’ll never win the best proposal contest.