Business app development: stages, scope and timeline

A good app starts before the first line of code: with a list of who will use it, what they do on their phone and what stays out of the first version. Below are the stages of developing an app for your business, what to decide at each one and what to get in writing so the project does not turn into an open-ended bill.

1. Brief: who uses it and why

The first question is not “how much does an app cost” but “who opens this app and what do they need to do in it”. A field team logging visits, a customer tracking an order, a front desk booking appointments: each case calls for different screens. In the brief, list:

• User profiles — customer, employee, manager. Each sees different screens.
• The 3 to 5 main tasks — what people do every week. The rest can wait.
• What already exists — system, spreadsheet, website, ERP. Does the app talk to it or replace it?
• How you will measure it — fewer calls, faster orders, less paper. Without a goal, there is no way to tell whether it worked.

2. Screen map and prototype

With the brief settled, we draw the flow: entry screen, login, list, detail, action. A clickable prototype shows the path before development, while changes are still cheap. This is where extras get cut: every additional screen adds time, testing and maintenance.

3. PWA or store app

A PWA opens in the browser or from a home-screen icon and updates instantly, with no store review. For many businesses, that is enough. A native app on the App Store and Google Play comes in when the brief needs device features or a store presence; then there are developer accounts, store reviews and a longer schedule. See the official rules for the App Store and the Google Play Console. The decision goes in writing in the proposal.

4. The system behind the app

Almost every business app needs a dashboard: records, permissions, reports. That dashboard is business software running on the web. If you already have one, the app reads its data; if not, it goes into the scope. Lumping both into a single quote line is the source of many surprises.

5. Development in increments

Instead of disappearing for months and coming back with everything done, development ships in short increments: login and sign-up first, then the main task, then reports. You test each part on your phone and adjustments come in early.

6. Testing with real users

Before launch, put the app in the hands of the people who will actually use it: the sales rep, the customer, the front desk. Old phones, weak connections and small screens show up at this point, not in the meeting room.

7. Launch and maintenance

A PWA goes live on your company’s domain. A store app goes through each store’s review. After launch come fixes, operating system updates and new features. Agree on what the monthly plan covers before you sign.

What to ask for in the proposal

• List of screens and user profiles for the first version
• PWA or stores, in writing
• App, system and website as separate lines
• Schedule by increment
• Developer accounts, domain and code in your company’s name
• What monthly maintenance covers

To compare proposals, use the guide how to evaluate a proposal. For what drives the price of the dashboard, see how much a custom web application costs.

Common mistakes

• Starting with the design before knowing who uses the app
• Wanting every feature in the first version
• Publishing to the stores when a PWA would do
• Leaving the management dashboard out of the quote
• Store accounts in the vendor’s name

Next step

Tell us who will use the app, what they do on their phone today and whether you already have a system. We will reply with the recommended path (PWA, stores, with or without a system) and a written proposal. We work 100% online. See also mobile apps.