How app development starts and ends with your customer?

A pre-launch founder in the football industry came to us with a colour-coded spreadsheet mapping out every competitor product in the space. It was thorough, methodical, and completely focused on what other products were doing. What it did not contain was a single data point about what users actually felt. Not what features they wanted. Not what they clicked on. What they felt, before they opened an app, while they were using it, and after they put their phone down.

The assumptions baked into a brief at week two become the architecture of the product six months later.

That gap, between competitive analysis and emotional understanding, is where most app projects go wrong. And it tends to go wrong quietly, in the early weeks, when the decisions being made feel provisional. They are not provisional. The assumptions baked into a brief, a scope, or a budget estimate at week two have a way of becoming the architecture of the product six months later.

Building an app that people actually use, return to, and recommend starts with understanding the person who will open it. That sounds obvious. It rarely happens in practice. What follows is an account of what proper customer understanding looks like, what it costs to skip it, and how it changes how you build and what you build entirely.

What 'Starting With the Customer' Actually Means in App Development

Starting with the customer is not the same as conducting a survey or commissioning a competitor audit. Those things have value, but they describe behaviour from the outside. They tell you what people do, not why they do it, and rarely capture how people feel about the thing they are already doing.

Our discovery process begins with a different set of questions. Who is this brand as a person? What is this product as a person? How does it interact with the people who use it? These are not abstract exercises. They establish the emotional register of a product before a single screen is designed, and that register shapes everything from the copy tone to the colour palette to the order in which information appears.

Emotion before interface

Understanding the emotional state a user arrives with is, as we see it, the most underused variable in app development. A user opening a fitness app on a Tuesday morning is in a different psychological state to someone opening the same app on a Sunday evening. A user landing in a property management app because something has broken in their flat is not the same user who opens it to pay a service charge on a quiet afternoon. The user journey begins before the app opens, and the design needs to account for that entry point.

What customers feel about what they already do

We always ask what users are currently doing to meet the need a product claims to address, and how they feel about that. If someone is reasonably happy handling something manually, a technical solution offers them friction, not relief. The product has to earn its place in a user's life, and that argument begins with understanding whether the gap the client has identified actually feels like a gap to the people who are living it.

Why Assumptions Made at the Brief Stage Are So Expensive

The brief stage feels like planning. It is actually decision-making. Every assumption that goes unchallenged at briefing becomes a specification, and every specification drives engineering time. A feature that seemed self-evident in week one and turns out to be wrong in week twelve does not just cost the time to remove it. It costs the time to build it, the time to test it, and often the time to unpick the architecture that depended on it.

According to Devtimate, projects that skip discovery are three to five times more likely to fail or exceed budget. That figure reflects something we have seen in practice. The mismatch between what a founding team assumes and what a real market needs is almost always present at the brief stage, and almost always invisible until someone goes looking for it.

We worked on a product aimed at expats living abroad across various countries. The scope, on paper, seemed clear. The client had formed a definite view of what their market needed. The discovery phase revealed that what the market actually needed was very far from those assumptions. Catching that early saved the client significant time and money that would have been lost building something not fit for purpose. Had development started from the original brief without that investigation, the gap would have surfaced only after substantial build time had been spent on the wrong product.

The further into development an assumption travels before it is tested, the more expensive it is to correct. That is the core argument for doing the hard thinking at the start.

What Proper Discovery Looks Like Before a Line of Code Is Written

Discovery, done properly, is more than a requirements-gathering exercise. It involves understanding the psychology of the people who will use the product, the emotional context they bring to it, and whether the product as imagined actually addresses a real need or a projected one.

We worked with a property developer building a concierge app for high-rise residential buildings. They arrived with a budget, a set of planned features, and a clear idea of what they wanted to build. What they were looking for was validation. We persuaded them to run a proper discovery phase, including focus groups with residents and user workshops. What came back from that process was not what anyone expected.

The product the client imagined building and the product residents actually needed were not the same thing.

The product residents actually needed was far simpler than the client had envisaged. Many of the planned features were dropped. The focus shifted from replacing existing building systems to creating a genuine human connection with the product. The result was a better product at a lower cost, and one that residents would actually use rather than ignore.

A ballpark estimate, made without discovery, carries roughly fifty percent accuracy. A paid discovery phase reduces that to somewhere between ten and twenty percent, according to Devtimate. The investment in discovery is, in practical terms, an investment in having a reliable number to work from.

Run at least one session with real users before writing a feature list. What they tell you about their current process will almost always reshape your initial assumptions.

When Skipping Discovery Costs You More Than Discovery Ever Would

The dating app project is the clearest example we have of what happens when discovery is applied selectively rather than across a whole product. The client was building a platform centred on verified profiles and the prevention of bots and fake accounts. The onboarding process received thorough discovery work, careful design, and rigorous verification logic. The messaging component did not.

The client wanted to skip discovery on messaging and focus resources on onboarding. The consequence was a generic messaging feature that directly contradicted everything the onboarding was designed to protect. The verified, carefully screened onboarding fed into a messaging system that allowed automated and fake messages with no friction. The behaviour the product was built to prevent was being enabled by one of its own features.

The cost of a single skipped discovery phase

That mismatch required a complete rewrite of the messaging section. The additional cost was approximately £15,000 in development budget and two extra months of work. The discovery that would have prevented it would have cost a fraction of that. And the delay, in a competitive space where verified profiles were the product's central proposition, carried its own market cost on top of the financial one.

Coherence across a product requires discovery across a product

A product is not a collection of independent features. Each component works in relation to the others, and an assumption left untested in one area can undermine careful work done in another. Discovery applied only to the parts the client finds interesting is selective investment in coherence, and incoherence tends to surface at exactly the wrong moment.

How Discovery Changes What You Build, Not Just How You Build It

The concierge app project is a good illustration of how discovery changes the product itself rather than just the way it gets made. The client came in wanting two things: a full building management utility and a community-building social tool. Those two goals pull in different directions, and trying to serve both equally tends to serve neither well.

We ran focus groups with social housing tenants to understand what actually builds community among people who share a building. The finding was specific. Community forms through familiarity, knowing neighbours' names, interests, families, and pets. A digital tool that replaces conversation does not build familiarity. A digital tool that handles the mundane administrative parts of building life, freeing people to have conversations rather than sending complaints, does.

From directory to social network

That insight changed the architecture of the product. What started as a building directory and maintenance logger became a product with a social feed at its centre. Residents could post content, ask neighbours for help, and follow updates from the concierge team and local charities. Building management features were a secondary layer rather than the core experience. The product did not grow by adding features. It was redesigned around a different primary purpose, and that redesign came entirely from listening to users before any build work began.

If your product has two goals that feel equally important, run user research on both separately. You will almost always find one is what people actually want and one is what you assumed they would want.

When Two Goals in One App Are One Too Many

Products that try to do two distinct things tend to do both of them poorly. This is less about scope and more about focus. A product with a clear primary purpose makes a clear promise to its user. A product with two equally weighted purposes asks users to decide which one they showed up for, and that moment of ambiguity is, in most cases, the moment they leave.

The property developer's original brief contained this tension explicitly: a utility product and a social product in the same app, given equal billing. That combination is not impossible to build, but it is very hard to build well without first understanding which one users actually want to open an app for. Our focus group work answered that question and gave the product a clear centre of gravity.

What founders often miss about dual-purpose products

Founders often arrive at the dual-purpose brief through a reasonable chain of logic. The product handles X, and users who handle X also care about Y, so the product should handle both. The logic is sound. The problem is that handling X well and handling Y well require different designs, different user flows, and often different emotional registers. Combining them without user input produces a product that is technically capable of both and emotionally suited to neither.

The discipline lies in knowing which goal the product should serve first, and letting that decision be made by the people who will use it rather than the people who are building it.

Test your product's primary purpose with five users before committing to a feature list. If they describe the product differently from how you would, that difference is the insight you need.

How Customer Insight Should Shape Every Stage After Discovery

Discovery does not hand you a finished product. It hands you a set of grounded decisions to build from. The insight gathered in discovery needs to travel through every subsequent stage, from information architecture through visual design to copy and testing. If it only informs the brief and then gets filed, the product drifts back toward assumptions as development progresses.

The emotional state a user arrives with should inform the priority of information on the first screen they see. The language patterns that came up in user interviews should shape the copy. The anxieties users expressed in workshops should be addressed visually, not just functionally. These are the difference between a product that users feel was built for them and one that they feel was built.

Involving users beyond the discovery phase

After every product launch we have worked on, user feedback has taken the product in directions the internal team did not anticipate. Real market response does not simply validate or reject the product as built. It redirects it. The founders and teams who handle that well are the ones who involved their target audience in the conversation early and kept them involved, so redirection feels like progress rather than failure.

That means building a feedback loop, not just a feedback mechanism. A feedback form is not the same as an ongoing conversation with the people using the product. The latter changes how subsequent decisions get made. The former collects data that tends to be read when something goes wrong.

Why Some Projects Should Not Go Ahead at All

We walked away from a project involving a social product because the client wanted to go directly into redesigns without any discovery work. The product was not obviously broken. The request was not unreasonable from a certain angle. But proceeding without understanding who the users were, what they needed, and how they felt about the existing product would have meant designing from assumptions rather than evidence. We declined the work rather than do it that way.

This is not a stance taken to be difficult. Discovery is the part of our process that makes everything after it reliable. Skipping it means the design decisions that follow are based on internal opinion rather than external reality, and internal opinion, however informed, is not a substitute for talking to users. According to CB Insights, thirty-five percent of projects fail because there was no real market need. Discovery is how you find out, before you build, whether the need is real or assumed.

When a pivot is the right answer

Sometimes discovery does not lead to a better version of the original plan. It leads to a different plan. When we ask the right questions and the answers point toward a fundamentally different product, we say so. That is not a failure of the brief. That is the discovery process doing exactly what it is supposed to do. A client who leaves discovery with a different product than the one they arrived with has saved themselves the cost of building the wrong one.

And occasionally, the right answer is to stop. A product that addresses a need nobody actually has, or one the market is already meeting in a way people prefer, does not become viable because someone builds it carefully. Saying that early is the most useful thing we can do.

How to Know Whether You Genuinely Understand Your Customer

There is a practical test for this. Ask your team to describe the user's emotional state at the moment they open the app for the first time. Not what they want to do. How they feel. If the answers are vague, or if different people in the room give different answers, the team does not yet have the understanding they need to design for that user reliably.

Founders who have done genuine customer research tend to speak about their users with specificity. They can describe what a user was doing before they opened the app, what they were trying to avoid, what would make them feel like the product had worked. Founders who have not done that research tend to describe their users by demographic and desired behaviour. These are not the same kind of understanding, and they produce different products.

What good research actually produces

Good research produces decisions, not just data. The output of a discovery phase is a set of specific, defensible choices about what the product will do, for whom, and in what emotional context. Those choices are the foundation the rest of the project builds on. When they are solid, the build phase moves faster because fewer decisions need to be relitigated. When they are absent, the same arguments happen at every stage of development, and they get settled by seniority rather than evidence.

1. Can you describe your user's emotional state when they first open the app?
2. Do you know what they are currently doing to meet the need your product addresses?
3. Have you spoken to users about how they feel about that current process?
4. Can you name one assumption from your original brief that research changed?
5. Does your team agree on the product's single primary purpose?

If any of those questions produce hesitation, that hesitation is the gap discovery fills.

Conclusion

Every project we have worked on has confirmed the same thing in one form or another. The gap between what a founding team believes their users need and what those users actually need is almost always present, and almost always closable, if you look for it early enough.

The property developer who came to us for validation left with a simpler, better product. The dating app client who skipped discovery on messaging spent £15,000 and two months correcting a problem that discovery would have cost a fraction of that to prevent. The expat product client avoided building something the market did not want by understanding what the market actually needed before the build began. These are illustrations of what happens when the customer is genuinely at the centre of the process, and what happens when they are not.

Understanding your customer is the real work. Everything built after it either reflects that understanding or works against it.

If you are at the point where a brief exists but real user understanding does not, or if you are further along and something feels misaligned, let's talk about your product and where that gap might be.

Frequently Asked Questions