How To Pick A Mobile App Developer

There are a myriad of reasons why you may want to build a mobile app. You could be the next billion dollar tech startup, need an enterprise mobile tool, be a hobbyist, etc.

Inexpensive, timely, quality. Pick any two, you can’t have all three in a mobile app developer.

Once you come to terms with which of these three options are most important to you, the next step is to make sure that the mobile app developer you choose will deliver on the two that you pick.

Remember, a mobile app is software that will be used by humans. It is very different than coding a server or backend infrastructure which only machines interact with. In order to build a successful product, you must ensure that your mobile app melds with human behavior to deliver upon your ultimate business objective.

1: Resources are in-house.

You are hiring a mobile app developer because they know how to execute and execute well. The only way they will build a core competency in programming software is if they have resources in-house. Unfortunately, it’s pretty easy for a firm to say, “Of course! All of our mobile app developers are in-house.”

Ask who the specific team members would be on the project. And, also ask to see what past mobile apps they have worked on. You can also ask to talk to the resources and see how their communication skills are.

Some firms will say all their resources are on-shore; however, in reality, they may have design resources locally and their development is off-shore. This is a good way for a developer to charge on-shore rates for development and make a huge margin. By doing appropriate diligence on the actual team members, you can weed these firms out.

2: The right process. Waterfall vs. agile.

In general, the industry is moving towards agile development. It provides more flexibility and iterative releases during software development with a lot less documentation before beginning development. Waterfall requires big documentation up-front before moving into development.

The larger your mobile app, the harder it is to know every single detail and nuance. Your timeline will be longer in waterfall.

Full agile means you have hardly any documentation before starting development and you have a high level understanding of the key pieces of functionality. You work in 1 or 2 week sprints and figure it out as you go. This is more expensive, but will get your product to market faster.

“Iterative development” is what we call a hybrid approach. There is some documentation up-front like wireframes and mockups for key screens and functionality. However, details and certain aspects are left to be figured out by the team during development.

3: Fixed fee vs. time and materials

In a waterfall structure, you could set up a fixed fee for the work. You could spend X on design & documentation and then receive a fixed fee to develop your app for Y. However, it is inevitable that you are going to want to change something. Enter Work Orders. Are work orders billed at the same rates? How many of their projects have work orders? How much is the original contract vs. work orders on average?

In an agile or iterative structure, you can be billed for the amount of work effort performed. The firm will provide you an estimate and rates that you’ll be billed. If billed hourly, do they have time tracking software and do you have access to review it? What happens if you dispute an invoice? Is there a process in place?

Although, on the surface, a fixed fee structure may seem to limit your risk the most, I would suggest caution. Your “locked in” price can be deceiving when you account for the total cost including future work orders. And, the ultimate goal is to get a great product that will accomplish your business objective. The quality and caliber of developer who works in a fixed fee structure can sometimes be compromised.

4: Estimate creations

What’s the process to create estimates?

Who made the estimate and does that person have a thorough understanding of what you are trying to build? Have you talked to that person? Have they worked on similar mobile apps and used similar technologies, examples? If the technologies are foreign to them, it is easy for them to mis-estimate. Historically, how do actual costs compare to initial estimates?

5: Code ownership and access

The code and intellectual property should solely belong to you. However, it is normal to see clauses about “generalized technology” which enables the developer to reuse common pieces of code. This ultimately brings down the cost of rework for your project. You should have access to the code throughout the project and/or have the developer send you the code throughout the project. Make sure to structure your payments so that the developer agrees to this. If there is ever a dispute in the future, you don’t want the developer to have all the leverage and hold your code hostage. If the developer has a big issue agreeing to this, run!

6: Code complete? Process tracking

How does the developer code? Do they have coding standards and guidelines for their teams? How often can you see a build of the mobile app while in development? If the developer is writing “complete code,” the answer should be daily. Meaning that the developer will ensure the app is functional at the end of each day. Now, it isn’t necessary to get a build daily; however, you don’t want to work with a developer who is writing incomplete code and not building all of the app’s desired functionality.

Many developers will get 70% done with an app and are never able to finish the last 30%. You want developers who will write code that is feature complete. Integrating into the API’s and finishing functionality as they progress is critical for successful development.

If the API’s aren’t finished, this can prevent a developer from programming in this fashion. For the most part, I recommend to have your API’s & backend farther along than your software app.

7: Automated QA

Does the developer have a QA team? Have they setup automated QA processes? What software do they use for QA automation? Are they writing test scripts during definition?

Automated QA is a strong indicator of a development firm’s maturity. It takes many projects under your belt to standardize your development processes to the point where it is feasible to automate your QA processes. Only having a human QA your app is inefficient. If your developers are writing “complete code” that means that an automated QA process can be run at the end of every day or every time the developer checks in code. This makes development much more efficient and helps to ensure quality.

Filed under: Product Engineering | Topics: mobile app developer, mobile platforms, platforms