RFP Should Mean Request for Partner

At Integrity, we get several Request for Proposals (RFP) per week to build various web applications and systems.  Because a thoughtful response is very time consuming, we simply do not respond to those looking to collect pricing.

Besides - that's not how great software is built.

Instead, we respond to organizations looking for the best partner to deliver the very best outcomes for their project. Partner first, project second.

That is a different process, and one we happily support.

The Process

Building a complex custom web application comes with steep risks and the rewards. Finding the right partner to guide you from the very beginning is the most critical decision you will make in the engagement.

Finding a Partner

After a few decades of building web applications, here is our checklist to find the best partner to succeed with your project.

1. Are they currently doing projects like yours?
2. Anyone can claim to be able to build your application, but are they building similar systems now? You want a partner to leverage recent experience to benefit your project. If you wish to build something that hasn't been done before, look for examples of equally complex (but different) systems.
3. What is the company’s focus?
4. Some agencies think of web engineering as a side service to offer in between direct mail and TV advertising.  If this is not all you do, you will not do it well. Are they a consultancy or staffing firm?
5. This is an important distinction: you are looking to hire a company that will build your software, not assemble a random group of strangers for six months to “see if they can build something.” To end with a great product, engage an experienced product team who can repeatedly launch successful web applications.
6. Are they full-time employees or contractors?
7. A loose collection of freelancers and contractors is profitable for an agency, but terrible for end work product. World-class applications are not built as a side project. This must be your dedicated craft.
8. Visit their office
9. Online, it's easy to look bigger than you are. Insist on visiting their office and see for yourself. Does their marketing match their reality?
10. Shake their hands
11. Who “exactly” would be working on this project? Remember, it's not the office, owners or account managers that will build your system - it's the team. You should be interviewing the actual people who will be doing the work. Are they experienced, professional, nice, knowledgable? Would you want to work with them for months at a time? If no, walk away.
12. Do I have the attention of the leadership?
13. Every web application is a serious undertaking that requires engagement at the highest level. If you find you are only speaking to a sales representative and a few mid level managers, that tells you volumes about how important your program is to the organization. The owners should be engaged early, interviewing you while you interview them to ensure everyone agrees it’s a great fit and should be pursued.
14. Are they local?
15. Though half of our clients are not local, we advocate engaging local firms whenever possible. Video conferencing is ok, but nothing is better than sitting next to your software partner during pivotal team decisions.
16. How many employees do they have?
17. Do they have enough employees to do the job? What if one quits mid project? Find their company on LinkedIn and look at their employee list. How many employees do they “really” have? How experienced? How many engineers? Etc. LinkedIn is a great way to separate spin from reality.
18. Who is their biggest client and what % of their revenue does that represent?
19. Most agencies exist to serve one anchor client that represents 90%+ of their total revenue. This means your project will immediately lose resources when the anchor client raises their hand. Ideally, a firm won't have more than 35% client concentration so your project can remain a priority. If near the 60% range, just accept you are filler work and will be treated as such.
20. Do they have a technology bias?
21. Many firms have one technology proficiency or resell a specific technology. Not surprisingly, whatever business issue you have will magically require that single skillset and platform. Finding a company large enough to be technology agnostic is ideal to design an approach leveraging the most appropriate languages, platforms and tools for your team and project.
22. Do I feel comfortable sharing key project details?
23. If you don't feel comfortable sharing your budget or timeline constraints, walk away. Success will require transparency across the entire team and you should trust your instincts if you are holding your cards.
24. What is their rate schedule?
25. What do they charge per resource type? Scope is determined by you and rate is determined by the agency. The intersection of the two will be your cost. I would caution you about firms who half the rate but claim they need four times the hours (doubling the actual total cost under the guise of a discount), but if you did the above due diligence, those shady firms would already have been disqualified.

Understanding Requirements

• Timeline
• Is there a hard date that must be hit? As a firm accustomed to working in regulated industries, we understand some dates are untouchable – that means all other things can be flexed. Perhaps we launch with fewer features or use a pre-existing tool to get us further faster.
• Budget
• Budgets are a reality in every organization. Being transparent and honest about your budget allocation helps influence the technical approach. If a budget is fixed, all other things can be flexed. Timelines, scope and technical approach will be adjusted to ensure the budget is protected.
• Scope
• What is the most simple thing we can create together that addresses our users core issues? Let’s launch that, measure user response and grow the system in an iterative approach based on qualitative and quantitative data. The smaller the system, the easier for users to adopt and product owners to support. However, if feature expectations are fixed, then timelines and budgets can flex to ensure that specific feature set is tested and deployed.

What if timelines, budgets and feature set expectations are all fixed? Then your project is very high risk and success may not be possible. Your partner will be able to guide you on next steps once a Discovery and Definition is complete.

Getting Started

Once you found your partner, it's time to turn your goals and objectives into something that can be realized. Relative to your project requirements, a detailed “cross team” project plan is created in sufficient detail to define the solution, detail the approach, assign roles and responsibilities, and agree upon timeline and cost estimates.

Now, you are ready to begin.

Interested in submitting a "Request for Partner" to the best web app developers in St. Louis? Submit your inquiry through our online contact form today!

‍