How do I find the right team fit for my web app project?

Getting Started

So, you are ready to start a web app project. You have run through a discovery session, identified your user personas, setup your user stories and user flows, and have a list of features you would like to implement. Now you need to find a team to handle the actual project implementation. Who do you go with? How do you know if they will be a good fit? What questions do you even ask them?

Do you work with a single contract developer? Assemble an internal team? Hire an agency? You are not alone with these questions. It is difficult to decide what team to work with when starting a web app project. A common decision factor that comes into play is“well which team can delivery with the lowest budget.” Budget should not be the sole factor when deciding which person or team to work with. As with all things in life - you get what you pay for.

There are many paths you can take and questions you can ask when finding the right team fit for your projects. This is by no means an exhaustive list. I have outlined a few common questions I have been asked when starting a project. These are also questions I tend to ask a client when getting started to understand what their level of experience is with web apps. For the sake of clarity I will refer to you and your team as “you” and the person or team you are looking to hire as “contractor.”

Have they worked on this type of project before?

If a contractor has worked on your type of project before, they will be able to identify issues before they come up, iterate quickly and get the job done quicker than a contractor that has not worked on your type of project. It all comes down to experience. Different industries come with their own sets of challenges and problems. By having a list of known unknowns, the contractor you are working with can start identifying what they can do to bring more clarity to the project. The contractor most likely will have a roadmap of what they need to get started at each phase, where they currently are in the journey, and what to expect next.

Have they worked on a similar type of project?

This is a great follow up question to question #1. If you have a pretty custom project - chances are no contractor will have done exactly what you are trying to do. However, they may have done something very similar. They can translate the same type of skills from project A to project B. Most web app projects I work on have a number of similar components. Authentication, data storage and retrieval, and permissions based on users are a few that are consistent across all SaaS and internal business software that I build.

If a contractor has not worked on your type of project, or any project that is similar that odes not mean they are a bad fit. There are just additional considerations you need to take. Things will take longer naturally because the contractor will need to discover your field, and the problems that come along with your project. There will need to be more communication than normal to understand all the facts, clarify what you are used to seeing as common knowledge, and identify exactly what you are looking to get done.

What is their project process?

A contractor should have the project steps laid out for you before you start work. If a contractor does not have a solid roadmap - this raises a red flag. This either means they have not completed a project of this type or a similar project - they do not know what to expect, or that the contractor is a bit un organized internally. I would consider this question to be an eliminator. It really does make a big difference whether or not a contractor knows what steps they will take rather than figuring it out on the fly. To be clear, I am not saying they need to know x step for y authentication platform - but they do need to know things like, mapping out a database schema, setting up a database, adding and securing users - whatever the common elements are for your project. If you are unsure of whether the proposed roadmap falls into the norm, get another pair of eyes on the work.

What kind of timelines are you looking at for projects of similar size and scope?

You need to know what kind of timeline you are looking at. Contractors operate at different speeds - thats a fact. Many factors influence operational speed. Taking longer or shorter is not a good or bad thing - it is what it is. I have learned to double the time I think a project will take. I either end up delivering on time, or delivering early. A mistake I see other contractors making often is setting very aggressive delivery schedules to try to meet a client deadline. This then leads to longer timelines, where the contractor is now burning through cash they did not plan for. Inevitably this leads to frustrating.

Who runs the show?

Have a single point of contact for the project - this makes a world of difference. Pro tip - assign a single point of contact on your end to communicate with the contractor. The two contacts can keep in sync and keep everyone on their own side up to date daily without anyone having to keep track of multiple inputs and changers. The only exception to this rule is when it comes to posting. When a project team posts a deliverable - whether it be a final design, or an iteration of a project - its important to have all stakeholders to review the information. Again, all info goes into a document or to the point of contact, which then gets shared to project point of contact, which then is shared with their team.

How do you account for the bus factor?

This one tends to rub some people the wrong way - but its 100% necessary. This is business, you have to plan for this. If you are unfamiliar with the bus factor here it is in a nutshell. What would happen if X person would get hit by a bus? It forces both teams to plan for worst case scenarios and have backups readily available to keep the project moving. In my case as a single developer - there are a number of scenarios I need to account for. Laptop falling off a bridge, client ghosting, myself literally getting hit by a bus. For each of these I have an action plan: full backups and multiple redundancies of files, billing 100% upfront or 50% upfront and milestone billing, and a trusted point of contact that can transfer all project assets needed to a client as needed.

Summary

Outlined above are six questions that I think are the most important when it comes to vetting a potential team or contractor. They range from project experience to internal procedures. There are many more questions that you can and should ask, but these will get you pointed in the right direction if you need some guidance. If you need a third party perspective, have an outside party join in on the conversation. I often join in on a call with another team as a short consult session to help them ask these types of questions and gauge responses.