How to build an app for your business, step by step

Before you build an app for your business

When a service business owner says “we need an app,” they usually mean one of two things. A crew app shows techs or cleaners their day: jobs, addresses, notes, photos and a way to mark work done. A customer app lets customers book, approve a quote, check on a job or pay. They’re built for different people, and they take different steps to launch.

The other early choice is between a browser app, which opens from a link on any phone, and a store app downloaded from Apple’s App Store or Google Play. It changes the testing and launch steps below, and our guide to what it costs to build an app compares the two on price, store fees and when each one fits.

First, ask whether you need to build anything at all. Many field service apps already include a phone app for crews, as our guide to field service software explains. If one fits how you work, buy it. For a simple checklist or equipment log, a no-code app builder on top of a spreadsheet may be enough. The questions at the end cover when that stops working. Build when your work doesn’t fit those apps, or your team types the same job into several of them.

Behind either kind of app sits the part nobody sees on a phone: the office screens and the records. The app is a window onto your customers, jobs and invoices. If those records still live in a notebook, three phones and QuickBooks, the app has nothing reliable to show. That back half is usually where most of the work goes. Here’s how it tends to look in a few trades, as examples:

• A 6-truck HVAC company: techs see today’s calls, take photos, get a signature and send the invoice from the driveway. Mostly a crew app.
• A cleaning company with 4 crews: each crew sees its route and a checklist for each house, and the office sees what’s done.
• A property manager with 40 units: tenants send maintenance requests with photos, and vendors see only the work orders assigned to them. Two kinds of outside users, so the rules on who sees what matter.
• A café taking catering orders: customers order and pay a deposit online. That’s usually a good order form on the website, not an app in a store.

Step 1: Map the job as it runs today

Good app projects start with a walk-through, not a feature list. Someone sits with you and follows one job from the first call to the paid invoice. Who takes the call? Where is it written down? How does the tech know where to go? What happens when the customer asks for a change on site? Who notices an unpaid invoice?

Bring the people who do the work. A lead tech or crew lead knows where paper gets lost and which steps happen in the truck with no signal. A few minutes with them can change the plan more than an hour of feature ideas.

The result should be a short written scope: the one path the first version covers, who uses it, and what’s left out for later on purpose. Our notes on scoping your first software release explain why that first path should be small. This is also when you pick who builds it, and our guide to choosing a custom software company lists the questions to ask.

Your part: a call or two to walk through the job, and some of a crew lead’s time. Bring a few sample job sheets, invoices or screenshots of what you use now.

Step 2: Decide the records and rules behind the screens

Most guides jump from the idea straight to design. For a service business, the step in between matters more: deciding what the app reads and writes, and who can see what. Get this right and the screens follow. Get it wrong and the app looks fine but shows the wrong jobs to the wrong people. These answers are also what a fair quote is priced on, so a builder who quotes without asking about them is guessing. Write down, in plain words:

• The records: customers, addresses, jobs, quotes, invoices, photos, signatures and notes. Which ones the crew sees, and which ones only the office sees.
• The steps a job moves through, like requested, scheduled, on the way, done, invoiced and paid, and who can move it to the next one.
• Who sees what. A tech sees their own jobs, a dispatcher sees everyone’s, and a customer sees only their own. OWASP, a nonprofit that publishes security guidance, recommends denying access by default and checking permissions on every request, not just hiding buttons.
• What happens with no signal. Can a tech still see today’s jobs and take photos in a basement, and what catches up once they’re back online?
• Where today’s records come from. One clean spreadsheet moves over quickly. Customers spread across an old app and three phones, with duplicates, take longer to sort out.
• Which apps it must connect to, like QuickBooks Online for invoices or Stripe for card payments, and whose name each account is in.

Reference: OWASP: Authorization cheat sheet (opens in a new tab)

Step 3: Try the screens, then build in weekly rounds

Before any code, ask for rough screens you can click through on your own phone. They’re cheap to change. Look at them where the app will be used: in the truck, in sun glare, with work gloves on, with one hand. Buttons that look fine at a desk can be too small on a ladder.

Check each screen against a real job from last week. Can the tech find the gate code? Is the customer’s phone number one tap away? Does the office see the photos without asking for them by text?

Then the build starts, usually in rounds. Each round adds a piece you can try, like the day view, then photos and notes, then invoices. The office screens and the connections get built alongside the app, because the app is only as good as the records it shows.

New ideas will come up once you see it working. Write them down, and ask for each one to be priced before it’s added, so the first version still goes live on time.

Your part: a little time each week to try what’s new, and quick answers when the builder asks how something should work.

Step 4: Test with real jobs, real phones and bad signal

Testing is where an app meets a real workday. The builder tests their own work, but the test that counts is your team doing real jobs with it.

Store apps add a round with outside testers. Apple’s TestFlight lets you invite up to 10,000 external testers, and the first build they get goes through Apple’s review. Google Play has a rule for personal developer accounts created after November 13, 2023. Before you can apply to release the app to everyone, at least 12 testers must stay opted in to a closed test for 14 days in a row. Google writes that rule for personal accounts only, and tells businesses to open an organization account. If your Google Play account is a personal one, plan those days into your launch date. These store rules are as they stood when we checked in October 2026.

Whatever kind of app it is, run through a checklist like this with your own team:

• Every kind of user does their own work: the office books a job, dispatch assigns it, a tech finishes it, a customer pays.
• Phones your team actually carries, iPhone and Android, including older ones.
• No signal: switch on airplane mode mid-job, take photos, then reconnect and check nothing was lost.
• Mistakes: a phone number typed with dashes, a job cancelled after it was assigned, two people editing the same job.
• Access: a tech tries to open another tech’s job, or a customer tries to open someone else’s invoice by changing a link. Both should fail.
• Money: a test payment lands on the right invoice, and the invoice shows up correctly in QuickBooks Online or whatever you use.

References: OWASP: Authorization cheat sheet (opens in a new tab) · Apple Developer: TestFlight (opens in a new tab) · Play Console Help: App testing requirements for new personal developer accounts (opens in a new tab) · Play Console Help: Choose a developer account type (opens in a new tab) · Play Console Help: Get started with Play Console (opens in a new tab)

Step 5: Launch: the crew’s first week and the store paperwork

For a browser app, launch can be as simple as sending your team the link and showing them how to add it to the Home Screen.

Either way, roll it out to people. Pick a quieter week, not the start of your busy season. Walk the crew through it, keep the old way available for a few days, and name one person they tell when something looks wrong. Write each problem down: what they did, what they expected and what happened. That list gets fixes made faster than a phone call a week later.

For a store app there’s also paperwork, and some of it takes time, so start it during the build:

• Store accounts. Both stores charge a fee to sign up. Open them yourself, not under your developer’s account, so the app stays yours. Apple enrolls a business under its own name only if it’s a legal entity, such as a corporation, and doesn’t accept DBAs or trade names. A sole proprietor enrolls as an individual, so their own legal name shows as the seller on the App Store.
• A D-U-N-S number. Apple requires one from organizations to verify the business. Google requires one for organization accounts too, and notes that getting one from Dun & Bradstreet is free.
• A staff-only listing, if you want one. Apple’s unlisted distribution keeps the app out of App Store search and listings, and your team opens it from a direct link. It still goes through Apple’s review, and Apple names employee resources as a good fit.
• A privacy policy. Both stores require a link to it in the store listing and inside the app.
• A way to delete accounts. If customers can create an account in the app, Apple requires a way to delete it inside the app. Google requires one in the app and on the web.
• A demo login for the reviewer. If the app has logins, Apple asks for a working demo account. A built-in demo mode is allowed instead only with Apple’s prior approval. Apple says that on average, 90% of submissions are reviewed in less than 24 hours (when we checked in October 2026). A rejection means fixing the problem and sending it again.

References: Apple Support: Bookmark a website in Safari on iPhone (Add to Home Screen) (opens in a new tab) · Apple Developer: Enrollment (opens in a new tab) · Play Console Help: Required information to create a Play Console developer account (opens in a new tab) · Apple Developer: Unlisted app distribution (opens in a new tab) · Apple Developer: App Review Guidelines (opens in a new tab) · Play Console Help: User Data policy (opens in a new tab) · Apple Developer: App Review (opens in a new tab)

Step 6: Keep it working after launch

An app isn’t finished at launch. Apple and Google keep releasing new phone software, and store rules change. The apps yours connects to, like QuickBooks Online or Stripe, change how they work too. Any of those can break something that worked last month.

Plan for three things. A fix period right after launch, written into your agreement. Someone who checks updates on a test copy and puts them live. And a way to ask for small changes as your business changes, like a new service or an extra field on the job form. Our guide to who looks after your software after launch covers what a support plan should put in writing.

Keep the keys, too: the store accounts, the domain, a copy of the code and an export of your records. Then if your builder ever moves on, someone else can pick it up without starting over.

How we build apps for service businesses

We build the whole thing, not only the phone screens: the crew phone app, a customer portal if you need one, and the office screens and records behind them. We connect to QuickBooks Online, Square, Stripe, Shopify, Google Calendar, Gmail or Outlook, and check anything else before we quote. What we build works in the browser on phones, tablets and computers. If your team needs an app on their home screen, we can build that too.

Our steps follow the same order. After a free first call, you get a fixed price in writing within 48 hours. In week 1 we map how your work flows and agree on the first version. You try the screens as they come together, we test with your real jobs, and you get a written update every week. Then comes launch, a walkthrough for your team and 30 days of fixes.

One business system, like scheduling and invoicing for a crew of 5 to 10, is typically $6,000–$18,000 over 6–⁠10 weeks. A full system with customers, jobs, quotes, invoices, payments and a crew app is $18,000–$40,000 over 10–⁠16 weeks. These are our prices as of October 4, 2026. You own the code we write once the project is paid in full. Hosting runs on our account, and you can take it over after payment.

If an app off the shelf fits, we’ll say so. If not, see how our custom business software works, or book a free first call.