6 Mistakes to Avoid When Hiring App Developers
Dec. 5, 2020
Hire an app developer with confidence.
Don’t make these mistakes.
Read the following common mistakes, avoid them, and hire the ideal customer.
Not Reviewing Credentials
Not Interviewing Developers
Haste Makes Waste
Not Understanding Fixed and Hourly Contracts
Not Owning Code
Not Knowing About Bugs and Maintenance
You may want to share this blog with your technical expert.
Not Reviewing Credentials
How do you verify credentials? In 2020, university diplomas are becoming less important and a portfolio of past work is becoming more important. In other words, what you do is considered more important than what a university says you can do. Tech giants such as Google, Apple, and IBM don’t even require college degrees anymore.
College degrees are still important, but showing your previous work is more valuable. This is especially true in mobile app development.
So how can you see an app developer’s previous work? The most common places to check are the developers’ website or their LinkedIn profile. If any of their apps are available for download, download the app and test it out. Ask questions such as:
Were there any troubles downloading the app?
Is this app easy to use?
Does this app match the brand of the company?
Can I do what the app wants me to do without confusion?
If you want to know what kind of app someone will make for you, look at the apps they’ve previously made for others.
2. Not Interviewing Developers
Coders are notorious for being anti-social. Sometimes they even lack empathy. The disadvantage of hiring a developer like this is that they won’t attempt to understand you and your goals. That will show (or not show) in the app.
Interview your app developer(s) before hiring. Ask questions like:
How do they interact with me socially?
Do they ask questions?
What types of questions do they ask? Insightful? Thoughtful?
Do they try to understand me and my company goals?
Your interactions with the app developer(s) will show you a glimpse of what working with them will feel like. Look for developers who try to understand your company’s vision and goals. If they understand what you’re trying to accomplish, that will show in their app design.
3. Haste Makes Waste
Simply put, developers who want to start coding as soon as possible will not make an app you like.
That’s because app developers should first try an understand your company’s goals for wanting an app before they start building the app.
For example, let’s say good app developers were being hired to develop an app for a clothing store. They would not only ask about their company’s goals for an app, but also what the company hopes to accomplish in the future. If the company simply wants to know how many times customers visit the app each month, then that would inform how the developers code the back-end of the app. If the company wants to know where they should open a new store, then the developers might code the back-end to count how many purchases each store gets in comparison to the others, or to use customer profiles to map out where regular customers live.
Also, the developers would check in the with the company regularly to make sure the app is being developed according to the specifications of the company. This takes a little bit of extra time, but it assures that the app will be developed just the way the company wants it. If the developer doesn’t check in regularly with the company, then they spend more time later on editing the app.
4. Not Understanding Fixed and Hourly Contracts
Some people favor fixed contracts, and some people favor hourly contracts. Here are the pros and cons.
| Fixed | Hourly |
|---|---|
| Fixed Price | Hourly Price |
| You know exactly what you want in the app | You want to explore what you can put on the app |
| Process is straightforward and not as long | It's a process of discovery and may take longer |
| You order a set list of features | You work with developers to discover what features you want |
| In order to add features, an addendum to the contract is made | In order to add features, you communicate with your developer(s) to add them |
| Set timeline | No set timeline |
Basically, if you know what you want in your app, then a fixed bid contract is most efficient. If you don’t know what you want in an app, then an hourly contract is best.
5. Not Owning Code
There is some code you want to own, and some code you don’t want to own.
What is code?
Code is like the DNA of software. The code is instructions for what the software has to do. Developers write code to design the look and features of your software. On a mobile app, for example, some lines of code may access the smartphone’s camera. Some lines of code may manage the profile settings. Some lines of code may manage ordering or making a purchase.
What code should I own?
Yes, you can actually own lines of code. This is gist of it. If you have something proprietary, such as a unique value proposition, then you may want to own the lines of code that perform that value. An example of this would be patented processes or ideas.
For example, if you hire developers to create an app that analyzes the stock market for you and makes recommendations based on your investment goals, then you may want to own the lines of code that perform that stock market analysis, that way the developer(s) can’t use your code for their own purposes.
However, if you have a feature as simple as creating a profile on your app, then it’s not necessary to own those lines of code because it’s not unique to your company — almost every single app has code to create a profile. So the only code you really want to own is the code that is your company’s “secret sauce.”
If you want to own code after the contract is signed, it may be a long and difficult legal procedure.
6. Not Knowing About Bugs and Maintenance
“What if I have bugs on my app after the contract is finished?” you might ask. Or, “what if I want to change something or need help maintaining the app after the contract is over?” Here is what you need to know about bugs and maintenance.
What are bugs?
Bugs are faults, errors, or flaws in the program. For example, a developer may create an app for you that asks people to input their phone number. After they use the app for the first time and input their phone number, the app may ask for the phone number again on the second time they use the app, then again on the third and fourth time. This is an error in the app, so we call it a bug.
The term “bug” comes from when computers were the size of a whole room and actual insects would get on the paper with the code on it, get squashed inside the computer, and cause a glitch in the program. So developers would have to clean the bug off of the code paper and restart the program. We continue to say “bug” today.
Bugs and Maintenance
When a contract is signed for an app, the developer is responsible for making sure the app is “fully functional” before the contract ends. This means that your customers are using the app without any problems neither on their end nor on the company’s end.
However, there may be a bit of gray area in terms of when the developer is finished fixing all of the bugs. An app may have bugs throughout its whole life, but the majority of bugs can be worked out when it is first developed. If you want the developer(s) to continue fixing bugs after the contract is finished, then that is usually a separate contract — a maintenance contract. Other maintenance tasks that can be included in that contract are adding features, data integration, and user-experience redesign.
Share this blog post