Development guides / New apps and first releases

What should the first version of a new app actually deliver?

The first release should let a defined user complete one useful journey. Screens alone are insufficient if data is not saved or staff cannot handle requests.

By ProApp2026-10-06How ProApp works

AI-generated concept of two phones showing a request form and submission status, with an admin interface behind them — AI-generated concept image, not a client project screenshot

What is missing when you already have an idea or design?

People planning an app often already know the need: customer service requests, staff work records or a mobile extension of an existing business. The harder step is turning a feature wish list into something users can complete and the business can operate.

For example, a customer may submit a request successfully on their phone, while staff have no way to view, assign or respond to it. Plan both sides of the journey before deciding which features deserve investment in the first release.

Choose an appropriate approach

For occasional forms, information lookup or booking, compare a mobile website with an app. If offline work, device features or frequent use matter, specify the required app capabilities. Decide whether platforms should share code based on functionality and maintenance needs.

Separate features needed to complete the main job from later improvements. Permissions, essential administration, error handling and persistent data affect the whole journey; screen count alone is a poor scope estimate.

**Illustrative workflow**A first release connects customers, stored data and administrators. Test from submission through the status update to confirm that the whole journey works.

Scope a concrete example

The example below illustrates an approach. It is hypothetical, not a client case study or a claim of delivered results.

Consider a service-request app: customers register, submit a request and track progress; staff receive, assign and update it. Connect that journey in the first release. Decide on referral rewards, social features and complex reports after observing real usage.

**Illustrative interface**The conceptual screen shows a saved request and its state. Acceptance should check that it matches the backend and remains available after signing in again.Sample data and a conceptual interface illustrate the design approach. This is not a screenshot of a client system.

Define delivery and acceptance

Run the full journey as a customer and an administrator; verify permissions, saved data and state after signing in again.
Test network interruptions, repeated submissions, missing data and third-party failures. If payment is required, reconcile payment and order states.
Agree separate milestones for a testable build, a submission-ready build and public launch. Store review is controlled by the platform; finished code does not mean store approval.

How should you compare cost and timing?

When comparing app quotations, check design, frontend and backend, permissions, test devices, integrations and handover. Existing screens or AI-generated interfaces can be a starting point, but data handling, failure cases and administration still need checking.

If the deadline is tight, discuss a smaller release, staged testing or an internal trial first. One unready integration can block acceptance of the whole journey. Public launch planning must also allow for store review and responses, rather than treating every feature as due on the same date.

Prepare before starting

Provide the intended users, the most important journey, any designs or sketches, data sources and developer accounts you control. Allow for design decisions, content, integration testing, acceptance and store responses. Handover should cover source code, accounts, deployment instructions and maintenance.