By Mario Peshev, CEO of DevriX and Rush, angel investor and business advisor for SMEs who has scaled billions of impressions and millions in GMV.
While requests for proposals (RFPs) have been the norm for soliciting bids in various industries like road construction, government projects and military contracts for the past three decades, the unique challenges and dynamic nature of the web development field have prompted some agencies, my own included, to rethink their approach.
Over the past 24 years in building websites (and scaling multiple agencies and product startups), I have fully embraced the observations of Heraclitus, a Greek philosopher known for preaching that “the only constant in life is change.”
Why RFPs Can Be Flawed
When crafting high-quality digital solutions, I find that one-size-fits-all estimates from RFPs often fall short. Any budget I would throw in for ramping up a project “from zero to hero” is a total guess estimate at best. From design and technology to content creation and growth strategies, there are numerous interrelated elements that contribute to a project’s success. RFPs can fail to capture this complexity, which leads to inaccurate estimations that can derail projects down the line. What works as a prototype (proof of concept) wouldn’t scale to 20,000 monthly users, let alone millions. In my experience, professional bids cost 50 times to 1,000 times what a minimum viable product can serve. And therein lies the difference between scoping out and the so-called “race to the bottom.”
I believe the RFP process itself has inherent flaws as well that can impact project success and estimates. From my perspective, RFPs make sense at scale, with enterprise-grade contracts worth hundreds of millions or more, where due diligence is commonly covered (paid for) and months are taken to narrow down the initial requirements.
1. Race to the bottom: In my experience, RFPs can lead to a bidding war focused on low prices. This could compromise the quality of the delivered solution and lead to cutting corners. Bidding competition can also result in exaggerated claims and false promises to win projects.
2. Limited discovery time: The limited time frame for submitting proposals can hinder a thorough discovery process to fully understand project requirements.
3. Preselected candidates: RFPs may be issued to fulfill formalities when a vendor is already preselected.
4. Limited access: I find that access to critical project components and systems is often restricted, which can hinder proper planning and execution.
5. Varying levels of detail: The level of detail in RFPs can vary and lead to misaligned expectations and scope changes. Lack of direct interaction during the proposal phase can also result in misunderstandings and missed opportunities for clarification.
6. Waterfall methodology: The traditional waterfall methodology used in RFPs can lead to scope creep, budget overruns and project delays.
7. Third-party dependencies: Delays caused by third-party dependencies can impact project timelines and outcomes.
8. Budget ballparks: Not specifying a budget range can lead to unrealistic expectations and difficulties in planning.
9. Interpretation and negotiation: The collaboration process following proposal selection involves negotiations and subjective interpretations of scope.
Platforms Don’t Stay The Same
Web platforms evolve over time. What starts as a minimum viable product (MVP) often grows and transforms as user demands change. Scaling a platform requires addressing issues of performance, security and stability. This evolution goes beyond simple plugins and optimizations and often demands custom solutions.
Platform-wise, that evolution goes through different stages, and what an MVP build would carry over won’t get you far. At scale, performance, security and stability look different. This highlights the dynamic nature of development projects and shows that fixed RFP-based estimates don’t always account for future scalability needs.
The Retainer Model As An Alternative
Some agencies are embracing alternative approaches. One such approach is switching to a retainer model, where agencies provide ongoing support and development services rather than one-off project estimates.
I coined the “WordPress retainer” term back in 2015, and after nine years on retainers with some of our accounts here, in good and bad times of fast growth, pandemics and recessions, it’s evident that development is an ongoing venture, not a one-off job. From my perspective, a retainer model acknowledges the fluid nature of web development and offers continuous iteration based on user feedback, A/B testing and evolving market trends.
Having mentored dozens of agencies through their transition to retainer solutions, here are the main takeaways you want to start with:
1. Perform a gradual transition to retainer plans.
Start with one or two existing clients. Focus on current projects in the works or recently completed solutions. Convey the benefits of the model. I often refer to the real world; cars and houses need maintenance; so do the services you’re providing.
2. Work toward a road map.
While retainer plans are flexible, you want to set clear milestones in a true agile fashion. Execution details may vary, but output and launch dates should be aligned.
3. Assess your team’s availability.
Retainers include a variety of services you offer internally. Ensure you have enough capacity across different teams, or communicate areas with limited resources and longer response times (such as business consulting from leadership or other strategic staff members.)
In my view, as the digital landscape continues to evolve, the shortcomings of RFPs in the web development industry become increasingly apparent. Recognizing the complexity, scalability and ongoing nature of development projects, agencies can consider alternative models.
