Why an app is always bigger than its brief

Every app starts with a conversation about what it should do. The one my father and I are planning is no exception. When we started talking about it, we naturally talked about the main thing: what it should do and who it should help.

I did not have the whole picture either, even though building apps is my work. I realised that in conversations like this, everything around the main features gets put off: sign-in, settings, error states, administration. Neither of us is at fault. Nobody talks about these things until someone writes them down.

Throughplan came from that experience. I wanted a tool that asks us these questions before we start building. I will not go through our app here. The same thing shows on a brief of the kind an agency or a freelance developer receives all the time, and it is the brief that shows how far it is from four sentences to a finished app.

Whoever pictures an app sees one good day. The user opens it, does what they came for, and leaves satisfied. That day is short and easy to follow, which is why the whole app looks smaller than it is.

Most of the work hides in all the other days. The ones when something fails, when the user changes their mind, or when another person with a different role steps in. These days are usually missing from the brief. The client is not hiding them. They have simply not run into them yet.

Picture this email arriving at an agency on a Monday morning:

“We need an app for our repair service company. A customer orders a repair in it, we assign a technician, and the technician closes the job when the repair is done. The customer pays by card. It is nothing complicated, basically three screens.”

It sounds reasonable, and it is tempting to reply with a price the same day. Three steps, three screens: order, assign, close. But let us take this brief through one ordinary week of a repair company.

On Monday it already turns out that more than one person opens the app. A customer has a leaking washing machine and orders the repair from her phone. A technician sits in a van between two visits and needs to see where he is going and what is waiting there. In the office sits a dispatcher, who assigns the jobs and needs the workload of every technician in front of her at once.

The brief does not mention the fourth person at all. The owner of the company wants to see the revenue at the end of the week and adjust the price list now and then. That makes four roles and three separate interfaces, two mobile and one on the web. Three screens are no longer on the table, and it is only Monday.

On Tuesday the customer cancels the order, because she sorted it out another way. May she do that when the technician is already on the way? On Wednesday the technician falls ill and someone has to take over his jobs, and the customers should hear about it before they wait for nothing. On Thursday his colleague arrives at an address and nobody opens the door.

The repair itself does not always go smoothly either. A spare part is missing, the job waits and needs a second visit. The repair turns out more expensive than expected, and the customer has to approve the new price. The card payment fails. And a week later the fault is back and a complaint comes in.

One week was enough to turn three states into eleven: new, assigned, technician on the way, in progress, waiting for a part, waiting for price approval, completed, paid, cancelled, customer not reached and under complaint. Every state means a screen, a notification or a rule, and often all three.

Underneath all of that runs a layer the brief does not mention at all, because everyone takes it for granted. The customer has to sign up, sign in and be able to recover a password. They expect a message that the technician is on the way, that the repair is done and that the payment went through. After paying, they want an invoice or at least a proof of payment.

It is the same on the company side. Someone has to manage the price list, and it has to be decided who may change it. Technicians have working hours and areas they cover. Photos before and after the repair are worth having. A technician often works in a cellar or a boiler room with no signal, which raises the question of whether the app should work offline. And finally personal data: who sees the addresses and phone numbers of customers, and how long they are kept.

None of it is interesting, and none of it can be left out.

Some questions even the most experienced supplier cannot answer, because they are not technical. They are decisions about how the company wants to work. Does the customer pick the time, or does the company propose it? Is the payment taken in advance, or after the repair? Does the customer know the price before ordering? Does the company use a system the app has to connect to?

Each of these four answers changes the scope. And a question that is not asked before the estimate does not go away. It waits for development, where every change costs more.

Say the client answers like this: the customer picks the time, pays after the repair and sees the price in advance as an estimate. Only now can the app be written out honestly, role by role.

The customer first signs up and signs in, which with password recovery makes three screens. The order takes three more: the description of the fault with photos and the address, picking the time, and the summary with confirmation. They then follow their jobs in a list and in a detail with the current state. Money adds the approval of a price change, the payment and the proof of payment. That leaves the complaint and the profile with addresses. The customer has 13 in total.

The technician needs fewer. They see the jobs for today and the detail of each, and they record the repair in progress with photos and notes, and the material used along with any price change. They either close the job or postpone it, when the customer was not reached or a part is missing. The technician has 6 in total.

The dispatcher works in a web interface. They need an overview of new jobs, the calendar of technicians, a screen for assigning and moving a job, its detail with history, the complaints and the list of customers. The dispatcher has 6 in total. The owner is left with the revenue overview, the price list, the technicians with their working hours, the service areas, and users and permissions. The owner has 5 in total.

Together that is 30 screens for 4 roles, a job with 11 states and 4 decisions the client had to make. Monday’s email said three screens.

I leave out the number of hours on purpose, because it depends on the team and the technology. The ratio holds either way: a quote built on three screens prices a tenth of the screens that will have to be delivered. The difference does not come from estimating hours badly. It comes from the first number pricing an idea and the second one pricing a plan.

The client behind Monday’s email hid nothing. They described their one good day, as any of us would. A brief describes the main path, and most of the scope lies outside it. That is why it pays to start with the roles, because every kind of user brings their own screens and permissions, and to add for every step what happens when it fails.

An estimate only makes sense on top of a plan. Until the screens and states are written down, what gets priced is a picture in someone’s head. And the open questions belong in front of the client before signing: they are part of the quote, not a flaw in it.

This is the process Throughplan is built for. It asks about what the brief leaves out and does not fill it in with guesses. From the answers it puts together the screens and the flows between them, and it works out the estimate from those. So that all those other days are found before anyone starts building.