Desktop, Web or Mobile App? Start With the Workflow

Start here

Describe the job before choosing a framework

A quote for “an app” is difficult to compare until the workflow is clear. Start with one sentence: a particular person needs to complete a particular task, on a particular device, in a particular setting. A customer booking an appointment, a technician recording work without a signal, and an employee reconciling orders may need very different interfaces. List the steps from opening the product to finishing that task. Then identify the step that is slow, error-prone, or impossible today.

When a web app is a useful starting point

A browser application often suits customer portals, booking flows, approval tools, and dashboards that people reach through a link. It can keep access straightforward across computers and phones, with updates delivered through the website. Check the real requirements before assuming that a browser can or cannot support them. Offline behaviour, notifications, printing, file access, and device integration vary by browser and platform. Test any critical capability early.

When mobile app development makes sense

An installed mobile app is worth considering when the phone is central to the experience: frequent touch interactions, device features, notifications, or a product people expect to find in an app store. Store distribution brings additional work, including screenshots, account ownership, review requirements, purchase rules, and compatibility testing. Include that work in the scope alongside the main screens.

From our work

Flowboo: separate the offline core from connected features

Flowboo is a React Native and Expo puzzle app released on iOS and Android. Its core puzzle experience supports guest play with progress on the device. Accounts, cloud saves, and rankings need a connection. This distinction matters for a business app too: decide which tasks must keep working offline, what is saved locally, and how updates are reconciled when the connection returns. “Works offline” should describe a specific set of tasks rather than the entire product by assumption.

When a desktop app deserves consideration

Installed desktop software can suit long-running work, local files, specialist hardware, or workflows that need deeper operating-system integration. Ask which operating systems and devices the business actually uses. An installer is only part of the scope: updates, permissions, backups, distribution, and support also need a plan. For a shared team workflow, a web application may still be enough. A small technical prototype can settle an uncertain integration before the full build.

From our work

Questborne: the interface and backend have different responsibilities

Questborne uses Flutter for its mobile interface and Supabase services for backend work, including game state and purchase-related logic. The useful lesson for a business product is to decide which operations require server authority. Permissions, billing entitlements, and shared data should not depend only on what the interface displays. Include backend rules and failure cases when estimating the work.

Write a first-release brief that can be estimated

A useful brief does not need technical diagrams. It needs enough detail to make the major decisions visible. Separate the one workflow that makes the product useful from features that can follow later. Ask for assumptions, exclusions, and ongoing costs alongside the development estimate.

• Who uses it, and what is their most important task?
• Which devices, operating systems, and offline tasks are required?
• Which accounts, data, APIs, payments, or hardware must connect?
• What information needs protection, and which roles can access it?
• What belongs in the first release, and what can wait?
• Who owns the store, hosting, source code, and support responsibilities?

Choose a platform against the evidence

There is no automatic winner between web, desktop, Flutter, or React Native. Choose based on the workflow, integrations, delivery constraints, and maintenance needs. Codent can help turn that brief into a scoped first release. Bring your existing process or product idea, and we can discuss the uncertain parts before committing to a larger build.

FAQ

Frequently Asked Questions