Build an App for My Business: When You Need One and What It Costs

Start with the sentence a customer would say. 'I want to book without calling.' 'I want to order ahead.' 'I want to see where my job is.' 'I want to pay the invoice from my phone.' Each of those is a task, and a task can live in a browser tab as easily as in an installed app.

An app in the store makes sense when customers will open it often enough to remember it is there, or when you need hardware the browser cannot reach in a reliable way. A gym with members checking in daily, a restaurant with a loyal lunch crowd ordering three times a week, a delivery fleet that needs background location. Those are app businesses.

A plumber, a dentist, a med spa, a caterer or a tutor is a different case. The customer might deal with you twice a year. Nobody installs an app for a business they use twice a year. They will tap a link in a text, finish the task, and forget the tab. That is the behavior to build for.

The question is not "do I want an app". It is "what task do my customers keep asking to do on their phone".

A native app is built for iOS or Android, submitted to the App Store or Google Play, reviewed by the store, and downloaded by the customer. Two platforms usually means two builds or a cross-platform framework, and every update goes back through review.

A web app runs in the browser at a link you own. Google's own guidance describes a Progressive Web App as a web app that 'can be installed', with an icon on the home screen and its own window, and notes there is 'no need for packaging, no extra content review, or delays on updates'. It reaches anyone on any device with a single codebase.

A customer portal is a web app with a login. The customer signs in, sees their own bookings, invoices, photos or documents, and acts on them. For most service businesses this is the thing they actually mean when they say "app".

The honest limits of the web app: background location, some Bluetooth hardware, and the shelf space of an app store icon. If your business lives on one of those, go native. If not, the browser is the cheaper and faster road.

Booking

A calendar the customer can see, the services and durations you offer, a deposit if you take one, and a confirmation by text. For a salon in Long Beach or a chiropractor in Pasadena this often starts as a Calendly or Acuity embed on the site, then grows into its own flow when you need staff selection, packages or intake forms.

Ordering

A menu or catalogue, a cart, pickup or delivery times, and payment. A bakery in Glendale that sells out of a Saturday cake run, a caterer taking Thanksgiving orders, a food truck in Santa Ana posting the week's stops. The order lands in your kitchen printer or your phone, and the customer gets a text when it is ready.

Portals

A login where the customer sees what you have done for them. A general contractor posting daily photos and the next milestone. A cleaning service showing the schedule and the invoice. A law firm sharing documents to sign. A fitness studio where a member sees what is booked, pays, and rebooks without calling anyone.

Loyalty

A stamp card the customer cannot lose. A phone number or QR code identifies them, purchases add up, and the reward triggers on its own. Cafes, car washes, pet groomers and barbers get the most out of this, because the visit repeats and the reward is small enough to be automatic.

Every one of these runs in the browser. Every one of them can be added to a home screen. And every one of them can plug into what you already use: Jobber, Housecall Pro, Square, Stripe, Calendly and Google Calendar all have connections Sitesmith has wired before.

Published ranges vary widely because "app" covers everything from a stamp card to a bank. Two current guides give a sense of the market for a native or full custom build.

Appinventiv also lists US hourly rates of $60 to $120 and a timeline of three to six months for a simple app. Those figures describe agencies building native apps for funded companies. They are not what a local business should expect to pay for a booking flow, but they are the numbers you will meet when you search, so it helps to know where they come from.

On top of the build, a native app carries store costs. The Apple Developer Program is $99 per membership year. Google Play charges a one-time $25 registration fee. Apple takes 15% of paid apps and in-app purchases under its Small Business Program for developers under $1 million in proceeds, and 30% above that. Google Play takes 15% of the first $1 million in annual revenue and 30% beyond it in most markets, with different tiers in the US, UK and EEA from June 2026. None of that applies to a web app, where a card payment goes through Stripe or Square at the normal processing rate; Stripe lists 2.9% plus 30 cents per domestic card transaction.

Hosting, a database, text and email sending, payment processing, and someone to fix what breaks when a phone update changes behavior. A native app adds the annual developer fees above and the work of resubmitting to the stores when the operating systems change.

• Hosting and database: a small web app for a local business runs on ordinary hosting, the same kind a website sits on.
• Messaging: text confirmations and reminders are billed per message by the carrier route, and US business texting has to be registered under the carriers' A2P 10DLC system before it will deliver reliably.
• Payments: processed by Stripe or Square at their published rates, paid out to your bank.
• Maintenance: a care plan or an hourly arrangement. Sitesmith care plans run $25, $49 or $99 a month for websites, and an app is scoped with its own line for upkeep.

Ask any builder two questions before you sign: who owns the code and the data, and what happens to the app if you stop paying them. Sitesmith answers both the same way it does for websites. Your data is exportable, and the build is handed over on request.

1. A scoping call. You describe the task customers keep asking for. We write the feature list down, in plain words, and it becomes the contract.
2. A first version that does one thing. Booking, or ordering, or the portal. Not all three. The second thing waits until the first is in use.
3. A working prototype you tap through on your own phone before we finish it. You change what is wrong then, not after launch.
4. Connections to what you already run: your calendar, your invoicing tool, your card processor, your text line.
5. A fixed quote before we start. Apps are quoted, not priced from a menu, because a booking flow and a client portal with payments are not the same job.

It runs in the browser on phone, tablet and desktop and installs to the home screen if you want it to. That skips the app stores, their review times and their cut. If a store listing turns out to matter later, the same web app can be wrapped and submitted, and the work you paid for is not thrown away.

If what you need is closer to a website with a booking embed and a payment link, say so. A Standard site is $1,500 to own or $500 down and $49 a month to lease, and it ships with a booking embed and a click-to-call already in it. Plenty of businesses that came in asking for an app leave with that, and it was the right call.