The Case Study That Convinced Us Discovery Isn't a Cost, It's an Insurance Policy

A client came to us with a dating app built around a genuine problem worth solving. The online dating space is full of fake profiles, automated bots sending scripted openers, and the steady erosion of trust that follows. Their product set out to fix that by verifying every user before they could interact with anyone else. The onboarding process was thorough, considered, and genuinely well thought through. They had invested real time in understanding the problem and real money in solving it properly.

Skipping discovery on one component cost £15,000 in rework and two months of additional work.

Then they asked us to skip discovery on the messaging feature, because they were confident they already knew what it needed to do.

What followed became one of the clearest illustrations we have seen of why discovery cannot be applied selectively. You cannot verify one half of a product with care and build the other half by assumption. The two halves talk to each other, and when they contradict each other, the whole thing breaks. This is that project, and what it taught us about treating discovery as something you budget for upfront rather than pay for at the back end.

The Product and Its Central Promise

The dating app had a clear premise. Fake profiles and automated messages had become so common on mainstream platforms that a meaningful portion of users had stopped trusting the interactions they were having. The client's answer was verification. Every person who signed up went through a process designed to confirm they were a real human being, using a real identity, genuinely present on the platform.

This was the product's entire reason for existing. The trust was the product. Without that, it was just another dating app competing on features and interface against platforms with far larger budgets and far larger user bases. With it, the product had a genuine differentiator and a real audience of people who had grown frustrated with the alternatives.

We worked closely on the onboarding process. The verification flow was carefully designed to feel reassuring rather than bureaucratic, building the user's sense of security as they moved through each step. The design communicated credibility without feeling clinical. By the time a user completed onboarding, they understood what the app stood for and why the extra steps were worth it.

The onboarding was good work. The problem was that good work in one part of a product does not protect you from weak work somewhere else.

The Decision to Skip Discovery on Messaging

The client's reasoning was understandable. Messaging is a solved problem, or so it seemed. Every dating app has a messaging function. Every user knows how to send a message. The interaction pattern is familiar, the interface conventions are well established, and there is no shortage of reference points to build from. Discovery felt like spending money to confirm something they already knew.

They also had budget pressure. Investing heavily in the verification and onboarding process meant that the messaging feature needed to be delivered efficiently. Commissioning a full discovery phase for a component they considered straightforward felt like a cost that was hard to justify at that stage of the project.

So they made the call to proceed without it. We flagged the risk. They weighed it against the cost and timeline and decided to move forward. That is a legitimate decision for a client to make, and we respected it. But we did want the risk on record, because the messaging component was not separate from the product's core promise. It was where that promise would either hold or fall apart.

Discovery is about understanding what the product is trying to do and whether every part of it is working towards the same thing.

What Was Built Without Discovery

Without a discovery phase to anchor the messaging feature to the product's specific context, what got built was a generic messaging system. It was functional. It allowed users to exchange messages in a familiar interface. It was not broken in any technical sense. But it had been designed against a template of what dating app messaging usually is, rather than against what this particular dating app needed messaging to be.

A generic messaging system does not discriminate between message types. It accepts input from users and delivers it. That is, broadly, what messaging systems do. The problem was that this product existed specifically because automated, scripted, fake messages had made other platforms untrustworthy. And the messaging feature, as built, had no mechanism to address that.

A generic messaging system had no mechanism to prevent the exact behaviour the product was built to eliminate.

Users who had been carefully verified during onboarding entered a messaging environment that could still receive automated messages. The behaviour the product promised to prevent was permitted by the product itself. The onboarding said: you can trust the people here. The messaging said: or maybe you cannot. That contradiction sat at the heart of the user experience, and it was invisible until the build was complete.

When you build any feature in isolation, ask what assumption that feature makes about the rest of the product. If the answer is "the same assumptions as any other app in this category, " that is a signal that discovery is missing.

How a Generic Feature Undermined a Verified Product

The contradiction was not abstract. A user who had gone through a careful verification process, who had given time and personal information in exchange for a promise of authenticity, could still receive a message that read like it had been generated by a script. They had no way to know whether the person on the other end was the verified human from their profile or an automated system mimicking one.

This matters because trust, once questioned, does not recover gradually. Users do not think "this message feels automated, but the onboarding was thorough, so I will give the benefit of the doubt." They think "this message feels automated, " and the doubt spreads backwards. The thing they signed up to trust becomes the thing they now question.

The onboarding had done its job. It had created a genuine expectation of authenticity. The messaging feature then created an experience that conflicted with that expectation. As Simon has described it: "Even though we'd put so much emphasis on the onboarding and validation and verification, that didn't then stack up with the other parts of the product, particularly around the messaging side of things."

The product's central promise was not just undermined. It was undermined by the product itself, from the inside. That is a different problem from a competitor undercutting you, or the market moving, or a technical failure. It is a problem of internal incoherence, and it comes from building components in isolation.

The Cost of Finding Out the Hard Way

Rewriting the messaging section cost approximately £15,000 in additional budget and two months of additional work. Those are the hard numbers. But they do not capture the full picture.

Two months in product development is two months during which momentum slows, team focus fragments, and the launch window shifts. In a competitive market, timing matters. A product that reaches its audience six weeks late is competing against a market that has had six more weeks to evolve. The £15,000 is a clean figure. The opportunity cost of the delay is harder to put a number on, but it is real.

There is also the cost of the work that could not be done during those two months. Development resource that went into the rewrite was not available for other features, improvements, or refinements. Every hour spent correcting the messaging system was an hour not spent on something that could have moved the product forward. According to Playbook UX, engineers spend up to 50% of their time fixing problems that a proper discovery and design phase would have prevented. That figure held true here.

The discovery phase for messaging would have cost a fraction of the rework. Two weeks of structured research would have surfaced the contradiction before a single line of code was written. The £15,000 was not the cost of building a messaging feature. It was the cost of building the wrong one.

What Two Weeks of Discovery Would Have Surfaced

A app user research phase for the messaging component would have started with a simple question: what does a verified user expect from a conversation on this platform? That question sounds obvious in retrospect. It is obvious in retrospect. But without asking it formally, with real users, the team defaulted to what messaging usually looks like rather than what it needed to look like here.

The answer would have been equally clear. Users who had gone through a verification process to join a platform built on authenticity expected messaging to feel different from messaging on other apps. They expected signals that the person on the other end was real and present. They expected the interface to reinforce the promise the onboarding had made, rather than abandon it.

Discovery would also have mapped out what the messaging feature needed to prevent, not just what it needed to enable. That is a different design brief. A standard messaging system is designed to facilitate communication. This one needed to be designed to facilitate trusted communication, which is a meaningfully different thing. The discovery phase is where that distinction gets made, agreed on, and built into the specification.

Write the discovery brief for each major feature as if it is a standalone product. What is this feature trying to do? Who is using it and in what state of mind? What would break their trust? Answer those questions before you write a line of code.

Two weeks. That is roughly what a focused discovery phase for a single feature component takes. Against £15,000 and two months, that comparison is not close.

When Discovery Reveals the Market Has Different Needs Entirely

The dating app case shows what happens when discovery is skipped on one component of a product. A separate project we worked on shows a different version of the same lesson: what happens when discovery reveals that the entire product premise needs rethinking.

We worked on a product aimed at expats living abroad across various countries. The client had a clear view of what the product should do and came to us with that view already formed. On paper the scope was straightforward. In practice, the discovery phase revealed something the client had not anticipated: what the market actually needed was very far from what the client had assumed.

That gap, surfaced early, saved a significant amount of time and money that would otherwise have been spent building something not fit for market. As Simon put it at the time: "We saved a lot of time and money that way by doing the discovery phase and realising that early on rather than building something and then realising that it wasn't fit for market."

The pattern here matters. Discovery does not always confirm the brief. Sometimes it changes it. And the earlier that change happens, the cheaper it is. CB Insights have identified no market need as a factor in 35% of startup failures. Discovery is the mechanism that tests for that before the money is spent.

Why Partial Discovery Creates Whole-Product Problems

The dating app case raised a question we have thought about carefully since: why did selective discovery feel like a reasonable decision at the time? The answer is that products are mentally segmented. Onboarding is one workstream. Messaging is another. Features are conceived, scoped, and costed as discrete units, and discovery naturally follows that structure. You do discovery on the parts you are uncertain about and skip it on the parts that seem clear.

The problem is that users do not experience a product in segments. They move through it as a single thing. The expectation built in onboarding travels with them into messaging. The trust created in one screen is tested in the next. When those two screens have been designed from different premises, with different assumptions about what the product is trying to do, the user feels the join. They may not be able to name it, but they feel it.

This is why partial discovery creates whole-product problems. It produces features that are individually coherent but collectively contradictory. On the dating app, the onboarding and the messaging were each defensible in isolation. Together, they undermined each other.

• Onboarding communicated: every person here is verified and real.
• Messaging permitted: automated and fake messages from unverifiable sources.
• The user experienced: a product that promised one thing and delivered another.

Product coherence is the thing that determines whether a user's experience matches the expectation you created for them. Discovery across all interconnected components is how you check for coherence before you build.

The Projects We Have Walked Away From

Skipping discovery entirely on one component is one version of this problem. Refusing to do any discovery at all is another. We walked away from a project involving a fairly standard social product because the client wanted to go straight into redesigns. They had a clear idea of what they wanted the product to look like, and they saw discovery as delay rather than investment.

Our discovery phase is emotionally led. We ask who the brand is as a person, what the product is as a person, and how it interacts with the people using it. We work to understand the psychology behind a product before we make any design decisions. That understanding shapes everything that follows, from information architecture to interaction design to the tone of every piece of copy on screen.

A client who will not engage with that process is a client we cannot serve well. The work we would produce without it would not reflect what we know about emotional design and user psychology. It would be surface-level, and surface-level work does not hold up under the conditions real users bring to a product.

So we walked away. That is not a decision made lightly. But a product built without proper discovery carries risks we are not willing to attach our name to, and our work always carries our name.

Before you scope a discovery phase, map every major component of the product and ask: what assumption does this component make about the user's emotional state when they arrive here? If the answer was not derived from research, that component needs discovery.

How to Think About Discovery as a Budget Line

The frame most clients bring to discovery is that it is a cost. It comes at the beginning of a project, before anything visible has been produced, and it consumes budget that could have gone into building. That framing is understandable, and it is wrong.

Discovery is an insurance policy. You pay for it upfront, and you are hoping not to need it in the specific sense that you are hoping it will not reveal expensive problems. But if it does reveal them, finding out in week two is categorically different from finding out in month six, after the build is well underway.

The table below sets out the comparison in concrete terms.

On the dating app, the problem was found during build. That put it in the middle row. A discovery phase covering messaging would have cost a fraction of the £15,000 rewrite, and the two months of delay would not have happened. Projects that skip discovery are, according to Devtimate, three to five times more likely to fail or exceed budget. The dating app did not fail, but it exceeded budget by exactly the amount the discovery phase would have cost.

Conclusion

The dating app story is not unusual. The decision to skip discovery on messaging was made by a thoughtful client with real budget constraints and a genuine rationale. What made it costly was not recklessness. It was a reasonable assumption about what "straightforward" means, applied to a component that was not actually straightforward in the context of this specific product.

Every product has components that look generic on the surface and are not. Messaging looks like messaging until you understand that this product's entire value proposition lives or dies on how messaging feels. A building directory looks like an information architecture problem until you understand that the residents using it have just moved home and are in a heightened emotional state. An onboarding flow looks like a series of screens until you understand the psychological work it needs to do before the user reaches screen three.

Discovery is the process of finding out what is actually underneath the surface. Applied to a whole product, it produces coherence. Applied selectively, it produces a product where some parts know what they are doing and others are guessing. The parts that are guessing tend to cost more in the end.

We run discovery as an emotionally led process, and we treat it as non-negotiable across every major component of a product. Not because it is an article of faith, but because the alternative has a price and we have seen it paid. If you are planning a product and trying to work out where discovery fits in the budget, let's talk about your project before the build begins.

Frequently Asked Questions