If you haven't been following along, this is one in a series of articles about saying no.
- I say no with email templates
- I say no to crazy requestions
- I say no to the request, not the person
- I say no to rev share deals
- I say no to the idea that my target market is everyone
- I say no to discounts
- I say no, you don't have to learn to code
And now…saying no to RFPs.
The story is the same each time.
You decided you wanted help building a website. So you went out looking for a provider who could meet your needs.
You wrote up these needs and shaped it into a request for proposals (RFP).
That was likely your first mistake.
It's not the point of this article, but I can't step into my point without highlighting that you're hurting yourself before you even start.
You see, if you write up your needs as an RFP, you're knocking out a bunch of viable candidates who won't respond to RFPs. Less respondents is bad for you, because that perfect fit might be someone you never interacted with – all because of the RFP.
Additionally, the RFP invites companies that specialize in responding to them, and those may not make the best development shops. But they will certainly invite more expensive shops – which may (or may not) fit your budget.
But let's move on. Like I said, that wasn't the point of this particular message I had for you.
You send it out and you collect a series of bids. Like I said earlier, you also didn't get a series of bids (the non-bids). You review them and what do you do?
I know you won't always admit to this, but in the quietness of the space you and I have here on the internet, can we agree that sometimes you're more inclined (at least) to select the lowest bidder.
That was your second mistake.
The lowest bidder among people who specialize in writing words (text that people read in RFP responses) doesn't, in any way, equal the highest performer among those who specialize in writing code.
So you pick your development person/team/organization and you get started. They're great about giving you updates (after all, they're good with words). But they're missing deadlines and their code isn't great (you didn't pick the one optimized for high performance code).
You get frustrated and fire them. No surprise. We knew, didn't we, that this was a real possibility. Right? So then you get ready to hire their replacement. The fixer. The cleaner. The one who will make ALL THINGS BETTER.
And that's when you do it.
You commit your third mistake.
You send out a new bid, don't you? As if the problem in the first place was just poor selection. But it's not. It's poor process. It's the whole thing. It's gotta stop. But you're so invested in the process that you forget to evaluate it.
You already know I say no a lot. Well, no surprise. I say no to RFPs.
My message to small and medium businesses
If you're looking to build a website, I want you to do almost everything above in the exact opposite way.
1. Start by finding a developer you can trust. Do it by building relationships. Invite a few to lunch. Interact with them. See if you like their ability to communicate. Do they make complex things simple?
2. Share with them your context and ask them to tell you how they'd approach the project. Don't create a list first. You're not an expert in web systems. They are. So let them design the steps and stages instead.
3. Never pick the cheapest bid. If you're tight on funds, learn to live with staged happiness. By that I mean, learn to break up your project into several and fund only those which you can afford to. Then enjoy them. As you have more funds, you can expand on the overall plan. And your happiness will grow with time as you fulfill more and more of your overall solution.
Your story doesn't have to be the same story as everyone else's. You could be an original. When everyone else is frustrated with their developer, you can declare your happiness with yours. Wouldn't that feel refreshing?
After all, who doesn't want to be the only one who knows how to work with software engineers? It's like it's own super power.