The questions we’re asked about building apps

The earliest stage of an app project is often where the biggest decisions are made, even though there isn't any code to show for it yet. It's tempting to think that the first step is choosing a development agency or starting to write a specification, but we'd encourage you to step back from the solution for a moment.

Before deciding what you're going to build, you need to understand why you're building it. That means getting comfortable with the problem, understanding the people experiencing it and making sure there is a genuine opportunity behind the idea.

This is one of the easiest questions to get backwards. A lot of product owners start with a feature list because it's something tangible. You can write down "login", "payments", "notifications", "profiles" and "booking", and suddenly it feels as though you've defined the product.

But a list of features doesn't necessarily tell you what the product needs to do. We prefer to start with the experience we're trying to create and the problems we're trying to solve. Once we understand those, the features become much easier to work out.

Think about what your user is actually trying to achieve. If you're building a travel app, for example, the important question isn't necessarily "what features should a travel app have?" It might be "what does someone need to be able to do before, during and after their journey, and where are the points at which the current experience isn't working?"

That shift in thinking can completely change the product. Instead of adding features because they seem useful, you're considering each one in the context of a real user need and a business objective. We also need to think about what belongs in the first version.

Not everything that could eventually be part of the product needs to be there on day one. Trying to build everything at once can make a project more expensive, more complicated and harder to validate. That doesn't mean you should build a deliberately poor first version, either.

A good first version should contain enough of the right experience to solve the core problem properly. It should give users something valuable and give the business something it can learn from. The distinction is important.

An MVP shouldn't mean "the app with the fewest possible features". It should mean the smallest version of the product that can deliver meaningful value and help you learn.

That's a much more useful way of deciding what belongs in version one.

You don't necessarily need to build an app to find out whether people want it. In fact, we'd strongly recommend finding ways to learn before committing to development wherever possible.

Validation can take many forms, depending on the idea. You might speak to people who experience the problem you're trying to solve. You might research competitors and alternatives. You might prototype an experience and put it in front of potential users. You might test a particular assumption with a lightweight experiment.

The important thing is that you're looking for evidence rather than simply asking people whether they think your idea sounds good. There's a big difference between someone saying, "That sounds useful," and someone demonstrating that they have a genuine problem they're already trying to solve.

When we're working through an idea during Discovery, we're interested in understanding the behaviours behind the problem. What are people doing today? What frustrates them? What are they willing to change? What would make the proposed solution genuinely useful?

That information gives you something much more valuable than reassurance. It gives you direction. And validation shouldn't stop once development begins. Good product development is a continuous process of learning, testing and improving. The more uncertainty you can remove before making expensive decisions, the better.

Once you've established that there's a genuine opportunity, the conversation inevitably moves towards money. And understandably so. An app isn't just a development project. It's an investment in a product that will need to create enough value to justify the money, time and resources put into it.

One of the biggest misconceptions we come across is that the main cost of an app is the development itself. Development is a significant part of the investment, but launching an app doesn't mean the costs stop.

Depending on your product, there may be ongoing infrastructure and hosting costs, third-party services, API usage, analytics, monitoring and other technology costs. There are also the costs associated with maintaining the app itself, fixing issues, supporting users and keeping it compatible with new operating system versions and devices.

Then there's the product side.

Your users' expectations will change. Your business will change. Your competitors will change. New technologies will emerge. You may discover that something you thought users wanted isn't particularly useful, while another opportunity becomes much more important. A successful app therefore needs to evolve.

This doesn't mean you need a huge development team working on it indefinitely, but you should think about maintenance and future development as part of the product lifecycle from the beginning.

When we're planning an app with a client, we don't just think about what needs to exist on launch day. We also think about how the product needs to be supported, monitored and evolved afterwards. Because the real measure of an app isn't whether you managed to get it into the App Store. It's whether it continues to deliver value once it's there.

Yes, and in many cases, that's exactly what we'd recommend. The important distinction is between starting small and building something that isn't fit for purpose.

Starting small means identifying the core problem and building the experience necessary to solve it properly, while deliberately leaving less important features for later. That's a sensible product strategy because it allows you to learn from real users before making bigger investments. The trick is to make sure the foundations are right.

If you know that the product will eventually need additional capabilities, integrations or user journeys, those future requirements should be considered when the product and technical architecture are being planned. You don't necessarily need to build them yet, but you don't want to make decisions today that make tomorrow unnecessarily difficult or expensive.

We've found that the strongest products tend to evolve in stages. You start with a clear purpose, learn how people use the product, understand where the opportunities are and then use that information to decide what comes next. That gives you something much more valuable than a giant roadmap created months before anyone has used the product... it gives you a product roadmap based on evidence.

The best way to deal with a project going over budget is to understand why it happened in the first place. Sometimes it's because the scope has changed. Sometimes new technical requirements emerge. Sometimes assumptions made at the beginning turn out not to be correct. And sometimes the original scope simply wasn't defined in enough detail.

This is another reason we place so much importance on Discovery. The earlier you can identify uncertainty, the easier it is to make an informed decision about it. That doesn't mean every project can be predicted down to the last pound. Software development involves complexity, and there will always be things you learn along the way. What matters is how that uncertainty is managed.

If a new requirement appears halfway through a project, for example, you should be able to understand what it means for the timeline, budget and existing scope. You can then make a decision about whether it's important enough to include now, move something else out or leave it for a later version.

The worst situation is when changes happen quietly, and the impact only becomes apparent when the budget has already disappeared. Good communication, clear priorities and a shared understanding of the product are therefore just as important to managing a budget as the original estimate itself.

This is the part of an app project that can be difficult to explain because, at first glance, it can look like you're paying someone to talk about your app rather than build it. But the thinking that happens before development can have an enormous impact on what eventually gets built.

You don't need to have every decision made before you speak to an agency. That's what a good product team is there to help with. But there are some fundamental questions that need answering before development can sensibly begin. You should understand:

• Who the product is for
• What problem you're solving
• Why that problem matters
• What the business needs the product to achieve
• What the core user journeys look like
• Which features are essential to those journeys
• What success will look like
• Which platforms and devices are relevant
• What integrations or technical requirements exist
• What constraints the project needs to work within
• How the product might evolve after launch

The important thing is that these decisions shouldn't be made independently. Your technical choices affect your budget. Your business objectives affect your feature priorities. Your users' needs affect the experience you design. Your future plans affect the architecture you put in place today.

That's why we don't see strategy, design and technology as separate conversations. They're all parts of the same product decision.

We'd start by asking what the product absolutely needs to do to solve its core problem. From there, features can be considered against several factors: how much value they provide to users, how important they are to the business, how complex they are to build, what risks they introduce and whether other features depend on them.

This is where prioritisation becomes useful. Imagine you have twenty potential features. If you simply ask, "Would this be useful?", you might end up saying yes to all twenty. Instead, ask: If we don't build this, can the product still solve the core problem?

If the answer is yes, that feature might not need to be part of version one. That doesn't mean it isn't valuable. It might simply mean that its value can be explored later, once you've learned more about the product and its users.

We've seen projects become considerably more complicated because the first version was treated as an opportunity to build every idea anyone had ever discussed. The better approach is to create a focused product that does the important things well, rather than an enormous product that tries to do everything.

The answer is usually somewhere in between. Customers are an incredibly important source of information, but their requests shouldn't automatically become product requirements. If ten customers ask for a particular feature, that's useful information. But the next question should be: what problem are those customers trying to solve?

A customer might ask for a specific feature because they've already imagined the solution. That doesn't necessarily mean their proposed solution is the best one. The same applies to the business.

A feature might be strategically important to the organisation, but if customers don't understand it, can't use it or don't see the value, it may not achieve what the business expects.

The role of product strategy is to bring those perspectives together. We look at what customers need, what the business needs to achieve, what the evidence tells us and what is technically and commercially realistic. That allows you to make decisions based on the bigger picture rather than simply building the loudest request.

Customer feedback becomes useful when you stop treating it as a list of instructions and start looking for the problems underneath it. Imagine a customer says, "We need a better search." That's a useful observation, but it isn't necessarily a requirement to redesign the search function.

• Why isn't the current search working?
• Are people struggling to find particular information?
• Are they using the wrong terminology?
• Are there too many results?
• Are they looking for something that doesn't exist?
• Is search even the right solution?

Those questions can lead you towards a much better product decision.

We recommend looking for patterns rather than reacting to individual comments. Combine qualitative feedback with quantitative information wherever possible, and consider what you're hearing alongside your wider business objectives. One person's request shouldn't automatically determine your roadmap. But repeated evidence of a genuine problem absolutely should influence it.

This is where good product teams earn their keep. Our job isn't simply to take everything a client or customer says and turn it into a feature. It's to help interpret the information, challenge assumptions and work out what will genuinely improve the product.

AI has introduced a slightly different set of questions for anyone thinking about building a digital product.m The most common one is probably some variation of: if AI can do more of this for users, do we still need an app? It's a fair question. But we think the answer is more interesting than simply saying apps are here to stay.

We think people will continue to use apps, but the way they interact with products is likely to change. For years, the dominant model has been that a user opens an app, navigates through its interface and performs an action. AI introduces another possibility.

Instead of navigating through an interface, someone might simply tell an assistant what they want to achieve and let it work out the steps. That doesn't make the underlying product irrelevant. It changes the relationship between the user and the product.

A travel company, for example, may still need an app where customers can manage bookings, access important information and complete tasks. But there may also be value in allowing an AI assistant to retrieve that information, make changes or perform actions on the user's behalf.

So the question we would ask isn't, "Will AI replace my app?" It's: Where will my users expect to interact with my product in the future? That might still be a mobile app. It might be a web experience. It might be through an AI assistant. It could be several of these at once.

The strongest products will be prepared for that reality rather than assuming there will only ever be one interface between the user and the service.

Increasingly, we'd argue that you should be thinking about both. Your human users still need an experience that makes sense to them. It needs to be understandable, accessible and enjoyable to use. But if you want AI agents to interact with your product, there are other considerations. Can an agent:

• understand what your product does?
• access the information it needs?
• securely perform actions?
• structure systems in a way that allows those actions to happen reliably?

This means thinking beyond the interface.

An app isn't just the screens someone sees. Behind those screens are APIs, data, authentication, permissions, business rules and systems that make the experience possible. As AI becomes another way of interacting with those systems, the underlying product architecture becomes increasingly important.

This is something we're particularly interested in at The Distance because we've been exploring the idea of products existing beyond a traditional visual interface. The future isn't necessarily about choosing between a beautiful app and an AI agent. It may be about building a product that can support both.

No. And we'd be suspicious of anyone who told you that every new app does.

AI is incredibly useful when it's solving a problem that genuinely benefits from it. But adding AI simply because it's currently popular can introduce unnecessary cost, complexity and uncertainty.

Start with the problem. If users need help understanding large amounts of information, generating content, making sense of complex data, interacting conversationally or automating a task that requires judgement, AI might be a very good fit.

But sometimes a normal feature is better. If someone needs to press a button to book a ticket, there's no reason to introduce an AI model just for the sake of it. Good technology choices aren't about using the newest technology available. They're about choosing the technology that helps you solve the problem effectively. AI should be treated in exactly the same way.

Once you've worked out what you're building, you need to make sure people can actually use it. And this is where good app design goes considerably further than making something look nice.

You can't assume that everyone will experience your app in exactly the same way. Different phones have different screen sizes, aspect ratios, resolutions and capabilities. People can also change text sizes, accessibility settings and display preferences, while operating systems introduce their own conventions and behaviours.

That's why responsive and adaptive thinking needs to be part of the design process from the beginning. Rather than designing a single screen at a single size and hoping it scales correctly, you need to understand how the interface behaves across different conditions. Such as:

• Where does content wrap?
• What happens when text becomes larger?
• Does an important button remain accessible?
• What happens on a smaller screen?
• What happens when someone rotates their device?
• Can someone using assistive technology understand what's happening?

These are part of designing a product that works for real people. And testing is just as important as design here. A design can look perfect in a design tool and behave very differently when it's running on an actual device.

Not necessarily. Your iOS and Android products should feel like the same product, but that doesn't mean every interaction needs to be identical. Both platforms have established conventions around navigation, controls, gestures and interaction patterns. Users have developed expectations based on the devices they use every day.

Ignoring those conventions can make an app feel unfamiliar, even when the underlying functionality is exactly what the user needs.

At the same time, you don't want to create two completely unrelated products. Your brand, visual identity, core journeys and overall experience should feel consistent. The trick is understanding where consistency matters and where adapting to the platform creates a better experience.

That's something we consider during the UX and UI design process rather than simply taking one set of screens and copying them across both platforms. Good cross-platform design isn't about making everything identical. It's about making everything feel intentional.

Getting an app into development can feel like the main challenge, but the final stages of a project raise some equally important questions.

The App Store and Google Play remain important distribution channels for mobile apps, but they aren't necessarily the only way people should interact with your product. The right answer depends on what you're building and how your users behave.

Some products benefit enormously from being installed on a phone. If someone uses the product frequently, needs notifications, relies on device capabilities or wants quick access, a native app can make a lot of sense. For other experiences, a web app or progressive web experience may be more appropriate.

And as we've discussed, AI assistants are creating another potential channel through which people can interact with digital services. So rather than starting with the assumption that you need an App Store app, we'd recommend starting with the user journey.

Where will your customers be, what will they be trying to do and what is the most useful way for your product to meet them there?

The answer might be an app. It might be a web experience. It might be both. The important thing is that the technology follows the product strategy rather than the other way around.

This is a deceptively difficult question…

• Does "done" mean the developers have finished writing the code?
• Does it mean the app has passed QA?
• Does it mean it's been submitted to the App Store?
• Does it mean users can download it?
• Or does it mean the product is achieving the outcomes you originally wanted?

We'd argue that all of those are milestones, but none of them necessarily mean the product is finished.

A development team might complete everything in the agreed scope, only for the product team to discover after launch that users are struggling with a particular journey. That's not necessarily a sign that development failed. It's a reminder that software products exist in the real world, where people behave in ways that aren't always predictable.

We therefore think about "done" in stages. A feature can be development complete. It can be tested. It can be ready for release. It can be live. And then it needs to prove its value. That last part is often overlooked. Launching an app isn't the end of product development. It's the point at which you finally have the opportunity to learn from real usage at scale.

Because your phone isn't everyone's phone. An app that works perfectly on one device can behave differently elsewhere because of differences in screen size, operating system versions, hardware, network conditions, permissions, settings and other factors.

Then there are the situations you probably don't encounter during your own testing, such as:

• What happens when someone loses their internet connection halfway through an action?
• What happens if they enter something unexpected?
• What happens if they deny a permission?
• What happens when the device has very little storage?
• What happens when the app is interrupted?
• What happens when an operating system update changes something your app relies on?

Testing is about finding those situations before your users do. It's also about more than checking whether buttons work. Good QA considers functionality, usability, performance, accessibility, compatibility and the wider experience.

This is why we treat testing as part of the development process rather than something that happens at the very end as a final tick-box exercise. The earlier you find problems, the easier they generally are to address. And the less likely your users are to become the people who discover them for you.

If there's one thing we hope you take away from all of these questions, it's that building an app isn't really about answering, "How quickly can we get this developed?"

It's about making good decisions in the right order. Before:

• you worry about individual features, understand the problem.
• you decide how much to spend, understand the opportunity.
• you start development, understand what the first version genuinely needs to achieve.
• choosing technology, understand the product and the people using it.
• adding AI, understand whether AI actually solves the problem better.
• launching, test the product in the real conditions your users will experience.

And once the product is live, keep learning.

The best app projects we've worked on aren't the ones where every decision was somehow perfect from day one. They're the ones where there was a clear process for asking questions, challenging assumptions, testing ideas and using what we learned to make better decisions. That's ultimately what good product development is about.

You don't need to arrive at your first conversation with an agency knowing exactly what needs to be built, which technology should be used or what every screen should look like. In fact, if you already have all of those answers, it's still worth asking whether the assumptions behind them have been tested.

What you do need is a clear understanding of the problem you're trying to solve and a willingness to explore the best way of solving it. That's where we come in.

At The Distance, we work with businesses from the early stages of an idea through strategy, Discovery, UX and UI design, development, testing, launch and ongoing evolution. Our role isn't simply to take a specification and turn it into an app. It's to help you make the decisions that give the product the best possible chance of succeeding. Because ultimately, the goal isn't to build an app. It's to build the right product.