Most businesses that ask for an app need something specific: customers booking without calling, staff logging jobs from the van, members checking in, orders placed in two taps. The hard part usually isn't the code. It's deciding what the first version must do, picking a sensible technical approach, and planning for the years of updates after launch.
This site explains how a mobile app project is normally run and what to settle before you sign. When you're ready, the form below goes to a service partner who designs and builds apps, and they'll reply with questions and a written estimate.
How a build usually runs
- 01
Discovery
Goals, users, the few features that matter at launch, platforms, integrations, risks.
You get: Written scope, feature list with priorities, estimate
- 02
UX and UI design
User flows, wireframes, a clickable prototype, then visual design for each screen and state.
You get: Design files, prototype you can tap through
- 03
Build
Short development cycles, app and backend in parallel, a test build at the end of each cycle.
You get: Working test builds on your own phone
- 04
Testing and beta
Testing on real devices and OS versions, then a beta through TestFlight and Google Play testing tracks.
You get: Bug list closed, release candidate
- 05
Store submission
Store listings, screenshots, privacy disclosures, review notes and a demo login for reviewers.
You get: App approved and released under your accounts
- 06
Maintenance
OS and SDK updates, store policy deadlines, crash fixes, security patches, new features.
You get: Release notes, update schedule
Apps businesses commonly commission
Customer apps
Booking, ordering, loyalty, account management. Usually need payments, notifications and a solid login.
Staff and field apps
Job lists, checklists, photos, signatures, offline use in places with poor signal. Often distributed privately, not on the public store.
Companion apps
A mobile front end for a system you already run, such as a booking platform, CRM or inventory tool, through its API.
Four decisions to make early
- Platforms. iOS, Android or both, and whether one shared codebase is good enough. See native vs cross-platform.
- Distribution. Public app stores, or private distribution to staff. Public listings go through store review.
- Ownership. Who owns the code, the developer accounts and the signing keys. Put it in the contract. See code and IP ownership.
- Life after launch. Phones and operating systems change every year. Budget for maintenance from the start.
Send a project brief
A short description is enough to start: what the app should do, who uses it, which platforms and any systems it must connect to. Cost mostly depends on the number of screens and user roles, integrations, offline needs, payments, the backend, design depth and how many platforms you target.
Do I need an app, or would a website do?
Often a well-built mobile website or web app is enough, especially for content, simple forms and occasional use. Native apps make more sense for frequent use, offline work, the camera, Bluetooth, background location or reliable push notifications. A good discovery phase should tell you honestly if you don't need an app.
Can you take over an app someone else built?
Usually, if you can provide the source code, access to the developer accounts and the backend. Expect a code review first. Older apps sometimes need upgrades before new features can be added.
Will you sign an NDA before I share my idea?
Ask for one in your first reply. It's a common and reasonable request.