--- title: The Fdas Overdose App Development Contest description: Explore what made the FDA's overdose app contest brief so effective. Learn how to write clearer, tighter app briefs that define scope, goals and success. image: https://weareaffective.com/hubfs/learning-centre-images/the-fdas-overdose-app-development-contest.webp --- [Skip to content](https://weareaffective.com/learning-centre/the-fdas-overdose-app-development-contest#main-content) [![we\_are\_affective\_logo\_200](https://weareaffective.com/hs-fs/hubfs/we_are_affective_logo_200.png?width=175&height=48&name=we_are_affective_logo_200.png "we_are_affective_logo_200")](https://weareaffective.com) - [Home](https://weareaffective.com) - About Us - [Our Story](https://weareaffective.com/about) - [How We Work](https://weareaffective.com/how-we-work) - Our Services - [App Planning & Strategy](https://weareaffective.com/app-planning-strategy) - [App Design](https://weareaffective.com/app-design-agency) - [App UX Design](https://weareaffective.com/app-ux-design) - [App UI Design](https://weareaffective.com/app-ui-design) - [App Technical Architecture](https://weareaffective.com/app-architecture) - [Existing App Audits](https://weareaffective.com/app-audit) - [Case Studies](https://weareaffective.com/case-studies) - [Pricing](https://weareaffective.com/pricing) - [Learning Centre](https://weareaffective.com/learning-centre) - [Get Started](https://weareaffective.com/get-started) Expert Guide Series # The Fdas Overdose App Development Contest Table of Contents The FDA ran a public contest asking developers, designers, and researchers to build a mobile app addressing opioid use disorder. On the surface, that sounds like a broad invitation. Build something useful. Help people with addiction. Good luck. But the actual brief was nothing like that. It was one of the most constrained, precisely articulated problem statements in recent public health technology, and that constraint was the whole point. > A brief that defines the problem clearly means every team spends their energy solving it, not debating it. What the FDA did was define the problem so clearly that any team entering the contest would spend their energy solving it, rather than debating what it was. That distinction matters far more than it sounds. Most digital product briefs fail before a single wireframe is drawn, not because the team lacks skill, but because nobody agreed on what success looks like or what the product is actually trying to do. The FDA's contest brief did something rare: it made those decisions in advance and committed to them in writing. We spend a lot of time at WAA working through briefs with clients, and the pattern is consistent. The products that reach market on time and within budget almost always started with a sharply defined problem. The ones that spiral, in scope, in cost, in timeline, almost always started with a brief that left too much open. The FDA's overdose app contest is worth examining closely because it shows what a properly constructed brief actually looks like, and what it produces. ## What the FDA's Overdose App Contest Actually Was The FDA's overdose app development contest was a federally organised challenge inviting teams to design and build a mobile application to support people in recovery from opioid use disorder. The contest sat within a broader effort to understand how digital health tools could complement existing treatment pathways, and it came with structured requirements, defined user groups, and a formal evaluation process. Crucially, the contest was not asking for the best idea about addiction recovery apps in general. It was asking for a solution to a specific, bounded problem. Entrants were given information about the target population, the context of use, and the criteria against which submissions would be assessed. Researchers conducted qualitative interviews with people in recovery to gather baseline data before the contest opened, so that teams were building from real insight rather than assumption. Those interviews produced findings worth noting. More than 80% of participants mentioned friends, family, and connection when asked what makes them most happy in life, according to [Springer, 2022](https://link.springer.com/chapter/10.1007/978-3-031-05900-1_7). Over half used their phones more than 15 times per day. 73% had tried some form of meditation, with 75% of those finding it helpful. These were not decorative statistics. They were the raw material teams were expected to design from. That pre-contest research gave the contest its grounding. It [turned an abstract public health challenge into a design problem with a known user](https://weareaffective.com/learning-centre/what-a-behavioural-discovery-sprint-uncovers-that-user-interviews-miss), known behaviours, and known emotional priorities. That transformation, from vague aspiration to specified problem, is the work a good brief must do. ## The Problem Statement: How the FDA Defined the Challenge The core problem the FDA articulated was this: people recovering from opioid use disorder face high relapse risk, limited access to consistent support, and the daily cognitive burden of managing their recovery without real-time tools. A mobile app could sit in that gap, available at the moment of need, without the scheduling constraints of in-person support. The research underpinning the brief showed that 90% of participants with counselling experience said it was helpful, but two disclosed feeling unprepared for the level of counselling they received, according to [Springer, 2022](https://link.springer.com/chapter/10.1007/978-3-031-05900-1_7). That tension, between the value of support and the readiness to receive it, became part of the design challenge. The app needed to offer support without overwhelming users who were already in a vulnerable state. The FDA also identified the existing gap in patient-facing tools. At the time, the market for opioid-related apps was dominated by clinician-facing products, and only a handful addressed the patient experience directly. A gap that large is not a coincidence. Building for the end user in recovery requires a different discipline than building a reference tool for a healthcare professional, and the majority had defaulted to the easier problem. Before writing a product brief, conduct at least one round of research with the actual end user. Design assumptions built on internal knowledge alone consistently miss the behaviours that matter most. By naming the specific user, the specific gap, and the specific emotional context, the FDA brief made it very difficult to drift. Every design decision could be tested against those parameters. ## Start your app project the *right* way We deliver the complete blueprint before a line of code is written. User research, psychology-driven design and full technical specifications. You choose who builds it. [See how we work](https://weareaffective.com/how-we-work) [Get started](https://weareaffective.com/get-started) No commitment ## Constrained Scope: What the Contest Ruled In and Ruled Out The contest brief did not leave scope to negotiation. It defined what the app should address and, equally, what it should not try to be. This is the discipline that most product briefs skip entirely, and it is the discipline that matters most when a development team sits down to [plan their first sprint](https://weareaffective.com/app-planning-strategy). By specifying the population, the recovery context, and the type of support the app could realistically provide, the brief effectively ruled out a large category of solutions. Teams could not build a clinical prescription tool. They were not competing to replace a counsellor. The app sat in a defined lane, and that lane had edges. > A brief with defined edges is the only kind that keeps a team from building a product that does everything and solves nothing. This is exactly where we have seen projects collapse in our own work. We worked on a sports club app project where the two co-founders were deeply embedded in the world the app was designed for. Because the app was the business itself, both founders consistently pushed to add more features, each convinced their additions were already implied by the original brief. What should have reached market in three to four months never launched after twelve to fourteen months of development, and the budget almost doubled. We had warned them early that the budget would spiral out of control. The project ended with the entire budget exhausted and nothing published to the app store. A brief that specifies what is out of scope is a protection. The FDA understood that. Teams entering the contest could build with confidence because the boundaries were clear from day one. ## Success Criteria: How the FDA Defined a Winning Solution Defining the problem is one half of a rigorous brief. Defining what a good answer looks like is the other. The FDA did both. Submissions were assessed against explicit criteria that related directly to the user research: Did the solution address the emotional needs of people in recovery? Did it account for the user's context and state of mind? Did it demonstrate usability for the target population? This matters because [success criteria shape every design decision made during development](https://weareaffective.com/learning-centre/how-to-structure-a-behavioural-risk-register-before-you-write-a-single-user-stor). When a team knows how their work will be evaluated, they can make trade-offs with confidence. Without that, every decision involves an implicit guess about what the client, the regulator, or the user actually values most. The research showed that 54.5% of participants had used virtual reality, with half reporting positive experiences and half reporting negative ones, and 100% expressed willingness to try a recovery intervention combining immersive technology with a smartphone app, according to [Springer, 2022](https://link.springer.com/chapter/10.1007/978-3-031-05900-1_7). That data point tells a team building for this population something specific: openness to technology exists, but the design must account for mixed prior experience. A good success criterion would probe whether the solution served users across that range, rather than only the ones already comfortable with new formats. Write your success criteria before you write your feature list. If you cannot describe what a finished, working version looks like in behavioural terms, your feature list has no anchor. Clear success criteria are not just useful for evaluation. They prevent the feature accumulation that kills products in development. If a feature cannot be connected to a success criterion, it has no business being in the scope. ## What a Rigorous Brief Produces That a Vague One Cannot A rigorous brief produces alignment that a vague one cannot manufacture later. When a team understands the problem, the user, the scope, and the success criteria from the start, they can move quickly and make decisions without constant escalation. A vague brief produces the opposite: repeated check-ins, contested decisions, and a growing pile of features added to fill the gap left by the original lack of direction. We saw this pattern on a dating app project focused on verified profiles and preventing bots. The client chose to skip discovery for the messaging component, wanting to focus solely on the onboarding process. Skipping that discovery meant we built a generic messaging feature that contradicted the core product premise. It allowed automated and fake messages, which undermined all the verification work done during onboarding. The entire messaging section had to be rewritten, costing approximately £15,000 in additional budget and two months of extra work. A brief that had defined the messaging scope from the start would have prevented that. The problem was not a design failure or a development error. The problem was a gap in the original problem definition that no amount of good execution could compensate for. The FDA brief also produced something less obvious but equally valuable: it made comparison possible. When multiple teams work from the same brief, their outputs can be evaluated against a shared standard. That is only possible because the standard existed before the work began. In a typical commercial engagement, the absence of pre-agreed criteria means evaluation becomes subjective, contested, and slow. ## What Most Commercial App Briefs Are Missing by Comparison Most commercial app briefs describe a product rather than a problem. They list features, sketch user flows, and name a target audience in broad terms. What they rarely do is articulate the specific human difficulty the product is designed to address, the conditions under which it will be used, and the measurable signs that it has worked. The existing landscape of opioid-related apps before the FDA contest illustrated this failure at scale. Research showed that 86% of available opioid-related apps were opioid-specific, and 43% were clinician-facing, according to [PMC / NCBI, 2020](https://pmc.ncbi.nlm.nih.gov/articles/PMC7305558/). Only 5% of the apps found provided support for patient monitoring. Teams had built what was easy to build and what they already understood, rather than what the end user needed. This is the direct consequence of briefs that lack a defined problem. Without one, teams default to convention, copying what exists, and layering features onto familiar structures. The patient-facing gap in opioid apps was not a gap in developer capability. It was a gap in problem definition. We worked on a genetics wellness app where we found a similar dynamic. The product had been built largely by a developer team who had stripped out the storytelling and narrative in favour of functional delivery. The brand promise itself was sound. But without a brief that defined emotional connection as a success criterion, the developers built what they could measure and understood: functions, data displays, and clean information architecture. Users were not connecting with their results, and retention suffered directly as a result. When reviewing a draft brief, ask this question for every feature listed: what specific user behaviour does this feature change, and how will you know if it worked? If neither answer is in the brief, the brief is incomplete. ## Scope Creep as a Brief Failure: When the Problem Is Never Properly Defined Scope creep is routinely described as a project management failure. It is more accurate to call it a brief failure. When a project expands beyond its original intent, the explanation is almost always that the original intent was never precise enough to hold the boundary. We worked on a grassroots football club app where the client wanted to replicate several different apps into one product. We advised them to focus on releasing a limited feature set first, test the market, and build from there. The client would not follow that advice. The scope kept expanding, the budget kept rising, and the product never reached market. The complexity was unnecessary, and it was visible early. But without a brief that defined the scope and held it, there was no agreed-upon line to defend. Simon has described the outcome plainly: "We ended up with a bigger product at the end, which is the complete opposite of what you should have." Refinement sessions, without disciplined scope control and stakeholder commitment to reduction, can perversely expand a product rather than focus it. That expansion does not come from bad intentions. It comes from a brief that never drew the edges clearly enough to make the expansion visible as a problem. The FDA contest could not produce that failure mode because the scope was set by the brief, not negotiated during development. Teams that wanted to add features outside the defined problem would find those features disconnected from the success criteria. The brief acted as a natural filter. ## What Happens When Success Criteria Are Absent or Ignored When success criteria are absent, the definition of done becomes whatever the loudest stakeholder says it is at the point of delivery. That is the root cause of most late-stage product disputes and most post-launch rewrites. On the fitness social network we worked on, users were dropping off at the point where they were asked to share their precise location with a potential match. The drop-off happened because the location-sharing request came before users had any opportunity to converse or learn about the other person. Nobody had defined, in advance, what a successful conversion from sign-up to first meeting looked like or what the behavioural sequence needed to be. Once we identified the problem and redesigned the flow, [introducing approximate proximity rather than precise location and sequencing conversation before location disclosure](https://weareaffective.com/learning-centre/why-product-owners-should-write-the-users-second-session-before-the-first-one), conversion from sign-up to successfully meeting another user rose from approximately 20% to around 60 to 70%. The fix was a single behavioural flow change. The reason it needed fixing was that the original brief had not defined [the sequence of trust-building as a success criterion](https://weareaffective.com/learning-centre/what-makes-users-trust-a-product-enough-to-enter-their-card-details). Had it done so, the drop-off point would have been visible before launch, not after. A success criterion is a design constraint that shapes the product from the beginning. When it is missing, the team builds what they think is right and discovers later whether it was. ## How to Write a Brief That Functions Like the FDA's A brief that functions like the FDA's contest document does four things. It names the specific human problem, describes the user in concrete behavioural terms, defines the scope by ruling things out as well as in, and states what a successful solution looks like in a way that can be tested. #### The four components of a functional brief 1. Name the specific problem the product addresses, in one sentence that describes a real human difficulty rather than a product category. 2. [Describe the user in behavioural terms](https://weareaffective.com/learning-centre/what-a-development-team-actually-needs-to-know-about-the-user-before-sprint-one): what they are doing, what they are feeling, and what context they are in when they need the product. 3. Define the scope by stating what the product will not do, as explicitly as what it will. 4. State what success looks like in observable terms, a behaviour that changes, a drop-off that disappears, a decision made more confidently. #### What to do when stakeholders push back The most common point of failure is the scope definition, because ruling things out requires stakeholders to accept that some ideas will not be in this version. On the genetics wellness app project, we used focus groups and five-second tests to measure comprehension before and after copy changes. Comprehension started low, and after rewriting to create a more narrative experience and pre-framing potential error states, a second round of user testing showed clear improvements in clarity, purpose, and retention. That process worked because we had defined what clarity and retention meant before we measured them. When stakeholders push to add scope, the brief is the place to push back. A feature that cannot be connected to a named success criterion belongs in a later version, or not at all. Committing that principle to the brief before development starts is the only way to hold the line without making every scope conversation a negotiation. The vehicle manufacturer's accident reporting app we redesigned worked on the same principle. By defining the specific problem, a distressed user unable to navigate to a reporting feature, we could rule out everything that did not address that moment. The accelerometer-based detection, the voice memos for witness statements, the exploded car diagram for damage photography: each element connected directly to the stated problem. Nothing was added because it seemed useful in general. ## Conclusion The FDA's overdose app contest was not a remarkable piece of public health policy because of its budget or its scale. It was remarkable because the people who wrote the brief did the hard thinking before the development started. They named the user, described the problem, bounded the scope, and defined what a good answer would look like. Then they got out of the way and let teams build. That sequence, brief first, build second, is obvious in theory and consistently reversed in practice. The sports club app where the budget almost doubled and nothing reached the app store after twelve to fourteen months. The dating app where skipping discovery on the messaging component cost £15,000 and two months of rework. The grassroots football club app that grew in every direction until it was too complex to ship. In each case, the brief had not done the work it needed to do, and the project paid the price. A brief is a design artefact. It shapes every decision that follows it. A brief that names the problem clearly, holds the scope, and defines success in testable terms gives a team the conditions to build well. A brief that leaves those questions open guarantees that the project will answer them anyway, under pressure, late, and at cost. The FDA knew what it wanted built. More product briefs should start from the same place. If you are at the beginning of a product or trying to recover a project that has drifted, [let's talk about your brief](https://weareaffective.com/get-started). ## Frequently Asked Questions What was the FDA's overdose app contest and who could enter? The FDA organised a federally run challenge inviting developers, designers, and researchers to build a mobile application supporting people in recovery from opioid use disorder. It was a structured competition with defined requirements, specified user groups, and a formal evaluation process rather than an open-ended invitation. Why did the FDA conduct research before the contest even opened? The FDA commissioned qualitative interviews with people in recovery to ensure that competing teams were designing from real insight rather than assumption. This meant entrants received concrete data about user behaviours and emotional priorities, such as the importance of social connection and the frequency of phone use, before they began building. What did the pre-contest research actually find about people in recovery? The research found that more than 80% of participants cited friends, family, and connection as central to their happiness, and over half used their phones more than 15 times per day. Additionally, 73% had tried some form of meditation, with 75% of those finding it helpful, giving teams clear behavioural and emotional data to design from. What specific problem was the app meant to solve? The FDA identified that people recovering from opioid use disorder face high relapse risk, limited access to consistent support, and the daily cognitive burden of managing recovery without real-time tools. The app was intended to fill that gap by being available at the moment of need, without requiring scheduled appointments or other barriers. Why does a clearly defined brief matter so much in digital product development? A vague brief means teams spend valuable time debating what the product should do rather than actually building it, which leads to scope creep, cost overruns, and missed deadlines. The FDA's approach demonstrated that committing to a sharply defined problem in advance keeps every team member focused on solving the same challenge from the start. How is the FDA's contest brief different from a typical digital product brief? Most digital product briefs leave too much open, allowing disagreements about goals and success criteria to derail projects before a single design decision is made. The FDA's brief made those decisions in advance, specifying the target population, the context of use, and the evaluation criteria, which is comparatively rare in both public and private sector technology projects. What can product teams learn from the way the FDA structured this contest? The key lesson is that investing time in defining the problem clearly, including conducting user research before development begins, leads to better outcomes and fewer costly course corrections later. Products that start with a sharply specified brief are far more likely to reach market on time and within budget than those that begin with ambiguous goals. How did the FDA turn a broad public health challenge into a workable design problem? By conducting pre-contest interviews and translating findings into a structured brief, the FDA converted a vague aspiration around addiction recovery into a problem with a known user, known behaviours, and known emotional priorities. That transformation is precisely the work a well-constructed brief must do before any design or development begins. ## Related Articles [![We Are Affective](https://weareaffective.com/hubfs/we_are_affective_logo_mark.svg)](https://weareaffective.com) 20-22 Wenlock Road London, N1 7GU United Kingdom +44 20 4572 8062 [hello@weareaffective.com](mailto:hello@weareaffective.com) Services [App planning & strategy](https://weareaffective.com/app-planning-strategy) [App design](https://weareaffective.com/app-design-agency) [App UX design](https://weareaffective.com/app-ux-design) [App UI design](https://weareaffective.com/app-ui-design) [App technical architecture](https://weareaffective.com/app-architecture) [Existing app audits](https://weareaffective.com/app-audit) Legal [Privacy policy](https://app.termly.io/policy-viewer/policy.html?policyUUID=b8fa9921-7518-4fb5-8ddd-9dc7f5977ed2) [Terms](https://app.termly.io/policy-viewer/policy.html?policyUUID=8b6a6ad5-91bd-4176-a5f7-6d36b0398f70) Case studies [TravAI](https://weareaffective.com/case-studies/travai) [Meditech](https://weareaffective.com/case-studies/harley) [WorkingWeight](https://weareaffective.com/case-studies/workingweight) [SkinSync](https://weareaffective.com/case-studies/skinsync) [Three Lochs](https://weareaffective.com/case-studies/three-lochs) [Drift](https://weareaffective.com/case-studies/drift) About us [Our Story](https://weareaffective.com/about) [How We Work](https://weareaffective.com/how-we-work) Guides [Creating an app](https://weareaffective.com/how-to-create-an-app) [Building an MVP](https://weareaffective.com/building-an-mvp) [Cost and budgeting](https://weareaffective.com/app-development-cost) [App technology](https://weareaffective.com/app-development) [Planning and strategy](https://weareaffective.com/app-planning-strategy) [User research](https://weareaffective.com/app-user-research) [Onboarding design](https://weareaffective.com/app-onboarding-design) [User psychology](https://weareaffective.com/user-psychology-app-design) [Launch and growth](https://weareaffective.com/app-launch-growth) Copyright © 2026, weareaffective.com. All rights reserved.