In this guide 6 sections
Ask who writes the screen list, which phones run the tests, how the app behaves offline, who holds the code and signing keys, and who pays for notifications. Then ask what support covers. Get every answer in writing. Vague replies reveal more than polished demos.
Who writes the screen list, and who signs it off?
A scope reading “staff app with login and reports” is no scope at all. Before any price is final, the vendor should hand you a screen-by-screen list showing the fields, validations and user roles on every page of the build.
Find out who writes it. If the answer is you, expect gaps. Name one person on your side who can approve it. Without that person, every disagreement becomes a change request, and the invoice keeps growing while the build waits for someone to decide what a button should do.
A clickable prototype helps. Walking a counter clerk through twelve screens on a phone costs one afternoon. Finding a missing approval step after release costs weeks of rework, support calls and unhappy branch staff.
- Screen list with fields, validations and roles
- One named sign-off person
- Prototype review with two real users
- A written definition of a change request
Which phones is it tested on?
Demos run on the vendor’s newest handset. Your drivers, sales staff and customers may carry a four-year-old Android with little free storage, a cracked screen and a battery that dies by noon.
Request the list of devices and operating system versions in the test plan, plus the oldest Android release the vendor agrees to support. Camera upload, barcode scan and PDF download are where cheap phones fail first, so test those three.
Ask to see them work on a handset you pick. Emulators do not count. An emulator on a developer’s desk never loses charge, never drops its signal and never runs out of storage in a warehouse aisle.
What happens with no signal?
Put this as a scenario. A technician fills an inspection form in a basement, taps save and walks to the lift with no bars of signal. Where does the entry sit?
The right answer names local storage on the phone, a visible count of pending entries and an automatic retry once the network returns. Silence means the app was designed for office wifi.
Press further. What shows on screen when an upload fails? What happens when two people edit one record while offline? If your staff never work offline, say so and save the cost, but if they sometimes do, offline behaviour belongs in the quote as its own line.
- Where an unsaved entry lives until sync
- What the user sees while entries are pending
- How clashing edits are resolved
- Photo and signature upload on weak networks
Who holds the code, the accounts and the keys?
At handover, ask which party holds the source code and in which repository it lives. Your company should own the Apple developer account and the Google Play console from the first day, because a vendor publishing under their own account holds your app hostage.
The Android keystore file matters more than most owners realise. If it or its password is lost, updates to the same Play listing become impossible, so ask where it is stored and who else holds a copy.
Add build instructions, API documentation and admin credentials to the handover pack. A repository that nobody outside the vendor can build is not ownership. It is a locked box.
How are notifications billed, and what does support cover?
Push notifications, SMS one-time passwords, maps, email and cloud storage each carry a usage charge from a third party. List every service the app calls, whose account pays, and how that bill grows as staff and customers are added.
Now read the support clause slowly. Does it cover crashes after a new Android release, or changes to store policy? Is a bug fix included but a new report excluded? Demand response times in hours. Adjectives mean nothing.
Call two past customers and ask what the first six months after launch looked like. Then send this same list to every vendor on your shortlist and compare the written replies side by side. The gaps will be obvious.
App vendor question sheet
One printed page holding a table of four columns: question, the vendor’s written answer, evidence you asked for, and your score from zero to two. Rows fall into seven blocks covering screen list, device testing, offline use, code and accounts, key files, third-party bills and support terms. A totals row ranks three vendors.
Open a blank worksheet to printQuestions owners ask
How many vendors should I compare?
Three is enough. Send each the same question sheet and the same one-page brief, then compare the replies. The differences show who has shipped business apps with logins, roles and reports and who has only built demos.
Should the vendor or my company own the store accounts?
Your company. Register the Apple developer and Google Play accounts yourself, then add the vendor as a team member with limited rights. If the relationship ends, you remove access and keep the listing.
Is a fixed price safer than hourly billing?
Only if the screen list is fixed too. A fixed price over a vague scope just moves the argument into change requests. Hourly work with a weekly cap and a live demo every fortnight can protect you equally well.
What should I ask for at handover?
The repository, build steps, API documentation, keystore, store accounts, third-party logins and a list of recurring bills. Then test it. A developer outside the vendor should be able to build the app from those files alone.