Do You Really Need an App? Seven Questions to Ask Before You Build

The business situations in this article are fictional illustrations, not accounts of Parikh Advisory client engagements.

Three quotations were open on the founder’s laptop. All three looked persuasive.

The first agency proposed a polished mobile app with a parent dashboard. The second included attendance tracking, automated reminders and a digital wallet. The third had a beautiful prototype and an ambitious delivery calendar. Everyone agreed that the business needed to become more digital. The only disagreement was how much the app should cost.

Then someone asked a question nobody had prepared for: What do the parents actually complain about?

The founder of this imaginary after-school tutoring business began listing the calls and messages received that week. A parent had missed a rescheduled class. Another had paid but could not tell whether the payment was recorded. A teacher had sent a new timetable to the wrong WhatsApp group. One family wanted an invoice.

Not one of those complaints was about the absence of a mobile app.

That doesn’t mean an app would be wrong. It means the team had chosen a solution before agreeing on the problem. And those are two very different decisions.

This situation is illustrative, not a claim about a real Parikh Advisory client. But the dilemma is recognizable to anyone who has been offered software before anyone has understood how their business works.

The question behind the app question

When founders ask, “Do we need an app?”, they usually mean something more consequential. Do we need a more dependable way for customers to interact with us? Can we reduce manual work? Can this business scale without hiring more coordinators? Will technology make us appear credible?

Those are legitimate ambitions. Yet they lead to different solutions. A responsive website may be enough for occasional bookings. A good CRM or scheduling tool may already solve the operational problem. A private portal might make sense where users return frequently and need to review sensitive information. A native mobile app may be justified when offline capabilities, device integrations, persistent engagement or a strong mobile distribution model genuinely matter.

Software format should follow user behaviour and operating requirements. It shouldn’t become the goal in its own right.

The UK Government Digital Service describes this principle in its Service Standard. It asks teams to understand the user’s wider task, not simply the screen or form in front of them, and to solve the whole problem where practical. It specifically cautions against organizing a service around a preselected technology. That is public service guidance, not proof that any particular commercial app failed. The underlying principle is still useful to a founder: observe the whole journey before selecting the container. [1] [2]

First, follow one parent through a normal week

Go back to our tutoring founder. Rather than opening the agency proposals, imagine sitting beside the administrator for a day.

At 8:30 a.m. the administrator changes Thursday’s class time because a teacher is unwell. The booking spreadsheet is updated. Two groups must receive separate messages. One parent replies privately asking for a different slot. At 10 a.m., finance checks incoming transfers against a list of student names. Someone used a family member’s bank account, so the payment cannot immediately be matched. In the afternoon, another parent asks whether the lesson is online or in person.

Now we can see at least four distinct jobs: scheduling, notification, reconciliation and service information. They share a customer but not necessarily the same technology requirement.

An agency might propose a screen for each job. The founder should first ask whether the business rules are clear enough to implement: Who may reschedule? What happens after a cancellation deadline? What counts as a paid booking? Who resolves an unmatched payment? Who can see a child’s information? Without those answers, even beautiful screens make ambiguity faster.

This is where a practical flow map helps. Not an architectural diagram full of boxes labelled API, but a customer journey showing the person involved, the action taken, the system of record, the exception and the person responsible for resolving it.

The founder can then identify which pain points would be solved by changing a process, which can be handled by existing tools, and which justify a new product.

Seven questions worth answering before signing a build contract

1. What repeated job would the software make easier?

Write down the action without naming the technology: “Parents should be able to book and pay for a class without waiting for an administrator.” That is clearer than “We need an app with a dashboard.” It gives the team an outcome against which to test every proposal. If the job occurs twice a year, an installed app may create more friction than it removes. If users interact every morning, the answer may be different.

2. What happens today, including when something goes wrong?

Don’t describe the ideal flow; follow the real one. Watch someone cancel late, pay from an unexpected account, lose connectivity or forget a password. In our story, the difficult part isn’t sending the reminder; it is knowing which schedule is authoritative when someone changes a class. The cost of an unhandled exception can be greater than the cost of the routine transaction.

3. Does the business already pay for a tool that can do this?

Review the capabilities and limitations of the scheduling system, CRM, payments provider or website you already use. Be wary of the sunk-cost argument—an existing tool isn’t necessarily the right one. But the cost of a new build includes more than its quotation. There is hosting, monitoring, security, accessibility, updates, support, analytics, vendor dependencies and migration when the business changes.

4. Will customers genuinely install and return to an app?

Ask for behavioural evidence, not just enthusiastic feedback. Customers may say an app sounds useful while consistently completing their tasks through links they already receive. A useful test is to offer the improved journey through a responsive web page first, then observe completion, repeat use and support requests. If a specific native capability is the source of value, test that claim explicitly.

5. What information and responsibilities would the app inherit?

A student timetable and a child’s profile create different data and access considerations from a public class catalogue. Who can edit records? What can teachers see? How are consent, deletion and access requests handled in the operating jurisdiction? A software vendor can implement permissions, but the business must define the underlying policy and obtain appropriate specialist advice when necessary.

6. How would we know that the investment worked?

Choose two or three measures linked to the original problem. For the tutoring business: fewer schedule-related support contacts; shorter time to confirm a booking; fewer unmatched payments; a lower error rate when classes change. Measure the baseline first. “App downloads” would tell us little if parents still telephone the administrator to complete the task.

7. What is the smallest responsible test that could change our decision?

A narrow test might involve a booking form, automated confirmation and a clear payment reference. It needn’t be pretty. It does need to protect customer data, work reliably and give the team evidence. Define what result would justify the next investment and what result would cause you to stop. An experiment with no decision rule is just a smaller project.

The option nobody put in the quotation

Suppose the founder has three choices after mapping the process.

Option A: Improve the current operation. Define rescheduling rules, use one shared source of truth for classes, and standardize payment references. It is the smallest investment but may still require staff intervention.

Option B: Configure existing software. Combine scheduling and payments in a proven service, with a branded web experience. This introduces subscription and vendor dependency but may avoid maintaining custom infrastructure.

Option C: Commission the app. Build around recurring use, tailored roles and integrations that cannot be met economically by the first two approaches. This offers control but increases product, support and security responsibilities.

The choice should be made with the same criteria: customer friction, ongoing cost, speed to evidence, data responsibility, adaptability and operational capacity. Comparing a glossy full-feature quotation with an unspecified “manual process” is not a fair comparison.

In some businesses, the correct answer is immediately Option C. Imagine a field-service team that works offline across remote sites and needs device capture, local synchronization and repeat daily use. A native application may be justified by the job. Logic Before Code is not anti-technology. It is anti-assumption.

What a good founder brief looks like

Before requesting another quotation, the tutoring founder could send potential partners a short statement:

We need parents to view schedules, reschedule within agreed rules and confirm payments without an administrator reconciling every request. We currently use a spreadsheet, messages and bank transfers. We want to test an improved web-first flow with a limited group, measure booking completion and unmatched payments, and decide whether a tailored app is necessary. We need the provider to identify data, integration and support dependencies, not just design screens.

That is a much stronger brief because it gives a delivery partner permission to challenge the solution rather than merely price it.

It also reduces the risk of buying the wrong kind of certainty. A fixed-price quote can be precise about screens while remaining dangerously vague about business rules, third-party integrations, exceptions and ongoing responsibility.

What to look for in a developer’s proposal

A thoughtful proposal should explain its assumptions. It should identify what is included in discovery, which integrations depend on third-party permissions, what the client must supply, how acceptance criteria will be agreed, how data protection and accessibility will be addressed, and who owns maintenance after launch. It should describe material exclusions as clearly as features.

You don’t need a hundred-page requirements document before the first conversation. You do need enough business logic for an agency to say what it can responsibly promise and what remains uncertain.

The AWS Well-Architected Framework offers a useful technical reminder: modern systems involve trade-offs among operational excellence, reliability, security, performance, cost and sustainability. A founder doesn’t need to choose every architectural component, but should understand that the cheapest build quotation may not represent the cheapest product to own. [3]

The ending is a better question

Our tutoring founder began with three agency proposals and a question about who should build the app. The more useful question turned out to be: What is the smallest dependable service that would remove the actual friction for parents and administrators?

That may eventually produce an app. But now the team has a customer journey, known exceptions, a baseline and evidence worth gathering. The decision is no longer based on the most persuasive prototype.

If you’re at a similar crossroads, don’t start by listing features. Spend time with the person doing the work and the person living with the result. Follow one real transaction from beginning to end. Write down where it breaks. Then decide how much software the problem deserves.

That’s the value of Logic Before Code. Not less ambition—better-directed ambition.