Well here we go. You’ve been bit by the creativity bug and come up with an exciting application idea that could be that one missing thing you need to achieve all of your goals and ambitions. You’ve seen a problem (or opportunity) and have concluded that technology can help you respond accordingly. You’ve seen what is on the horizon and decided to bring your digital vision to reality. But wait, you aren’t Mark Zuckerberg? You don’t have a team of keyboard cowboys (and cowgirls) on your payroll and available to be tasked towards building out your new technical innovation? Well then, like most, it’s time for you to consider finding a development firm to partner with in building out your web or mobile project.
In my time running Business Development at FarShore, I’ve seen over one million hours of service delivered across thousands of projects and hundreds of clients. We work with some of the most exciting startups and support them from launch through their eventual exit and engage with some of the largest and most prestigious enterprise companies out there. Even with the differences in business size and scope, or the application of their product to their market, it never ceases to amaze me how broadly reaching best (and worst) practices really are when it comes to getting the most out of a software partner. The reality is though, even for relationships lasting several years and over multiple projects, the biggest factor determining the success (or failure) of a partnership starts during the vetting and selection process.
To be fair the title of this blog is a bit misleading. Depending on the circumstances, “forget” could be replaced any number of words or phrases (such as “aren’t aware of” or “ignore” or “incorrectly prioritize”) that could be applicable here. Nevertheless, I’ve been tasked with offering some insights that, regardless of nomenclature or verbiage, all end at the same place – which is having a happier, more enjoyable and overall more successful partnership with your development team. So, without any further ado, here is a list of things to make sure to consider or evaluate when trying to identify that ideal software partner.
Make sure the firm spends sufficient time planning and documenting
Before anything else can commence, the first step between you and your new technology partner should be a formalized (i.e. separate engagement) deep dive into the functional and technical layout of your application (wireframes, third party integrations, database blueprinting, roadmap features etc.) This is a critical step in the process and gets everyone on the same page quickly and effectively. You can do some of the legwork on your own and there are numerous tools and resources out there to help you get the ball rolling; but this documenting process can and should be curated by your technology partner. Depending on the bid/pricing arrangement, this is likely required too in order to reach a finalized cost or quote estimate. Nevertheless, while most shops will spend time on this, it is up to you (the client) to make sure they invest an appropriate amount of time into this exercise.
During the discovery and vetting process on your end, ask questions about what process the shop utilizes for documenting and scoping. Ask how many meetings occur, who you would be working with and what participation (if any) you and your team has in the process (note: the more formalized and participative the better, generally.) The final deliverable for this phase should be a document outlining all User Interface and User Experience storyboards as well as any 3rd party integration notes, platform selection analysis, server configurations etc (what we at FarShore call a “Functional Specifications Doc”.) Be diligent and be disciplined to make sure you allow for and require an appropriate amount of time to be spent planning and architecting your product.
Evaluating past performance is the best risk mitigation
Without a doubt, past performance is the single best indicator towards whether or not a potential technology partner has the ability to make your technical vision a reality. Has the company you’re evaluating worked with other companies similarly situated to your business? If you are a pre-funded startup, have they worked with many other pre-funded startups? If you’re a billion dollar manufacturing company, have they worked with many others in your space? If you’re objective is to raise money, have they worked with many people (or even participated) in the fundraising process with other clients? If you’re aiming at getting acquired, have they worked with many other companies who have been acquired during or immediately after their engagement? If you are seeking a multi-year engagement, how often is the shop involved with a project past launch?
From a functional standpoint this sentiment is important as well. Interested in building out a shared-economy or “Uber of ____” application? Building a scalable ecommerce solution for fashion or consumer goods? Then make sure the shop has that style or type of work in their portfolio. Now, it is possible that a shop can still deliver on your vision even if they don’t have that specific experience, but again, there is no greater risk mitigation (which is one of your primary goals when evaluating software firms to work with) than looking at comparable performance so you can ensure they are aware of and able to respond to the unique circumstances facing your company.
Realize when making your selection it’s at least partly about the people
Cost, availability, domain experience and all of those other common items that you’ll review as part of the selection process do make up the vast majority of the reason why most people choose one development firm over another. But an often overlooked (maybe even slightly subconscious) reason that you may lean towards Company A over Company B can simply come down to the people involved. Avoiding the superficial here, what I am talking about is a certain affinity or interpersonal connection you can garner with your counterpoints at the firm, and how that connection can be (strategically) relevant towards the overall success of your project.
For all its nuances and intricacies, the process you’re going through is not all that different from hiring a full-time employee. Be sure you do not overlook things like culture fit and attitude… think of it as hiring an internal team member… just in the aggregate. If you appreciate simple and direct communication, then keep an eye open for those traits – if you enjoy more comradery as a part of your interaction, then look for that as well. The point is that these people are going to be in the foxhole with you day in and day out – finding someone who you feel you are aligned with beyond just the X’s and O’s of a project can play a critical role down the road in those moments where you need to push or ask for more from your development partner (not to mention, it will make for a much more enjoyable and fun process.)
Only that which can be measured can be managed
Holding anyone to a standard that they don’t know they are being held to will usually spell disaster in any relationship; this is especially try when it comes to finding or onboarding your technology partner. Establishing a timeline and cost structure for your engagement (both during the initial buildout and after) is critical if you want to manage and have met your own expectations for delivering your product. If you don’t clearly outline, share and then get sign-off on what your expectations are you’ll find yourself constantly disappointed throughout the process (and so will your technology partner.) Development and software building is really a juggling of constant concentric activities and priorities; so tracking the trend of milestone achievement once you have started building can be challenging – but it is critical that as the client/ultimate PM you carve out time during each touch base to discuss where progress is relative to the overall scope of work.
This doesn’t have to be a convoluted or highly technical process; it really just boils down to establish clear expectations around timeline (and not just a total timeline, but milestone-based expectations) and tracking/discussing those milestones as the work continues onward. When an issue or deviation arises, discuss why the milestone or metric was missed and what can be done to make up lost time or avoid it again in the future. The ultimate success or failure of the project resonates with you most of all – so expect adjustments, be fluid, but also require more out of your technology partner in terms of goal-setting and communication around key metrics indicating if your project is on or off track (and to what extent.)
Don’t overlook the supplemental value that your software partner can bring you (inversely, don’t work with partners that cannot add supplemental value)
The reason you are hiring a software firm is to build out or update your new or existing applications. But, the absolute best technology partners are solutions partners first, software partners second. What does that mean? Well it means that a good software partner can be a part of your brain trust for tackling a multitude of challenges or opportunities, not all of which directly or immediately relate to their software services. For startups this could be fundraising, or introductions to potential channel partners. For larger corporations this could be participation in or overseeing a focus group to discuss consumer’s needs before updating a product or offering insight into areas of the technology that the firm isn’t directly or contractually overseeing (CRM, ERP, SEO & SEM, etc.) Just like some of the best full-time and internal team members, the best software firms should have the ability to wear many hats. Both in terms of the scope of services and the tech stacks they support, but also in terms of being able to add value to your organization whenever and however you need them to do so.
If you’re interested in getting more tips about evaluating and selecting your development partner, or any other best practices, feel free to reach out and connect with me or someone on the Business Development team to learn more today!
JC is the President of FarShore, spending most of his time focusing on scaling the US and Global Business Development operations and consulting our partners on how to grow their businesses. Originally from Nashville, TN, JC ran marketing and client services for a Chicago-based tech startup before joining FarShore. Prior to that, he started and ran a successful small business and startup consulting practice, focusing on offering business leaders guidance on everything from business plan writing to fundraising strategies and general strategic planning. He earned an MBA from Pepperdine University with dual concentrations in Entrepreneurial Management and Marketing after previously working in Non-Profit Management.