How much does a web app cost? Scope, data and integrations explained

That makes a general price tag fairly unhelpful. A tool that lets one employee check leads is a different project from a complete membership platform that's part of your service. They both work in a browser, but the comparison quickly ends there.

You get a better handle on costs by looking at what users need to do, which data they need and how the solution connects to the rest of your business.

A small solution can focus on one specific task

One example of a small project is a simple dashboard for a CRM provider. Leads arrive in that environment first. The team reviews them, contacts them to arrange a call and checks them before forwarding them to its own CRM.

The value lies in one clear step: being able to assess a lead first and then pass it on in a controlled way. You don't automatically need to build a completely new CRM for that.

Even a small solution needs a few clear agreements. When has a lead been checked? Who can change its status? What happens if forwarding it fails? If that workflow stays clear and well defined, you can focus the build on it.

This example isn't a pricing package. An extra role, a different integration or a change in how you work can already change the project.

A membership platform involves more parts

At the other end, the brief might be to develop a complete membership platform tailored to a customer's product or service. You're then designing an environment that users return to over time and where a larger part of the service takes place.

Depending on the product, you might need to think about access, different memberships, personalised content, payments or progress tracking. Not every membership platform needs all those features. That's exactly why we first work out what a member needs to do and what the team behind it needs to manage.

The connections between those parts make a project like this larger. A change to a membership can affect access, communication and administration. Those workflows need to be designed, built and tested. The number of visible pages therefore tells only a small part of the story.

What determines the amount of work?

A few decisions have a big effect on scope. It helps to make them concrete early on:

• Users and roles: will only your own team use it, or customers and external partners too? What can each role see and change?
• Process steps: how many actions, decisions and exceptions does the app need to support?
• Data: does it come from one source, does it need cleaning up, or will existing information need to be migrated?
• Integrations: which systems need to work together, and what happens if they temporarily stop responding?
• Use and management: what should your team be able to change itself, and how will users get support after delivery?

An integration that only forwards a new lead is different from two systems that constantly need to keep up with each other's changes. And a single fixed user role calls for different decisions from an organisation where administrators assign permissions themselves.

That's why we look at complete user journeys, including situations where something is missing or goes wrong. Those also help determine how much design and testing work is needed.

Separate the project investment from recurring costs

The project investment covers our process: discovery, concept, design and build. During discovery, we investigate the problem and scope. We then work out how the solution functions, what it looks like and how we'll build it.

There are also costs for hosting and any additional tools. These might be services needed to keep the app available or support a specific feature. Which ones you need follows from the project. A custom web app at BORING isn't automatically tied to one platform.

Make agreements about maintenance, support and ongoing development too. Who handles an outage? What counts as maintenance, and what's a new feature? That way, you know which costs belong to the initial build and which arrangements continue afterwards.

Keep the first version small enough to test

You don't have to build every future wish straight away. Choose a first version that lets users complete a useful task from start to finish. That's different from putting half a feature everywhere.

For the lead dashboard, that could be the complete journey from a lead arriving to its checked handover. For a membership platform, first decide which part of the service needs to be available in the initial version. New features can then follow based on real use.

That helps keep the investment focused, without pretending that a large solution can always be built on a small budget.

Want to know what your web app would cost? Bring the problem to a conversation, along with your current way of working and the systems you use. A short explanation of where people get stuck is a better starting point than a long wish list with no priorities. From there, we can define a scope that supports a realistic estimate.