A Showstopper is a critical, unforeseen issue or flaw that halts everything. These high-priority defects, such as system crashes or broken core functionality, typically prevent the product from being released, tested, or operated until they are resolved. Showstoppers often result in significant delays and increased cost.<\/p>\n\n\n\n
In design, a showstopper is sometimes used to describe the opposite: a highly impressive “wow” feature. <\/p>\n\n\n\n
\nThe noun “showstopper” originated in the 1910s, with the earliest known usage recorded in 1916 in the Fort Wayne Journal-Gazette<\/em> (Indiana). The term historically describes a theatrical performance – usually a song or act – so impressive that it receives prolonged applause, forcing a temporary halt to the show. It was commonly used in theater to describe acts that “brought the house down”.<\/p>\n\n\n\n
Software engineering eventually gave the word a darker second career – with considerably less applause: A critical defect that caused a system – or its release – to grind to a halt. The metaphor still worked perfectly. Something happened. Everything stopped. <\/p>\n\n\n\n
Today, the word is commonly used as a synonym for “deal-breaker” in government and business. The negative meaning is now so pervasive that using it in the original meaning may regard you as ignorant.<\/p>\n<\/blockquote>\n\n\n\n
WHEN<\/h2>\n\n\n\n
You\u2019ve encountered a Showstopper when:<\/p>\n\n\n\n
\n
- Everything is ready except one thing<\/strong>
Unfortunately, that one thing is the reason the product exists.<\/li>\n<\/ul>\n\n\n\n\n
- A critical journey cannot be completed<\/strong>
Users can browse beautifully. They just can’t buy anything.<\/li>\n<\/ul>\n\n\n\n\n
- The product technically works but practically doesn’t<\/strong>
The feature loads, looks excellent, and provides absolutely no path forward.<\/li>\n<\/ul>\n\n\n\n\n
- An edge case becomes a release blocker<\/strong>
Yesterday it affected \u201cprobably nobody.\u201d Today that nobody is your largest customer.<\/li>\n<\/ul>\n\n\n\n\n
- A dependency fails at exactly the wrong moment<\/strong>
The product is ready. The service it depends on has other plans.<\/li>\n<\/ul>\n\n\n\n\n
- Someone says: \u201cWe can’t ship this.\u201d<\/strong>
Not shouldn’t. Can’t.<\/li>\n<\/ul>\n\n\n\n\n
- Everything else suddenly stops mattering<\/strong>
Nobody is discussing the slightly inconsistent icon anymore.<\/li>\n<\/ul>\n\n\n\nWHY<\/h2>\n\n\n\n
Showstoppers aren\u2019t usually dramatic. They\u2019re often small things in very important places such as a single broken step in a critical flow, a missing piece in a dependency chain, or an edge case that turns out not to be an edge.<\/p>\n\n\n\n
They emerge because:<\/p>\n\n\n\n
\n
- Critical paths carry disproportionate risk<\/strong>
Login, checkout, saving, submitting, authentication, and core workflows may represent only a fraction of the interface but determine whether the product is useful.<\/li>\n<\/ul>\n\n\n\n\n
- Dependencies concentrate failure<\/strong>
A single service, API, permission, component, or decision can sit underneath several apparently unrelated experiences.<\/li>\n<\/ul>\n\n\n\n\n
- Edge cases aren’t always edges<\/strong>
The rare configuration discovered during testing has an unfortunate tendency to belong to a very important customer.<\/li>\n<\/ul>\n\n\n\n\n
- Production behaves differently<\/strong>
Real devices, real data, real networks, real permissions, and real users create conditions prototypes politely avoided.<\/li>\n<\/ul>\n\n\n\n\n
- Late discoveries are expensive<\/strong>
A critical problem found during exploration is inconvenient. The same problem found twelve minutes before launch has considerably better branding.<\/li>\n<\/ul>\n\n\n\nHOW<\/h2>\n\n\n\n
Showstoppers can\u2019t be eliminated entirely but they can be anticipated and their impact reduced. Avoid them by applying the following strategies:<\/p>\n\n\n\n
\n
- Identify critical paths early<\/strong>
Determine which journeys absolutely must work for the product to deliver its core value.<\/li>\n<\/ul>\n\n\n\n\n
- Test the important things first<\/strong>
If users can’t sign in, complete the primary task, save their work, or pay, polishing secondary interactions won’t rescue the experience.<\/li>\n<\/ul>\n\n\n\n\n
- Test under real conditions<\/strong>
Use realistic devices, browsers, data volumes, permissions, network conditions, and user behavior. The prototype is a very supportive environment.<\/li>\n<\/ul>\n\n\n\n\n
- Look for single points of failure<\/strong>
Ask what one component, dependency, service, or decision could bring the entire experience down.<\/li>\n<\/ul>\n\n\n\n\n
- Surface risk early<\/strong>
Uncertainty becomes more expensive the longer it remains undiscovered. Test risky assumptions before polishing safe ones.<\/li>\n<\/ul>\n\n\n\n\n
- Design for recovery<\/strong>
Failures happen. Provide retries, fallbacks, autosave, useful error states, and ways to continue when possible.<\/li>\n<\/ul>\n\n\n\n\n
- Prioritize by consequence<\/strong>
Not every defect deserves emergency status. A misaligned icon and a broken checkout should not compete in the same weight class.<\/li>\n<\/ul>\n\n\n\nPRO TIP<\/h2>\n\n\n\n
\nYou’ve encountered a showstopper if you hear someone (yourself) saying: “It worked on my box”. Always test your app on multiple devices and screen resolutions.<\/p>\n<\/blockquote>\n\n\n\n
EXAMPLES<\/h2>\n\n\n\n
\n
- Users can browse an online store but cannot complete checkout. <\/li>\n\n\n\n
- A login issue prevents a significant group of users from accessing the product at all. <\/li>\n\n\n\n
- A mobile layout breaks the primary workflow on a widely used device or screen size. <\/li>\n\n\n\n
- A security vulnerability is discovered that makes the planned release unsafe to ship. <\/li>\n\n\n\n
- A critical API dependency fails and leaves the product without its core functionality. <\/li>\n\n\n\n
- A form appears to submit successfully but silently loses the user’s data. <\/li>\n\n\n\n
- A permission issue prevents administrators from completing a required setup process. <\/li>\n\n\n\n
- A prototype performs beautifully until real production data causes the primary experience to fail.<\/li>\n<\/ul>\n\n\n\n
CONCLUSION<\/h2>\n\n\n\n
In theater, a showstopper is an outstanding performance or moment everyone remembers. In product development, it\u2019s the moment everything pauses for all the wrong reasons.<\/p>\n\n\n\n
A Showstopper doesn\u2019t compete for attention, it takes over. It halts progress, delays release, and forces a decision: fix it, or abandon. Good teams identify critical paths, test risky dependencies early, prepare for failure, and reserve their highest urgency for problems that genuinely deserve it.<\/p>\n\n\n\n
The lesson is simple: Not every problem deserves urgency. But some problems deserve all of it.<\/strong><\/p>\n","protected":false},"excerpt":{"rendered":"
A Showstopper is a critical, unforeseen issue or flaw that halts everything. These high-priority defects, such as system crashes or broken core functionality, typically prevent the product from being released, tested, or operated until they are resolved. Showstoppers often result in significant delays and increased cost.<\/p>\n
In design, a showstopper is sometimes used to describe the opposite: a highly impressive “wow” feature.<\/p>\n","protected":false},"author":1,"featured_media":946,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_feature_clip_id":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_post_was_ever_published":false},"categories":[24],"tags":[149,151,147,148],"class_list":["post-736","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-the-testing-twilight-zone","tag-bug","tag-features","tag-show","tag-stopper","entry","has-media","owp-thumbs-layout-horizontal","owp-btn-big","owp-tabs-layout-horizontal","has-no-thumbnails","has-product-nav"],"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"https:\/\/hitchhikersguidetodesign.com\/book\/wp-content\/uploads\/2026\/09\/50.jpg","_links":{"self":[{"href":"https:\/\/hitchhikersguidetodesign.com\/book\/wp-json\/wp\/v2\/posts\/736","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/hitchhikersguidetodesign.com\/book\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/hitchhikersguidetodesign.com\/book\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/hitchhikersguidetodesign.com\/book\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/hitchhikersguidetodesign.com\/book\/wp-json\/wp\/v2\/comments?post=736"}],"version-history":[{"count":3,"href":"https:\/\/hitchhikersguidetodesign.com\/book\/wp-json\/wp\/v2\/posts\/736\/revisions"}],"predecessor-version":[{"id":1004,"href":"https:\/\/hitchhikersguidetodesign.com\/book\/wp-json\/wp\/v2\/posts\/736\/revisions\/1004"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/hitchhikersguidetodesign.com\/book\/wp-json\/wp\/v2\/media\/946"}],"wp:attachment":[{"href":"https:\/\/hitchhikersguidetodesign.com\/book\/wp-json\/wp\/v2\/media?parent=736"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/hitchhikersguidetodesign.com\/book\/wp-json\/wp\/v2\/categories?post=736"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/hitchhikersguidetodesign.com\/book\/wp-json\/wp\/v2\/tags?post=736"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}