Most aborted app projects don’t fail due to poor coding. They are losers because the wrong team was engaged for the wrong reasons: because they made a low bid, the slick job portfolio, or because they had a good sales pitch. Buyers’ decisions on mobile app development are a procurement decision, an engineering decision and a product decision in one, and most buyers only consider one of these.
Follow the steps below to assess any team. It includes a weighted score card, a comparison of the primary engagement models and a red-flag checklist to reference in the next vendor call. All of this is done using patterns that are found time and again in software delivery work, and thus can be used by start-ups as well as by product managers in large established businesses.
Start With the Decision, Not the Directory
Before you look at a single portfolio, answer three questions in writing:
- What is the app’s job? One sentence, such as “let field technicians log inspections offline.”
- What does version one need to prove? A hypothesis, not a feature list.
- What breaks if this launches late or badly? This gives a good indication of the amount that you have to pay for reliability.
These answers are important because they determine the type of team fit. It’s important that the app feels flawless when it launches, whereas a tool inside a company can be faster but not as polished. Teams that skip this step end up comparing quotes for projects that aren’t actually the same project.
Chapter 1: The 5-Signal Vetting Scorecar
This is the first original aspect of the guide, a weighted scorecard which can be duplicated and entered into a spreadsheet. Give each candidate team 1-5 points for each signal multiplied by the weight and then compare the total points out of 100.
| Signal | What to verify | Weight |
| 1. Shipped proof | Live apps in the stores, not just design mockups | 25% |
| 2. Process transparency | Sprint cadence, demo schedule, access to the repository and backlog | 25% |
| 3. Technical fit | Experience with your platform choice, backend and integrations | 20% |
| 4. Post-launch capability | Monitoring, crash response, update plan | 15% |
| 5. Communication quality | Quick response, understanding of trade-offs, saying no | 15% |
How to use it: Have each team explain to you how they have shipped one app from the first sprint to the current version in the store. Real delivery experience teams discuss their decisions and trade-offs.
A deliberate approach to weighing in proof and process transparently is shipped. A good portfolio demonstrates what they have accomplished in the past, and a clear process demonstrates if they can repeat those steps for you.
This section compares the Engagement Models.
The position of your team has as much influence on cost, speed and control as the players who are on it.. The table below is the second original elementThe cost positions are relative and not quoted as prices fluctuate widely depending on region and scope.
| Model | Best for | Cost position | Control | Main risk |
| In-house hires | Long-term core products | Highest, plus hiring time | Highest | Slow to assemble; key-person dependence |
| Dedicated team from a software company | Products needing sustained development | Medium to high | High | Needs clear ownership on your side |
| Project-based agency | Well-defined scope with a clear end | Medium | Medium | Scope changes get expensive |
| Freelancers | Small builds, prototypes, specialist gaps | Lowest upfront | Variable | Availability and continuity |
Rule of thumb: If the roadmap is over a year away, then target the team or in-house.
When you have one document that describes the finished product, you are pretty much safe to use a project based agency. When you are able to take control of the technical direction, freelancers work best.
Section 3: Evaluate Technical Decisions Without Being Technical
Don’t have to read code to test if the team knows what it is doing. Ask these questions and tune into specific answers.
Native or cross-platform and why for this app?
A believable answer mentions your real requirements, like performance requirements, device capabilities or budget. Try to avoid any team that provides the same answer for each project. These are both correct. Mobile frameworks minimize development time across both iOS and Android environments, and native development provides more access to platform-specific features, and usually the best performance for intensive interfaces.
How will you handle offline use, slow networks and low-end devices?
You can’t have real world conditions break apps that only work on fast office Wi-Fi. . A team with field experience will bring this up before you do.
What does your testing look like?
Look for a mix of automated tests, testing on real devices, and a beta release process through the platforms’ own testing channels. “We test it manually before release” is not a testing strategy.
How are you approaching security and data?
Anticipate responses concerning the security of user data, user authentication, and least privilege access to user data. If your application deals with payment or health data, inquire about how the team meets the requirements of compliance to your market.
Section 4 is the Red-Flag Checklist
This is the third original element—a linkable checklist you can bookmark. If you have three or more of these, you can walk away.
- The quote arrives without a single clarifying question
- No access to a live app they built, only screenshots
- Refuses to name who will actually work on your project
- Promises a fixed price and a fixed deadline for an undefined scope
- No mention of testing, analytics or post-launch support
- Ownership of source code and accounts is unclear or “to be discussed later”
- Pressure to sign quickly with a time-limited discount
- Cannot explain a past project that went wrong and what changed afterward
The last item is the most revealing. Every experienced team has a project that went badly. The ones worth hiring can describe it honestly.
Protect yourself contractually: You should own the source code, the developer accounts for the app stores, and all third-party service accounts. Establish these in your company’s name, as opposed to the vendor’s name, from the beginning.
Section 5: Run a Paid Pilot Before You Commit
Vetting by a small paid pilot is the most dependable way but is seldom used. Assign the same project to both of your favorite candidates, say “14 days, one core screen with real data connections.To compare results, choose the same 14-day project, e.g. develop a single core screen having actual data connections. Using the 5-Signal Scorecard, score each of the three teams shortlisted.
A good pilot reveals what no sales call can:
- How quickly questions get answered
- Whether the team pushes back on unclear requirements
- The quality of the delivered code and documentation
- How they respond to a change you introduce mid-way
Treat this as you would any hiring trial budget. Much cheaper than finding a discrepancy six months in to a full build.
Expert Perspective: What experienced Product teams watch
Product leaders, who have shipped multiple apps before, can all say something similar: it isn’t so important about the scope as it is about the working relationship. Requirements will vary after the first build is seen by users. The right partner sees that as a natural part of the game and will have a concerted course of action for re-prioritizing instead of a clause for them to charge you more.
Treat the first month as the real interview. If the sprint demos are not clear, communication is not good, or questions aren’t resolved, it is unlikely these will get better when the contract is bigger.
Your Practical Takeaway
When you evaluate mobile app developers, do these five things in order:
- Write down the app’s job and what version one must prove.
- Using the 5-Signal Scorecard, score each of the three teams shortlisted.
- Don’t align the engagement with your budget, align the engagement with the length of your roadmap!
- Fill out the red flag checklist for any and all proposals.
- Sign up for two weeks of free trials for your top 2 before signing up.
A good team, passing the checklist and performing as the pilot, has been awarded the bigger contract. One that doesn’t pass one of the three has saved you from a costly error.
One Response