The five questions you need to ask yourself before developing an app have little to do with technology. They are: what problem it solves, whether it needs to be an app at all, what it has to connect to, what it will cost to build and to run, and who will own it and look after it. A project that cannot answer them is not ready to be quoted for. Answering them takes an afternoon and removes most of the reasons app projects overrun.
This article assumes the app has a business purpose: a tool for your staff, or something your customers log in to.
1. What problem is it solving, and how will you know it worked?
“We need an app” is a solution. The problem sits behind it and sounds more like this: engineers write job sheets on paper, the office types them up two days later, and invoices go out a week after the work was done.
Write the problem in two sentences without mentioning software. Then choose a measure you could check six months after launch, such as “invoices go out the day the job is finished”.
The measure does two things. It tells you what the problem costs today, and therefore how much it is worth spending to fix. It also gives you a way to settle arguments about scope: a feature that does not move the measure can wait for a later phase.
Next, list the people who will use the app and what each of them needs to do. Then write down the five things it must do on its first day, each as something a person does, for example “an engineer records the parts used on a job”. Stop at five. Everything else goes on a list headed “later”.
2. Does it need to be an app at all?
There are three alternatives to rule out before commissioning anything.
A packaged product. If every business in your trade has the same problem, someone already sells software for it, and a subscription will cost less than building your own. Bespoke software earns its cost where you do something your own way and that way is worth keeping.
A low-code platform. These let you assemble forms and simple processes with little programming. They suit small internal tools and run into limits as the rules and the number of users grow. We set out the trade-off in bespoke software or a low-code platform.
A web application. People say “app” for anything on a phone. A web application runs in the browser on phones, tablets and desktops alike, needs no installation and no app store approval, and everyone is always on the current version. An app installed from the Apple App Store or Google Play costs more to build and maintain. It earns that when staff must work without a signal or the task leans heavily on the phone’s own hardware. Native app or web app goes through the choice.
There is also the matter of who builds it. AI coding tools now let someone with no programming background produce working screens surprisingly quickly, and a prototype made that way is a good means of showing a supplier what you have in mind. A system the business depends on needs more than screens that work. It needs to be secure and backed up, and someone has to be able to change it safely three years from now.
3. What does it have to connect to, and what data will it start with?
Very few business apps stand alone. Yours will probably need to exchange information with an accounting package, a job or stock system, email, perhaps a payment provider.
Each connection is a separate piece of work, and how hard it is depends on the other system. Some have an API, a defined way for other software to read and write their data. Some do not, and the only route is the database or exported files. Find out which before asking for a price, because this is where quotes most often turn out to be wrong.
Then there is the data. Most new systems begin life with records from whatever came before: customers, products, open jobs, several years of history. Moving them takes longer than people expect, because old data is full of duplicates, gaps and entries that only made sense to the person who typed them. List what has to come across, where it is now and who can say whether it is accurate.
4. What will it cost to build, and what will it cost to run?
The build cost depends on how much the app does, how many kinds of user it has, what it connects to, how much data has to be moved and whether it is a web application or an installed app. Our article on how much it costs to develop an app in the UK gives worked figures.
Give suppliers a budget range. A supplier can do more with “between this and that” than with a single figure or silence, and a clear scope is what makes a fixed price possible.
The running costs are the ones people leave out of the business case:
- Hosting, charged monthly.
- Maintenance: security updates, fixes and the small changes every live system needs.
- App store costs, if it is an installed app. Apple charges an annual membership fee for its developer programme and Google a one-off registration fee for a Play developer account. The app also has to be retested each year when new versions of iOS and Android arrive.
- Third-party services charged by usage, such as text messages, mapping or card payments.
- Your own time. Somebody in the business has to answer the developers’ questions, test what is delivered and decide what happens next.
Ask for a delivery date along with the price. Time depends on scope in the same way cost does, and a supplier who has understood the scope should be able to commit to both.
5. Who will own it, and who will look after it?
Paying for software does not by itself make you its owner. In the UK the copyright in commissioned software normally stays with whoever wrote it unless the contract says otherwise. Check what your contract says before you sign, and take legal advice if it is unclear. Our answer on who owns the source code of bespoke software explains what to look for.
Ownership on paper is not enough if you cannot get at the thing itself. Make sure these are held in the company’s name:
- the source code, in a repository you can log in to;
- the hosting account;
- the domain name;
- the Apple and Google developer accounts, if there are any.
Then ask who looks after it. Faults will need fixing and the business will change, so decide before launch who does that work and on what terms. Ask what would happen if the supplier closed, or if a lone developer became unavailable.
Inside the business, name one person who owns the app: who decides priorities, signs off changes and hears the complaints. Plan the launch as well. Staff need showing how it works, and the old spreadsheet or paper form has to be retired on a known date, or you will end up running both.
What to do next
Write your answers down. Our software project planning worksheet covers the same ground and ends with a one-page snapshot you can send to suppliers. Send the same page to each of them, so that the quotes describe the same piece of work.
Then watch how they respond. A supplier who comes back with questions about your data, your other systems and what “finished” means has read it properly. A price that arrives the same day with no questions asked is a guess.