What does a custom app cost?

Start with the task, then choose the app

An app is useful when it helps someone complete a recurring task. Write that task in one sentence: a customer checks a project status, an employee records a job, or a team approves a request. Describe the current process and where people have to copy information, wait or ask for help.

A useful first brief includes who can log in, what each role may see and what counts as a completed action. A portal with one customer role is a different project from a marketplace with payments, several roles and moderation. A screen count alone is not a reliable quote.

When is a web app enough?

A web app runs in a browser and can work on a phone, tablet and computer. A progressive web app can add capabilities such as installation or offline behaviour, when built for them. Support depends on the device and browser, so essential features need to be tested on the devices your users actually have.

For MakeMorrow projects, we begin with the required workflow and check whether a web app covers it. App-store distribution or deep device integration is a separate requirement to assess. Do not commission a mobile app simply because the word sounds more complete.

• Google’s introduction to progressive web apps

Which requirements determine the quote?

Separate the first usable release from later ideas. The price needs to include the less visible parts: handling incorrect input, recovering from a failed connection, managing permissions and helping users understand what happened.

• Roles and permissions: who may view, edit or approve which information?
• Data: which records already exist and do they need cleaning or migration?
• Integrations: what can the existing systems expose and at what usage cost?
• Business rules: what happens when a request is incomplete, late or duplicated?
• Quality: which devices, accessibility needs and security requirements must be covered?

What should a first version include?

An MVP is the smallest usable version that tests the central idea. For an illustrative customer portal, the first release might contain sign-in, viewing a request and sending a response. A chat feature, payment module or extensive dashboard can wait unless the core task depends on it.

Define acceptance criteria before building. For example: a customer can only view their own request, an employee can update its status, and a failed update produces a clear message. Start with a small user group, record the obstacles and decide which changes are needed for wider use. This is a planning example, not a claim about a delivered client project.

Which costs continue after delivery?

A working app also needs hosting, a database, monitoring, backups and support appropriate to its use. External systems or AI providers may charge by subscription or usage. If distribution through app stores is required, confirm the associated account, review and maintenance responsibilities separately.

Agree who owns the source code and accounts, who handles incidents, how backups are restored and which updates are included. Maintenance of a custom app has its own scope; MakeMorrow’s website subscriptions are not a published price for app support.

What should you send to MakeMorrow?

Share the current process, intended users, essential features, existing systems and an example of the information the app will handle. Add your budget boundary, preferred launch window and the person who can approve decisions. Use fictitious data for early examples.

We can then discuss a defined first release, what needs investigation and the acceptance checks. The proposal distinguishes design and development from external subscriptions, ongoing care and later improvements.

• Explore custom apps, portals and MVPs
• Considering automation of an existing process?