Overlooked Questions That Startups Should Ask Before Hiring a Tech Shop

One editorial disclosure: my job is to make many of the services outlined below available to prospective buyers, but I will attempt to limit or eliminate my own bias for my shop in an effort to provide truly valuable feedback that applies across the board.

I’ve spent the better part of a decade now working with startups in a consultative capacity, culminating to my current post in the software and product development space. And whether it was during my times peddling SaaS products to member-based organizations across North America, or now in my role providing consulting and specialized development support for everything from new ventures to Fortune 500 companies, one thing remains constant and that is people (or more specifically, startups) have a hard time pinpointing all of the criteria they should use when evaluating a potential technical shop to hire. Now to clarify, when I say “shop” what I am really referencing is a corporate entity of more than one employee that offers software development as one of its primary services (versus say a freelancer or entity offering development as a secondary or tertiary service.) The poor results (overages on cost, missed deadlines, lack of buy-in for the venture’s vision) that come from not properly vetting and selecting an ideal technical partner are as costly as they are avoidable; and the situation is further exacerbated particularly when the people are bringing in the tech shop to build their first or early product version. Putting aside the argument or debate on whether hiring an outside team for your initial product build is viable (it is), there are some items to consider before pulling the trigger. Yes, there are some nuances that even seasoned entrepreneurs may not look for/evaluate when considering which team best fits their needs. Below is a list of a few must-ask questions that entrepreneurs should be putting to any potential technical partners BEFORE commissioning them to build their initial products.

- What are my rates for the project and can these rates go up for any reason after the initial product is launched?

This question encapsulates one of the most under-vetted questions in structuring a software development relationship. That is, some shops will quote you one rate for the initial project build, but then for ongoing support/maintenance/updates, that rate magically goes up by a factor of anywhere from 50% to 400%. To clarify, these are the same resources (engineers) who built your website or mobile app, however the honeymoon phase of “get to know ya” pricing isn’t sustainable for these shops. I’ve spoken with so many entrepreneurs who (fortunately for my shop and unfortunately for them) have been shocked to see their bill go up so sharply when it comes to anything requested after the initial (more affordable) first project. Be sure to look at the cost in aggregate over the length of the relationship, not any one project, because I can say with almost absolute certainty you will have updates you want made after the initial rollout

- How are change-orders handled during the project how can I request ongoing support tasks once it has concluded?

This is an item usually covered during the discovery or negotiation stages of meeting with a prospective tech shop; however the depth to which this conversation goes is rarely sufficient. What to pay particular attention to is the communication process for being notified when a change is out of scope (i.e. are billable changes required to get your approval beforehand) as well as how your orders are prioritized into their internal workflow with other client requests (i.e. is it based on a first-come, first-served basis or is it based on priority of individual tasks?) The shop that builds your version 1.0 needs to be available post-build for ongoing support as well as helping transition the workflow to perhaps an internal team once you’ve secured funding. The reality that most shops that don’t have sufficient depth at the position/stack you are working in is that they set their own priority based on who is paying the most — avoid being put in that situation by getting a handle on how they manage ongoing support workflow and change orders during the build itself.

- How is your team structured and where are they located?

Just because you have made the decision to off-site your initial product build doesn’t give you an excuse to not think about how the tech shop you are hiring is structured and how it fits into your own workflow. On the structure side, you can find out how organized (or not) the company is by inquiring about things like recruitment practices, training methods (if any) and also how specific team members on their end are matched up for your project (do they look at experience, comparable project work etc, or is it just who is breathing and available at that moment?). Beyond the structuring of their internal team, also ask how your project team is assembled and who is involved at what point(s). Do they have a project manager? Do they have an account manager? Do they have singular “engineers” who do all front end, back end and design work themselves or do they have specialists responsible for their respective areas of the project. Are these resources dedicated (i.e. only working on your project) or if they are working on other projects, how many in total do they have active? In the transition from the initial build to post-launch support, how are team members assigned to complete those tasks?

Now some quick hitting questions you can sprinkle in for effect:

- How many startups have they worked with?

- How many version 1.0 products have they launched from start to finish?

- How many of those projects are they still actively involved with?

- Ask them to describe an instance where they advised that a client NOT make a significant investment in technology which ultimately reduced the billable services they offered and why they did it.

For most entrepreneurs hiring an outside tech team will be the first big decision they make as far as the new venture is concerned. Most successful startups who go this route don’t look at the shop they hire as just some vendor, but rather as a true partner (or at the very least, their first employee hired) — but well intended entrepreneurs who recognize this still have to find a way to weed out less than viable candidates because the success of that approach is only found when met with the same type of reciprocal intention from the respective tech shop. It’s not reasonable to expect perfection, or even a shop that satisfies (to the degree you may want) all of the questions outlined above, but instinctually you will understand through conversing on these topics whether or not a shop will be an asset or liability towards achieving your vision. So before you hitch your wagon to an outside team’s star, make sure they fit the profile of what you are looking for out of a true technology partner.