Businesscode takeovercustom software developmentfrontend developmentmobile appsstart upweb development
Tips for Finding Your Software Development Match
By Stuart Smith | April 30, 2020 |
The key to a successful project is finding your software development match. Starting a relationship with a software development company can be as tricky as starting a personal relationship. It’s not easy to get to know someone before you commit to a relationship. You ask a lot of questions on the first date, to get to know the person before you get too involved. The same is true if you are thinking of starting a software development project with a company. It’s best to ask a lot of questions before you commit to a relationship.
Obviously, you can’t grill someone the first time you meet if you expect the relationship to go anywhere. But when evaluating a software development company, you have every right to try to find out everything you can about that company. You want to understand how they do business prior to committing to a relationship. Companies expect that you are evaluating multiple organizations when searching for a development partner.
When it comes time to compare software development firms, here are a few things to consider while dating to help you find the best match.
When searching for a software developer you may come across a firm that is willing to take an equity stake in your project in exchange for a discount or free development hours. This can be attractive if you are trying hard to find funding for your project. You would want to consider this option carefully though. If your developer takes a stake in your project, this will typically mean that they will own a portion of the code. Therefore, they may not grant you complete ownership of that code. Ever. What happens if you want to take the development of the project in-house? What if you don’t get on well with that developer and want to find another firm? Will they hold your code hostage?
Owning your code and having access to it is critical. As long as you stay current in your payments, you should always have access and control of your code. The code should be held in a repository that you have access to, or at least held in escrow and updated regularly. Your code is all you have to show for all the money you spend. It is your only equity and you don’t want it out of your control.
Make sure that you have access and control of your source code. There is a big difference between source code and compiled code. You need source code to continue to develop your application, you can’t un-compile code to get back to the source.
So, when evaluating a software development firm be sure to understand who owns the code and when you will be granted access. Sometimes your agreement will grant you access to the code after a specific payment milestone. This is pretty typical, as the developer has to have some assurance that you will pay for their work prior to granting access.
You should also ask for control of your staging and production environments once an application is published and in the hands of the end-users. These environments should be set up under hosting accounts in your (or your company’s) name. You should have the admin credentials and be able to control these environments.
It’s important to understand the level of transparency that a development organization can provide into the work that is being done on your behalf. How does the organization track the time spent on your project and will you have visibility into this?
A good development organization should be able to provide detailed reports with a breakdown of hours at multiple levels. For example, you might be interested in a break down on hours used by the various departments within a project, i.e.: project management, technical planning, technical management, development resources, QA resources, Design, UX/UI, etc. It also can be useful to see a breakdown by application architecture, i.e.: mobile, web frontend, server, database, API, etc. While a breakdown by specific tasks can be a lot to digest, it can also shed light on areas of functionality that might be consuming more development resources. Will the company grant you access to internal development/project management tools used to track time associated with individual tasks or development resources?
Transparency comes with good communication. You should understand how and with whom you will be communicating during your project. Is your primary point of contact in the same time zone? Do you speak the same language? Do they communicate clearly? Will you communicate in person (always best when possible, especially during the first part of the wireframe/design process), via phone, video chat, email, Skype, Slack? How frequently will you meet? These are all things to consider when evaluating a development organization.
If a development organization has built a project similar to the one you are considering, you can benefit from their experience and lessons learned. While the development organization may not have built something exactly the same, they may have experience building something within your industry or something that relates well to your application.
Check out the development company’s portfolio of projects and see if anything relates to what you are trying to develop. Ask for references for projects similar that you might speak with if available. Check the company out on 3rd party review sites, like Clutch.co, to see how they have been reviewed and if there are any similar projects reviewed.
Post-Release Support & Ongoing Costs
You should also understand how an organization can support you after your project is complete. What sort of support agreements do they provide? Is there any warranty period for bugs post-release? Will the same developers be reserved to work on your project once launched? What process will be used if you wish to continue to enhance your application after the initial release?
You should also understand if any services or third-party libraries would be used when building your application. Services and libraries can have recurring costs associated with them that would contribute to ongoing costs to maintain the application.
It’s important to understand the amount of resources a development organization can provide and how much of their available bandwidth your project will consume. When will they be able to start your project? Do they have resources in reserve if you want to scale up?
Organizations with more development resources often have a bit more overhead. A larger organization requires more processes to manage and communicate. However, a larger organization may be able to dedicate more resources to your project to get it done faster. They may have more bandwidth to provide good service to multiple clients.
Smaller development organizations can be more efficient and cost-effective. This is because managing the organization requires less overhead. However, they may not be able to scale to meet the growing needs of a successful application. Also, because they have less bandwidth, they may not have resources in reserve to start a project right away or finish a project quickly. Smaller organizations may not be able to focus on your project if their resources are spread thin across multiple clients. I discussed some details of the differences between freelancers, smaller companies, and larger companies in a previous article, the Wild West of Software Development Quotes.
Where are the organization’s resources located? Doing development remotely is very common with good developers available all over the globe. It’s nice to know where the development resources working on your project will be located. More importantly, you should know whether the company contracts its developers or if they are actual employees.
It is hard to judge a company by where its resources are located as some areas have a bad reputation that might not really be deserved. There are good developers everywhere. However, some areas offer a better pool of development resources to pull from due to better educational systems related to technology in that area.
Project Management and UX/UI and Design location are far more important than the location of development resources. You don’t typically need to communicate directly with your developers (unless you are very technical). But you will need to communicate with your Project Manager and designers. Having them local or in a location with a similar time zone can make for better communications.
Of course, the basic information about the company you plan to partner with should be researched.
How long have they been in business? If they have been around a while it shows experience and stability.
How long have they been doing development for your type of application? The more experience the better.
The number of employees? Indicates possible bandwidth.
What sort of businesses do they typically work with? Do they have a niche or vertical that are more successful?
Ratio of employees to contractors?
Average employee tenure? It can indicate stability.
Do they resell application platforms? Could indicate bias to these platforms.
What is their preferred development methodology?
What technology stacks are they proficient in? It can give an indication if they are using current techniques.
Can they provide a bio for the key resources that will work on your project?
Like any relationship, in the end, trust is key. You must get a good feeling that the company you are partnering with fully understands your project. You must believe the company is capable of delivering a quality product at the cost they are quoting. The company should be able to clearly explain terms, technology, or any aspect of your project so that you can understand what you are jumping into.
You should feel comfortable and look forward to working with the company as a long-term partner. If your project is successful you will probably want to continue to enhance and improve it for the long term. You want to get to know the company as best you can during the dating phase in order to maximize your chances of a successful long-term relationship.
Stuart has been working as a technology professional for about 30 years. He got his start working in systems operations/systems management and then moved on to software development. He has a diverse history with technology working with software applications and systems ranging from avionics, web applications, disaster recovery, license plate recognition, content management, and systems monitoring.