In this guide 6 sections
Build a business app in five steps. Watch the job, sign a screen list with a role matrix, test a clickable prototype on a real phone, pilot it with one team before you publish. Each step ends with a sign-off you keep. Nothing ships unseen.
Watch the job before you list a single screen
Spend a day at the counter, the workshop bench or on the delivery route, watching rather than asking, because people only describe the old process. Note what they scribble on paper, which messages they send on WhatsApp and where they walk back to a desk to look something up.
Every delivery slip and job photo is a record the app may hold, so a driver who photographs a signed delivery note needs a camera screen, not a form. That detail shapes the design.
Keep the notes short, with one line per task that names who does it and how often, because ten lines will surprise you.
- The paper slips and registers in use today
- Messages sent to customers or the office
- Tasks that need a camera, a scan or a signature
- Places on the route with weak mobile signal
Turn your notes into a signed screen list and role matrix
Name every screen on its own line with a purpose in a few words, such as login, job list, job detail, photo capture, customer signature or daily summary. Stop there for the first release.
Beside it, draw a role matrix with screens as rows and roles such as owner, supervisor and field staff as columns, then mark each cell see, edit or hidden. Field staff rarely need the rates an owner approves. Hide them.
Sign both pages with initials from you and from the developer, which turns a vague wish into a scope and sends every later addition through a written change. Cost and delivery date stay honest.
Test a clickable prototype on a real phone
A prototype is a set of linked screen drawings that behave like the app before any working code exists, and the designer can send it as a link. Open it on a real handset. A meeting room monitor tells you nothing.
Pick two or three people who will really use the app and give each a single task, such as closing a job. Then stay quiet. Watch where a thumb hesitates. That hesitation is a free defect.
Fix the flow now. Moving a button in a drawing takes minutes, but moving it after the code exists can cost days of retesting across Android handsets with different screen sizes.
- Test on the cheapest handset your staff carry
- Give a task, not a tour
- Count the taps for the most frequent job
- Record every wrong tap
Run a pilot before you publish to the stores
Install a test build for one team at one branch for two weeks, and keep the paper process running beside it so that nothing stops if the app fails. Compare the two totals every evening. Differences are your bug list.
Ask the team lead to log faults in one shared sheet with a screenshot, the phone model and the time of day. A pattern across three handsets points to the device, while a fault on one phone points to that account or its user.
Decide in writing what counts as a pass. Every job opened in the app must be closed in the app, and the daily summary must match the paper total to the last entry.
Publish, then take over what the vendor built
Releasing to Google Play and the App Store needs a listing, screenshots, a privacy page and review time, so plan a few days. Review can bounce a build. One missing privacy URL is enough.
Open the developer accounts in your company’s name, add the vendor as a team member, and at handover collect the source code, build instructions, signing key and server logins. The tracker lists each one.
Book a review a month after release and read the crash reports, the slow screens and the requests that staff keep repeating. That list becomes version two.
App build tracker, one page
The tracker runs to one page and has five rows, one for each step: observe, screen list, prototype test, pilot and release. Columns hold the owner, the date, the sign-off initials and a result cell marked passed or failed, and a foot block lists accounts, signing key and source code. Each gets a tick.
Open a blank worksheet to printQuestions owners ask
How long does it take to build a business app?
It depends on screen count and on how quickly you answer questions, and a short list, quick prototype feedback and a ready pilot team all shorten it. Ask for a date against each step.
Do I need both an Android and an iPhone version?
Check what your staff and customers carry. Field teams often use cheap Android handsets only, while customers split across both platforms, so build first for whichever group you must reach. Add the other after the pilot.
Who should write the screen list?
You and the developer, together. You know the daily job and the developer knows what is practical on a phone, so one person alone usually misses either a daily task or a technical limit.
What if the pilot fails?
Failure is what a pilot is for. Publishing a flawed app to every branch costs far more than a second pilot, so log the faults, fix the worst ones and run it again.