{
    "archive_path": "archive/1769962716.839376",
    "base_url": "blog.mikeswanson.com/backseat-software",
    "basename": "",
    "bookmarked_date": "2026-02-01 16:18",
    "canonical": {
        "archive_org_path": "https://web.archive.org/web/blog.mikeswanson.com/backseat-software",
        "dom_path": "output.html",
        "favicon_path": "favicon.ico",
        "git_path": "git/",
        "google_favicon_path": "https://www.google.com/s2/favicons?domain=blog.mikeswanson.com",
        "headers_path": "headers.json",
        "htmltotext_path": "htmltotext.txt",
        "index_path": "index.html",
        "media_path": "media/",
        "mercury_path": "mercury/content.html",
        "pdf_path": "output.pdf",
        "readability_path": "readability/content.html",
        "screenshot_path": "screenshot.png",
        "singlefile_path": "singlefile.html",
        "warc_path": "warc/",
        "wget_path": null
    },
    "domain": "blog.mikeswanson.com",
    "downloaded_at": "2026-02-01T16:18:40.871573+00:00",
    "downloaded_datestr": "2026-02-01 16:18",
    "extension": "",
    "hash": "XSZ0HX5J6FG49HVD07WN",
    "history": {
        "archive_org": [
            {
                "cmd": [
                    "/usr/bin/curl",
                    "--silent",
                    "--location",
                    "--compressed",
                    "--proxy",
                    "socks5://tor-socks-proxy:9150",
                    "--head",
                    "--max-time",
                    "60",
                    "--user-agent",
                    "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)",
                    "https://web.archive.org/save/https://blog.mikeswanson.com/backseat-software/"
                ],
                "cmd_version": "8.10.1",
                "end_ts": "2026-02-01T16:19:28.713447+00:00",
                "index_texts": null,
                "output": "ArchiveError: Failed to find \"content-location\" URL header in Archive.org response.",
                "pwd": "/data/archive/1769962716.839376",
                "schema": "ArchiveResult",
                "start_ts": "2026-02-01T16:19:20.984729+00:00",
                "status": "failed"
            }
        ],
        "dom": [
            {
                "cmd": [
                    "/usr/bin/chromium-browser",
                    "--proxy-server=socks5://tor-socks-proxy:9150",
                    "--disable-features=DarkMode",
                    "--run-all-compositor-stages-before-draw",
                    "--hide-scrollbars",
                    "--autoplay-policy=no-user-gesture-required",
                    "--no-first-run",
                    "--use-fake-ui-for-media-stream",
                    "--use-fake-device-for-media-stream",
                    "--simulate-outdated-no-au='Tue, 31 Dec 2099 23:59:59 GMT'",
                    "--headless=new",
                    "--no-sandbox",
                    "--no-zygote",
                    "--disable-dev-shm-usage",
                    "--disable-software-rasterizer",
                    "--disable-sync",
                    "--window-size=1440,2000",
                    "--user-agent=Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)",
                    "--user-data-dir=/data/personas/Default/chrome_profile",
                    "--profile-directory=Default",
                    "--dump-dom",
                    "https://blog.mikeswanson.com/backseat-software/"
                ],
                "cmd_version": "131.0.6778",
                "end_ts": "2026-02-01T16:18:58.533922+00:00",
                "index_texts": null,
                "output": "output.html",
                "pwd": "/data/archive/1769962716.839376",
                "schema": "ArchiveResult",
                "start_ts": "2026-02-01T16:18:48.929277+00:00",
                "status": "succeeded"
            }
        ],
        "favicon": [
            {
                "cmd": [
                    "/usr/bin/curl",
                    "--silent",
                    "--location",
                    "--compressed",
                    "--proxy",
                    "socks5://tor-socks-proxy:9150",
                    "--max-time",
                    "60",
                    "--output",
                    "favicon.ico",
                    "--user-agent",
                    "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)",
                    "https://www.google.com/s2/favicons?domain=blog.mikeswanson.com"
                ],
                "cmd_version": "8.10.1",
                "end_ts": "2026-02-01T16:18:44.492992+00:00",
                "index_texts": null,
                "output": "favicon.ico",
                "pwd": "/data/archive/1769962716.839376",
                "schema": "ArchiveResult",
                "start_ts": "2026-02-01T16:18:41.229972+00:00",
                "status": "succeeded"
            }
        ],
        "git": [],
        "headers": [
            {
                "cmd": [
                    "/usr/bin/curl",
                    "--silent",
                    "--location",
                    "--compressed",
                    "--proxy",
                    "socks5://tor-socks-proxy:9150",
                    "--head",
                    "--max-time",
                    "60",
                    "--user-agent",
                    "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)",
                    "https://blog.mikeswanson.com/backseat-software/"
                ],
                "cmd_version": "8.10.1",
                "end_ts": "2026-02-01T16:18:44.749666+00:00",
                "index_texts": null,
                "output": "headers.json",
                "pwd": "/data/archive/1769962716.839376",
                "schema": "ArchiveResult",
                "start_ts": "2026-02-01T16:18:44.524436+00:00",
                "status": "succeeded"
            }
        ],
        "htmltotext": [
            {
                "cmd": [
                    "(internal) archivebox.extractors.htmltotext",
                    "./{singlefile,dom}.html"
                ],
                "cmd_version": "0.8.5rc51",
                "end_ts": "2026-02-01T16:19:14.536295+00:00",
                "index_texts": [
                    "Backseat Software \u2013 Mike Swanson's Blog (Mike Swanson's Blog \u00bb Feed) (https://blog.mikeswanson.com/feed/) (Mike Swanson's Blog \u00bb Comments Feed) (https://blog.mikeswanson.com/comments/feed/) (Mike Swanson's Blog \u00bb Backseat Software Comments Feed) (https://blog.mikeswanson.com/backseat-software/feed/) (oEmbed (JSON)) (https://blog.mikeswanson.com/wp-json/oembed/1.0/embed?url=https%3A%2F%2Fblog.mikeswanson.com%2Fbackseat-software%2F) (oEmbed (XML)) (https://blog.mikeswanson.com/wp-json/oembed/1.0/embed?url=https%3A%2F%2Fblog.mikeswanson.com%2Fbackseat-software%2F&format=xml) (https://blog.mikeswanson.com/wp-content/plugins/complianz-gdpr/assets/css/cookieblocker.min.css?ver=1765912675) (https://blog.mikeswanson.com/wp-content/plugins/add-anchor-links/assets/css/add-anchor-links.css?ver=1.0.2) (https://blog.mikeswanson.com/wp-json/) (JSON) (https://blog.mikeswanson.com/wp-json/wp/v2/posts/1267) (RSD) (https://blog.mikeswanson.com/xmlrpc.php?rsd) (https://blog.mikeswanson.com/backseat-software/) (https://blog.mikeswanson.com/wp-includes/js/dist/script-modules/interactivity/index.min.js?ver=8964710565a1d258501f) (https://blog.mikeswanson.com/wp-content/uploads/2024/04/MikeIcon-150x150.png) (https://blog.mikeswanson.com/wp-content/uploads/2024/04/MikeIcon-300x300.png) (https://blog.mikeswanson.com/wp-content/uploads/2024/04/MikeIcon-300x300.png)  Skip to content (https://blog.mikeswanson.com) Mike Swanson's Blog         (/) Posts   (https://blog.mikeswanson.com/projects/) Projects   (https://blog.mikeswanson.com/about/) About   (https://blog.mikeswanson.com/search/) Search            Backseat Software  January 18, 2026   What if your car worked like so many apps? You\u2019re driving somewhere important\u2026maybe running a little bit late. A few minutes into the drive, your car pulls over to the side of the road and asks: \u201cHow are you enjoying your drive so far?\u201d  Annoyed by the interruption, and even more behind schedule, you dismiss the prompt and merge back into traffic. A minute later it does it again. \u201cDid you know I have a new feature? Tap here to learn more.\u201d  It blocks your speedometer with an overlay tutorial about the turn signal. It highlights the wiper controls and refuses to go away until you demonstrate mastery. Ridiculous, of course. And yet, this is how a lot of modern software behaves. Not because it\u2019s broken, but because we\u2019ve normalized an interruption model that would be unacceptable almost anywhere else. I\u2019ve started to think of this as backseat software : the slow shift from software as a tool you operate to software as a channel that operates on you. Once a product learns it can talk back, it\u2019s remarkably hard to keep it quiet. This post is about how we got here. Not overnight, but slowly. One reasonable step at a time.    Software Came on Disks There was a time when software shipped on physical media: floppy disks, CD-ROMs, sometimes even with a spiral-bound manual. Software felt like a product back then. You bought it, installed it, and used it. If you upgraded, it was because you chose to. The software didn\u2019t constantly change underneath you, and it didn\u2019t have the opportunity to ask for your attention beyond whatever UI the developers shipped on day one. That era had real downsides. If you shipped a serious bug, you lived with it until the next release, which could be weeks or months away. If security issues were discovered, your options ranged from \u201cmail a patch\u201d to \u201cgood luck.\u201d In hindsight, it\u2019s amazing we survived! But something else was true too. When you were using the software, you were alone with it. As a software developer, if something was wrong, you found out because users told you. Sometimes loudly. Sometimes angrily. Often on message forums or during support calls. Feedback was slower and scarcer, but it was real. It was also \u201cexpensive\u201d in the way that matters. You had to earn it, listen to it, and interpret it.    Always Online Then the internet arrived, and for a while it was almost entirely upside. Software could finally be updated after it shipped. Bugs could be fixed. Security holes could be closed. Documentation got easier. Support got easier. The idea of \u201cship it and hope for the best\u201d started to fade. (https://en.wikipedia.org/wiki/Windows_Update) Microsoft\u2019s update infrastructure is a good example of the era. Updates moved from \u201cgo download this\u201d toward automation over time, and by the early 2000s the industry was normalizing the idea that your machine could check for and apply updates regularly. This was a genuine leap forward in quality and safety. If you\u2019ve ever been on the receiving end of a serious bug report, you know how valuable it is to fix something now rather than in the next boxed release. So far, so good.    The Back Channel Once software could reliably connect to the internet, it no longer just received instructions. It could talk back to the company that made it. At first, this too was mostly good. Crash reports made it easier to fix real problems, update checks were convenient, and license activation reduced some kinds of piracy. Teams could finally see patterns in failure modes instead of guessing. Developers like me love this kind of feedback loop, and for good reason. A tool that improves over time is better than one that doesn\u2019t. But that back channel didn\u2019t stay limited to \u201cthis crashed\u201d and \u201cthere\u2019s an update.\u201d It expanded, quietly, because once you can send some data home, the next question arrives right on schedule: \u201cSince we\u2019re already connected\u2026what else can we learn?\u201d     Everything Gets Measured Once software could send data home, the next natural thought was: \u201cCan we understand how people actually use this?\u201d  Again, that\u2019s not an evil thought. In fact, it\u2019s useful! Before analytics, if you wanted to understand user behavior, you had to ask people, watch them, or infer patterns from support tickets. That requires time, empathy, and effort. Suddenly, you didn\u2019t have to guess anymore. Web analytics going mainstream is one of those quiet accelerants. (https://urchin.biz/urchin-software-corp-89a1f5292999) Google\u2019s acquisition of Urchin in 2005 , and the rise of Google Analytics shortly after, helped normalize the idea that instrumentation and dashboards were simply part of building software. Instead of arguing in a meeting about which features mattered most, you could look at usage data. Instead of guessing where people struggled, you could see drop-offs. Instead of relying on the loudest customer, you could get a broader view. But somewhere along the way, the center of gravity shifted.  Usage data stopped being a tool for improving software and became a tool for optimizing behavior. The question quietly changed from: \u201cIs this good software?\u201d  to: \u201cDoes this increase engagement?\u201d  And that\u2019s when the vocabulary starts to creep in. DAU. MAU. Retention. Funnels. Stickiness. Cohorts. Conversion. Gamification. Oh my! If you\u2019ve worked inside a modern product organization, you\u2019ve heard these words so often they start to feel unavoidable.    Metrics Can Be Correct and Still Be Wrong One of the most dangerous things about analytics is that they feel objective. A chart is a chart. A number is a number. They have the aesthetic of truth. I\u2019ve always liked this quote by William Bruce Cameron ((https://quoteinvestigator.com/2010/05/26/everything-counts-einstein/) often misattributed to Albert Einstein ):   \u201cNot everything that can be counted counts, and not everything that counts can be counted.\u201d  Metrics don\u2019t measure reality. They measure what your product currently makes easy. There\u2019s a well-known warning about this, often summarized as: when a measure becomes a target, it stops being a good measure . It\u2019s commonly referred to as (https://en.wikipedia.org/wiki/Goodhart%27s_law) Goodhart\u2019s Law , and the broader point shows up in multiple fields, because it keeps happening to humans in systems with incentives. When I was at Microsoft, a team wanted to remove a feature because \u201cthe analytics show that nobody uses it.\u201d If you looked at the UI, though, that feature had been moved deeper and deeper over time: it used to be easy to find then it moved into a menu then into a submenu then into a settings panel then behind an \u201cadvanced\u201d section then it was basically invisible  Of course nobody used it! The analytics didn\u2019t prove the feature was unwanted. The analytics proved that we buried it. Even worse, once a metric becomes a target, people get promoted for moving it. That doesn\u2019t require anyone to be malicious. It just requires incentives and a dashboard.    Experimenting in Production Measuring behavior changes what feels possible: \u201cWhat if we try two versions to see which one performs better?\u201d  This is where A/B testing enters the story. On paper, it\u2019s an engineering triumph! Instead of arguing about opinions, you can test ideas. Instead of debating copy or layout in a meeting, you can ship both and let real-world behavior decide. But A/B testing quietly changes the role of the product team. You\u2019re no longer just building a tool and observing how it\u2019s used. You\u2019re now running experiments on people\u2026adjusting wording, placement, timing, friction, and flow to see what moves the metric. At that point, the product stops being a finished artifact and starts behaving like a laboratory. Every screen becomes provisional, and every interaction becomes a hypothesis. Once that mindset takes hold, it\u2019s very hard not to optimize for what moves fastest, even if it moves the wrong thing. There\u2019s a quieter consequence here that doesn\u2019t get talked about much. When experimentation becomes the primary decision-making tool, a strong product vision becomes optional. Not because anyone argues against vision , but because you don\u2019t strictly need it anymore, and because backing a chart is safer than backing an opinion. Metrics have numbers and experiments have winners. If a decision goes wrong, you can always point to the data and say, \u201cwe followed the evidence.\u201d Over time, this can change the role of a product team where judgment slowly gives way to iteration, and taste gives way to performance. The product still evolves, but it does so without a clear sense of direction\u2026only a sense of momentum.    Guidance Everywhere Once experimentation becomes the default way decisions get made, changing behavior stops being theoretical and starts being procedural. At that point, nudges aren\u2019t a new idea. They\u2019re the obvious next move. It usually starts reasonably: \u201cWe shipped a feature. Users might not notice it.\u201d  Fair. So you add a little callout. Then a tooltip. Then an onboarding tour. Then a \u201cWhat\u2019s New\u201d screen. Then a little survey. Then another survey, because you didn\u2019t get enough responses the first time. By the time you\u2019re done dismissing everything, the tool has already taken more time than the task itself. If you\u2019ve ever read about (https://yalebooks.yale.edu/book/9780300262285/nudge/) \u201cchoice architecture\u201d and nudging , this will feel familiar. The modern language for it was popularized in the late 2000s, and the core idea is simple: how choices are presented changes what people do, even if nothing is technically forced. Then product teams go one step further. Instead of just shaping choices, you can shape timing . Prompts start showing up in the middle of workflows because that\u2019s when the user is \u201cmost engaged.\u201d The industry also has a whole discipline around persuasive design and how to move someone from intention to action with prompts, friction removal, and well-timed triggers. (https://www.demenzemedicinagenerale.net/images/mens-sana/Captology_Fogg_Behavior_Model.pdf) B.J. Fogg\u2019s behavior model is one of the more cited frameworks in this space. Some nudges are genuinely helpful. But the same machinery that helps you discover a feature can also be used to push you into something you didn\u2019t come here to do. And once the machinery exists, it gets reused. It\u2019s also why coming back to an app after you\u2019ve been away for as little as a week can feel like a game of Whac-A-Mole. Not because you forgot how to use the tool, but because the tool has been busy while you were gone. There\u2019s new tips, new tours, new \u201cwhat\u2019s new\u201d overlays, new announcements, new prompts that all want a click before you\u2019re allowed to do the thing you actually opened it for.    Push Notifications Then the smartphone era arrived and made interruption cheaper. Once you can send push notifications, you no longer have to wait for the user to open the tool. You can tap them on the shoulder whenever you want. (https://en.wikipedia.org/wiki/Apple_Push_Notification_service) Apple\u2019s push notification service arrived with iOS 3.0 in 2009, and it\u2019s hard to overstate what a shift this was for the \u201cwho initiates the interaction?\u201d question. Some of this is legitimate and genuinely helpful: messages you asked for alerts you configured reminders you chose  But we all know where it went: \u201cWe miss you.\u201d \u201cYou haven\u2019t finished setup.\u201d \u201cYou haven\u2019t tried this feature.\u201d \u201cCome back and see what\u2019s new.\u201d  All framed as helpful. All measured in engagement. And just like that, the tool starts acting less like a tool and more like a stalker.    In Defense To be fair, not every prompt is evil, and not every notification is marketing. Some software is genuinely complicated, and a little guidance prevents real mistakes. Some categories are basically made of alerts: messaging, security, banking, calendars, delivery tracking, anything where timing actually matters. Telemetry exists because some problems can\u2019t be found any other way. It\u2019s often the only method that enables teams to find the weird crashes that happen on one driver version, one device model, or one edge case you\u2019ll never reproduce in-house. Even the \u201cfeature tour\u201d has a defensible origin story. Users ask for improvements, teams ship them, and then users complain they didn\u2019t know the improvements existed. In other words, the same people who hate popups also punish you when you make changes silently. If you\u2019ve ever shipped a big UI redesign, you already know this. So the problem isn\u2019t that software ever teaches, asks, or informs. The problem is that once a company builds the machinery to do it, that machinery becomes cheap to reuse, and the incentives gradually pull it away from \u201chelp the user succeed\u201d toward \u201cmove the metric.\u201d What starts as an occasional heads-up becomes a permanent layer of UI exhaust. What starts as support becomes a funnel. What starts as a reminder becomes a habit-forming system. That\u2019s the drift I\u2019m talking about. Not guidance existing at all, but guidance becoming the default posture of the tool\u2026always talking, always nudging, always taking the first turn in the conversation. And once the tool decides it should initiate the interaction, the rest of the story is mostly mechanics.    Even the Builders Hate It One of the most bizarre contradictions in modern software is that the people building these engagement systems don\u2019t like them either! Ask anyone who works on onboarding popups, feature tours, lifecycle messaging, or in-app announcements how they feel when an app interrupts them mid-flow to announce something they didn\u2019t ask for. The answer is almost always the same. They hate it! Or at least they\u2019re annoyed. Find me the telemarketer who likes being called during their own dinner. The job exists because it works enough in aggregate, not because anyone enjoys being on either end of it. So why does it keep happening? Because inside companies, the incentives are clear and the measurements are easy. You can measure clicks and track whether they led to a \u201ccompletion.\u201d You can measure whether a nudge led to the next step in the funnel. You cannot easily measure the resentment. Or the rage clicks when they smash a button to dismiss another \u201cdid you know\u201d pop-up. You cannot easily chart the moment a user thinks, \u201cI used to like this product, and now it feels needy.\u201d You cannot easily quantify the slow erosion of trust. There\u2019s an older framing for this that I like: in an information-rich world, attention becomes the scarce resource . (https://gwern.net/doc/design/1971-simon.pdf) Herbert Simon wrote about this dynamic in 1971 , long before push notifications, app stores, or social media feeds. If your business runs on attention, and attention is scarce, then the pressure to \u201ccapture\u201d it becomes constant.    Tools Are Supposed to Get Out of the Way As the marketing adage goes: People don\u2019t want a drill. They want a hole in the wall.  The drill is just the tool. The outcome is the job. Nobody wakes up and says, \u201cI\u2019d like to buy a new drill today!\u201d Well, except drill enthusiasts, I suppose. Likewise, nobody wakes up and says, \u201cI\u2019d like to buy a new app today!\u201d In fact, your app is in the way of their objective. I could argue that nobody wants the hole either. What they really want is what comes after the hole. They want to hang photos of family and friends, souvenirs from trips, and artwork that makes a room feel like home. The drill and the hole are both just steps along the way. That distance matters. The further a tool is from the real human outcome, the more invisible it should be. The drill doesn\u2019t ask how you\u2019re enjoying your experience drilling. It doesn\u2019t upsell you on premium hole-making. It exists to disappear the moment it\u2019s done its job. This is a useful way to think about software. Most users don\u2019t want \u201csoftware.\u201d They want the outcome: write the document edit the photo pay the invoice file the taxes ship the code communicate with the team  Great tools get out of the way so the user can accomplish their goal. Your favorite products feel like they\u2019re not there. You open them, do the thing you came to do, and close them again without ever feeling managed, marketed to, or delayed. Your least favorite products tend to do the opposite. You use them because you have to, not because you want to.    Everything Gets \u201cSmart\u201d This pattern is spreading because \u201csmart\u201d is spreading. Smart TVs. Smart speakers. Smart thermostats. Smart appliances. Anything that joins your Wi-Fi can: update itself (often good) send diagnostics (often good) collect usage data (sometimes defensible) interrupt you (almost always annoying) market to you (almost never what you bought it for)  It\u2019s the same story as software, just with plastic and a power cord. One more backchannel: some \u201csmart\u201d TVs use (https://en.wikipedia.org/wiki/Automatic_content_recognition) Automatic Content Recognition (ACR) to identify what\u2019s on the screen and turn that into data. It\u2019s basically a pixel-sampled fingerprint of anything that shows up on your screen whether streamed, broadcast, or just played back locally. If you want a more academic version of how \u201cdata collection leads to prediction which leads to intervention\u201d becomes a business model, this is adjacent to what (https://news.harvard.edu/gazette/story/2019/03/harvard-professor-says-surveillance-capitalism-is-undermining-democracy/) Shoshana Zuboff describes as surveillance capitalism . It\u2019s not just observing behavior, but intervening to shape it.    How We Got Here None of these events ruined software by themselves. They just made the next step easier. 1990s: consumer internet connectivity becomes mainstream, and \u201conline\u201d stops being a special mode. 1996\u20131997: PointCast popularizes (https://www.wired.com/1997/03/ff-push/) \u201cpush\u201d to the desktop (including ads): software starts initiating the interaction. 1997: (https://www.forbes.com/sites/jaymcgregor/2014/08/15/the-man-who-invented-pop-up-ads-says-im-sorry/) pop-up ads arrive and interruption becomes a business model. 1997: (https://news.microsoft.com/source/1996/11/19/microsoft-office-97-released-to-manufacturing/) Office 97 ships with \u201cClippy\u201d the Office Assistant, the friendly ancestor of in-app nudges. 2000: \u201cautomatic updates\u201d becomes a normal expectation for consumer operating systems. 2005: (https://googlepress.blogspot.com/2005/03/google-agrees-to-acquire-urchin_28.html) Urchin \u2192 Google Analytics: instrumentation and dashboards go mainstream. July 10, 2008: (https://www.apple.com/newsroom/2008/07/10iPhone-3G-on-Sale-Tomorrow/) the App Store launches and app distribution becomes frictionless. June 17, 2009: (https://en.wikipedia.org/wiki/Apple_Push_Notification_service) push notifications arrive at scale on iOS (even if they weren\u2019t first): the app no longer has to wait for you to open it. Nov 4, 2009: Apple announces (https://www.apple.com/newsroom/2009/11/04Apple-Announces-Over-100-000-Apps-Now-Available-on-the-App-Store/) 2 billion push notifications already delivered, early proof that \u201ctap on the shoulder\u201d scales. 2010s: \u201c(https://www.sciencedirect.com/science/article/pii/S0040162523007965) growth hacking \u201d becomes a discipline; nudges, tours, overlays, and lifecycle messaging become standard product surface area. By 2011, Apple\u2019s review rules explicitly forbade using push for \u201cadvertising, promotions, or direct marketing.\u201d Mar 4, 2020: Apple changes course and (https://www.theverge.com/2020/3/4/21165087/ios-apple-push-notification-advertising-marketing-now-allowed-app-store) allows marketing push , but only with explicit opt-in. 2020s: \u201c(https://www.wired.com/story/tiktok-platforms-cory-doctorow/) enshittification \u201d becomes a word people recognize because enough people feel the pattern.  People use \u201censhittification\u201d to describe platform decay. What I\u2019m describing here is one of the mechanisms that makes that decay feel personal. It\u2019s the constant conversion of your attention into a (https://www.kpi.org/kpi-basics/) KPI .    Designing for Quiet I don\u2019t want to go back to floppy disks. I like fast updates. I like security patches. I like sync. I like crash reports when they help fix real issues. What I want is for \u201cphone home\u201d to be treated like a privileged capability, not an assumed right. In other domains, we treat privileged capabilities with care. We put them behind intentional choices. We build guardrails. And we treat abuse as a bug, not a growth opportunity. Here are a few practical ways out. And yes, we\u2019ve heard many of these before.    1) Make interruptions opt-in, and make opt-out permanent If you want to announce a feature, fine. Put it somewhere predictable. If you want to educate, fine. Let me ask for help. If you want to survey me, fine. Ask at a sensible moment and accept \u201cno\u201d as a real answer. Most importantly, if I turn something off, it should stay off! A tool should not require me to keep saying \u201cnot now.\u201d Or conveniently \u201cforget\u201d my choices in its next update.    2) Separate product health telemetry from growth telemetry Crash reports, performance metrics, and error logs are about stability. Engagement nudges are about behavior. When those get mixed together, the growth incentives win, because they produce the cleanest charts and the easiest wins. If you can\u2019t draw a clear line between \u201cthis helps us fix bugs\u201d and \u201cthis helps us juice numbers,\u201d the product will drift toward the numbers.    3) Use analytics as a flashlight, not a steering wheel Analytics are useful for asking better questions. They are not answers by themselves. Before removing a feature because \u201cnobody uses it,\u201d ask: Is it discoverable? Did we move it? Did we rename it? Is it used rarely because it solves rare but important problems? Is it used by a small set of power users who keep the whole system running?  Then talk to humans. Analytics can reduce guessing, but it can also create false certainty.    4) Optimize for trust, not just return visits Short-term engagement can be increased by annoyance. (https://www.tandfonline.com/doi/full/10.1080/23311975.2024.2361321) Long-term loyalty is harder and more valuable . The best products I use don\u2019t constantly remind me to use them. They quietly do their job so well that I come back when I need them. That\u2019s what tools are supposed to do.    5) Ship a real \u201cquiet mode\u201d Not \u201cquiet except for what we care about.\u201d Quiet . No popups. No tours. No surveys. No \u201cnews.\u201d No nudges. If the product is genuinely valuable, quiet mode should improve retention, because it respects the user\u2019s attention and intent. Also, it\u2019s a nice forcing function. If your product can\u2019t stand on its own without constantly poking the user, that\u2019s a signal. Maybe not the signal you want, but definitely a signal. Software didn\u2019t break all at once. It eroded slowly, one reasonable justification at a time. Each step made sense in isolation, and each step could be defended. Together, they reshaped the priorities of an entire industry. Once software became measurable in this way, it became optimizable in this way. And optimization has a way of eating everything else. Instead, let\u2019s make software that respects your attention, does its job well, and lets you get on with your life. That\u2019s what good software used to feel like and what it could feel like again. Good software is a tool that you operate, not a channel that operates on you. As always, (https://blog.mikeswanson.com/contact/) I love hearing from you .  Comments 31 responses to \u201cBackseat Software\u201d (John Avatar)   John (https://blog.mikeswanson.com/backseat-software/#comment-1405) January 19, 2026    Thank you for the historical perspective on how we got here. I am almost willing to pay extra money for truly quiet mode.  There\u2019s a reason that Clippy is one of the most hated \u2018features\u2019 ever shipped by Microsoft. And I think you\u2019ve nailed it.  (https://blog.mikeswanson.com/backseat-software/?replytocom=1405#respond) Reply     (John Avatar)   John (https://blog.mikeswanson.com/backseat-software/#comment-1412) January 29, 2026    \u201cBy 2011, Apple\u2019s review rules explicitly forbade using push for \u2018advertising, promotions, or direct marketing.\u201d\u2018 \u2026what happened to that? mainstream iOS apps spam us all the time now  (https://blog.mikeswanson.com/backseat-software/?replytocom=1412#respond) Reply     (Barry Avatar)   Barry (https://blog.mikeswanson.com/backseat-software/#comment-1413) January 29, 2026    Excellent. And true about more than software design. There are universal truths underneath all this behavior, instructive of how humans behave with each other generally.  My role has been the mediator between marketing, creatives, software development, and the C Suite \u2013\u00a0across several industries. Yet each company consisted of this team of critical players.  Over time, the people who rose to the C Suite came exclusively from a Marketing background. This meant that eventually, in product meetings, Marketing people dominated every discussion. The bosses and the marketers speak the same lingo. And did not understand or value the input of the other teams. Unsurprisingly, each company as a whole came to over-valued click metrics over product development. They actively de-valued the harder to measure qualities of good UI and software design \u2013\u00a0the actual elements that customers pay money for, and judge quality with every interaction. The skills and expertise of those teams were seen as cost centers to be reduced whenever possible. While more and more got invested in Marketing programs. Once this dynamic takes over, it\u2019s almost impossible to turn around.  I watched three formerly successful companies wither into bankruptcy by strangling loyal customers with marketing plans, instead of delivering good products. As the numbers continued down, in every meeting the solution was always more Marketing (popups, emails, surveys, discount codes, etc.), because they could measure clicks, and they wanted more clicks.  (https://blog.mikeswanson.com/backseat-software/?replytocom=1413#respond) Reply    (Guy V. Avatar)   Guy V. (https://blog.mikeswanson.com/backseat-software/#comment-1444) January 31, 2026    I fully agree that this is the root of the problem. What you are saying in your comment needs to be widely known.Unfortunately it now seems to have infected Apple as well.  (https://blog.mikeswanson.com/backseat-software/?replytocom=1444#respond) Reply       (J. Bee Avatar)   J. Bee (https://blog.mikeswanson.com/backseat-software/#comment-1414) January 29, 2026    I think this article is somewhat refusing to put it\u2019s finger on the simpler version of what\u2019s \u201cgoing wrong\u201d here.  It\u2019s advertising.  All of these bad practices are a result of trying to *advertise* products and features to the end user, without their consent.  Because of course, the nature of advertising is to operate explicitly *without* consent.  All this stuff happens because of the monetary incentive, and the view that users are just undifferentiated purchase bots that will probably buy more stuff if you throw it in their faces.  It\u2019s *not* actually morally OK to advertise to people without giving them the option to refuse.  It\u2019s not OK for instance, for Apple to advertise it\u2019s products and services within the OS as they now do, and not allow people to opt out from those advertisements.  This is exactly what made Microsoft of the 90\u2019s and early 2000\u2019s so absolutely vile. The fact that they extended themselves into services, and then sold their souls by advertising those services, (as well the \u2018cool features\u2019 of their own OS\u2019s), within the OS itself. The whole system became a nightmare of pop up suggestions and requests to buy into their services.  Apple is definitely moving strongly in that direction.  Switching to Apple *was* the breath of fresh air at the time, but now they\u2019re just doing the exact same thing that we all hated Microsoft for back then.  because: money  (https://blog.mikeswanson.com/backseat-software/?replytocom=1414#respond) Reply    (Miles Thatsme Avatar)   Miles Thatsme (https://blog.mikeswanson.com/backseat-software/#comment-1422) January 30, 2026    Agree with the insidiousness of advertising: I have trouble thinking of another industry where people pay to *not* receive your product (ads). Why not let people \u201cvote with their feet/wallets\u201d\u2014well, what if your primary source of intel about their votes is the ad industry? The subscription service model amplifies these problems, built upon entrenched platforms.  But I think this was a clear-eyed, more focused piece\u2014terrific.  (https://blog.mikeswanson.com/backseat-software/?replytocom=1422#respond) Reply     (walter Avatar)   walter (https://blog.mikeswanson.com/backseat-software/#comment-1430) January 30, 2026    100% in agreement. Apple has in fact become that  ogre that  the hammer was thrown at in that classic 1984 Super Bowl Ridley Scott commercial Ad. Apple has lost its soul.  (https://blog.mikeswanson.com/backseat-software/?replytocom=1430#respond) Reply       (Ian Davies Avatar)   Ian Davies (https://blog.mikeswanson.com/backseat-software/#comment-1415) January 29, 2026    Adobe is the cursed poster child for this now, IMO. Tours, surveys, the repulsive blue pop-ups, the utterly pointless crash windows that offer to look for a solution, but have yet to offer a single one in 23 years. The relentless disrespect for their users is one of the most miserable examples of enshittification.  (https://blog.mikeswanson.com/backseat-software/?replytocom=1415#respond) Reply    (Sam Schlesinger Avatar)   Sam Schlesinger (https://blog.mikeswanson.com/backseat-software/#comment-1443) January 31, 2026    Exactly. I pay for tools to do my job, not to be treated like a KPI. Every Adobe launch feels like running a gauntlet of promos, tours, upsells, counter-intuitive feature bars and useless crash dialogs before I can touch my actual work. It\u2019s not software anymore, it\u2019s internal metrics wearing a toolbar. Painfully ridiculous.  (https://blog.mikeswanson.com/backseat-software/?replytocom=1443#respond) Reply       (Dmitri Zdorov Avatar)   (https://dimka.com) Dmitri Zdorov  (https://blog.mikeswanson.com/backseat-software/#comment-1416) January 29, 2026    It\u2019s not just advertisement, it\u2019s hustling culture in general. Hustlers just do better overall. They sell more, they earn more, they get more prizes, they\u2019re more popular. And you can say that is chasing a quick buck, short-term profits, or maybe it\u2019s just what you get when there is too much competition, which is not as bad as too little, but still not optimal.  (https://blog.mikeswanson.com/backseat-software/?replytocom=1416#respond) Reply     (Scott H Avatar)   Scott H (https://blog.mikeswanson.com/backseat-software/#comment-1417) January 30, 2026    The part that discourages me is that I think we\u2019ve reached the point where half or more of the people working on products no longer remember how it was in the before times.  They don\u2019t realize that pooping popups and sign-ups and surveys and tutorials all over your carefully-crafted UI is a choice \u2013 for them, this is just the way things are.  (https://blog.mikeswanson.com/backseat-software/?replytocom=1417#respond) Reply     (Caitlin Steele Avatar)   (https://www.caitlinsteele.com/) Caitlin Steele  (https://blog.mikeswanson.com/backseat-software/#comment-1418) January 30, 2026    Wonderful article. I have struggled with a lot of this myself as a designer, developer, product owner and leader. A few months ago Vivianne Castillo said something about commerce not being capitalism and it stuck with me. I wrote a few articles last year about how tech has gone from being like startups panning for gold to open pit mining for mass extraction. I think the core of this is that software used to be about creating value and exchanging that value for money (commerce). Give me money and I give you a box of software you own. We have pivoted to models of extraction of value, from employees and from customers. Yay capitalism.  I miss building software that makes me proud to ship.  (https://blog.mikeswanson.com/backseat-software/?replytocom=1418#respond) Reply     (Neal Avatar)   Neal (https://blog.mikeswanson.com/backseat-software/#comment-1420) January 30, 2026    Lovely perspective and insight. I\u2019ll add another snippet from another thread. Pre-iPhone we had Symbian. Pre the onslaught of apps, social networks, attention economy, etc.It had this terrible activity where when the battery got below (from memory) 20%, the screen would blast on with an alert for low power. And do it continuously every couple of percent or minutes \u2013 even though though the phone was still going to run for another few days more likely! A constant distraction.(Little did we know what would come 15 years later of course and how simple this was!). The iPhone arrived \u2013 Apple (or perhaps Steve Jobs) had obviously put attention into those details of how to get out of your way and there was no way they were going to annoying you with alerts such as this.Of course, what you described above occurred \u2013 they added the App Store, push notifications (all great ideas) \u2013 and then they themselves fell down this slope in the recent years with \u2018new feature\u2019 announcements, incessant pushing, along with everyone else.  Honestly, the original few iterations of iOS were your point number 5\u2026\u2026  (https://blog.mikeswanson.com/backseat-software/?replytocom=1420#respond) Reply     (Foo Bar McGrath Avatar)   Foo Bar McGrath (https://blog.mikeswanson.com/backseat-software/#comment-1423) January 30, 2026    A great read \u2013 thanks for putting down so clearly what we have been experience for so long.  (https://blog.mikeswanson.com/backseat-software/?replytocom=1423#respond) Reply     (Philip Avatar)   Philip (https://blog.mikeswanson.com/backseat-software/#comment-1424) January 30, 2026    You don\u2019t mention the disappearance of user manuals. It used to be that if I,* Wanted to learn a new application, I work through the whole manual* Wanted to understand a feature, I\u2019d look it up in the manual.* Couldn\u2019t work out how to do something, I\u2019d go to the manual I\u2019d look in the manual. I\u2019d love it if user manuals were brought back. Then if I want to I\u2019ll refer to it, if I don\u2019t I won\u2019t. Now everything is supposed to be intuitive and we don\u2019t need any information on how to use an app. It\u2019s all common sense, until it isn\u2019t.  (https://blog.mikeswanson.com/backseat-software/?replytocom=1424#respond) Reply     (Denver Fletcher Avatar)   Denver Fletcher (https://blog.mikeswanson.com/backseat-software/#comment-1425) January 30, 2026    Very good. Thank you very much for writing it.And also, as attributed to Henry Ford, \u201cif I had asked people what they wanted, they would have said \u2018faster horses\u2019 \u201c.This illustrates the fatal allure of local optimization as the sole determinant of action. It forecloses innovation because what could be better than \u201cdata-driven decisions\u201d?Regarding Trust and Consent I would really like to send you something I think you would appreciate. Email me if so.  (https://blog.mikeswanson.com/backseat-software/?replytocom=1425#respond) Reply     (Kh\u00fcrt Louis Francis Elliot Williams Avatar)   (https://islandinthenet.com) Kh\u00fcrt Louis Francis Elliot Williams  (https://blog.mikeswanson.com/backseat-software/#comment-1426) January 30, 2026    I loved this because it names a feeling I\u2019ve had for years. I launch an app to do a job, not to be coached, nudged, or surveyed. Notifications for trivial things make me irrationally angry. The best tools vanish. They finish, quietly, and let me get on with my actual life.  (https://blog.mikeswanson.com/backseat-software/?replytocom=1426#respond) Reply     (tim Avatar)   tim (https://blog.mikeswanson.com/backseat-software/#comment-1427) January 30, 2026    \u201cHere are a few practical ways out.\u201d For whom, though?  You admit that users hate it, and engineers do, too, and companies are incentivized to do it anyway.  Who exactly is this advice for? This reads about like advice to \u201cDon\u2019t cause oil spills \u2014 nobody likes them\u201d.  Not untrue, but this fact alone doesn\u2019t suggest a path forward for anyone caught in the system.  (https://blog.mikeswanson.com/backseat-software/?replytocom=1427#respond) Reply    (Bruce Avatar)   Bruce (https://blog.mikeswanson.com/backseat-software/#comment-1435) January 30, 2026    @tim It\u2019s an educated rant, sometimes you just need to get things off your chest, you never know who reads it, could make a difference  (https://blog.mikeswanson.com/backseat-software/?replytocom=1435#respond) Reply       (g Avatar)   g (https://blog.mikeswanson.com/backseat-software/#comment-1428) January 30, 2026    Also Sparkle on Mac furthered the implementation of notifications  (https://blog.mikeswanson.com/backseat-software/?replytocom=1428#respond) Reply    (g Avatar)   g (https://blog.mikeswanson.com/backseat-software/#comment-1432) January 30, 2026    I mean, the initial idea was great, allow updates, but later on it got abused  (https://blog.mikeswanson.com/backseat-software/?replytocom=1432#respond) Reply     (Gordon Meyer Avatar)   Gordon Meyer (https://blog.mikeswanson.com/backseat-software/#comment-1438) January 30, 2026    Sparkle is horrible because, due to its tech and design, it can only interrupt what you\u2019re doing. I never launch an app to perform and update, I launch an app to accomplish some task, yet Sparkle rudely inserts itself at the worst possible moment.  (https://blog.mikeswanson.com/backseat-software/?replytocom=1438#respond) Reply       (Peter Kankowski Avatar)   (https://www.abareplace.com) Peter Kankowski  (https://blog.mikeswanson.com/backseat-software/#comment-1429) January 30, 2026    Many tools are implemented as SaaS now, so the developers have more options to watch users\u2019 behavior and experiment with surveys, CSAT, and cross promotions. Desktop software is still relatively quiet and private by design; at least, I don\u2019t collect any telemetry in my own program.  (https://blog.mikeswanson.com/backseat-software/?replytocom=1429#respond) Reply     (Jim Avatar)   Jim (https://blog.mikeswanson.com/backseat-software/#comment-1431) January 30, 2026    \u201cIt blocks your speedometer with an overlay tutorial \u2026 Ridiculous, of course.\u201d My 2017 Chevy has been doing this for nearly a decade already! It will block my speedometer while driving to let me know that a Bluetooth device briefly disconnected and then reconnected. It\u2019s got another popup that hides my speedometer every time it notices the outdoor temperature is near-or-below freezing, reminding me that ice may exist. No hysteresis either, so in spring and fall I\u2019ll sometimes get that popup several times during a single short drive when the temperature is hovering right around their alerting threshold. There\u2019s even a long wordy message that appears completely at random, including while driving, whose sole purpose is to remind me not to use the touchscreen while driving. It won\u2019t time out on its own, and dismissing it requires interacting with the touchscreen \u2014 unlike all other popups, you can\u2019t close this one with the buttons on the steering wheel. And of course, not a single one of these blatantly dangerous distractions can be disabled. I just have to live with them, which I can only assume is observed by the car\u2019s built-in telemetry and reported back to GM as a signal of \u201cacceptance\u201d.  (https://blog.mikeswanson.com/backseat-software/?replytocom=1431#respond) Reply     (Conan Avatar)   Conan (https://blog.mikeswanson.com/backseat-software/#comment-1433) January 30, 2026    I find it hard to think of a more evil job than advertising. Especially in the modern form using massive data and servers to slide in the advert of the bid winner. But it\u2019s all a consequence of our economic system and greed based system.  (https://blog.mikeswanson.com/backseat-software/?replytocom=1433#respond) Reply     (MacHobbes Avatar)   MacHobbes (https://blog.mikeswanson.com/backseat-software/#comment-1434) January 30, 2026    So great software is like great typography.  You enjoy it without noticing it.  (https://blog.mikeswanson.com/backseat-software/?replytocom=1434#respond) Reply     (Mark Avatar)   Mark (https://blog.mikeswanson.com/backseat-software/#comment-1436) January 30, 2026    Interesting history, but this seems incorrect:  \u20182000: \u201cautomatic updates\u201d becomes a normal expectation for consumer operating systems.\u2019 In Windows XP automatic updates were not enabled by default until service pack 2 was released in 2004. Prior to that the average user was not even aware they needed updates  (https://blog.mikeswanson.com/backseat-software/?replytocom=1436#respond) Reply     (Houss Avatar)   Houss (https://blog.mikeswanson.com/backseat-software/#comment-1437) January 30, 2026    Great article  (https://blog.mikeswanson.com/backseat-software/?replytocom=1437#respond) Reply     (Erik J. Barzeski Avatar)   (https://analyzrgolf.com/) Erik J. Barzeski  (https://blog.mikeswanson.com/backseat-software/#comment-1439) January 30, 2026    Thank you for writing this. The best software is the one that lets you discover \u2014 at your own pace \u2014 its features. I can look things up (on YouTube, Reddit, etc.) if I need to find out how to do something, but even then the truly great software will guide you through doing something without needing to truly hold your hand. It\u2019ll name menus with obvious and good titles. It\u2019ll put the tools in the right place. It\u2019ll have a good Help menu (oh how I miss those!). It won\u2019t try to do too much.  (https://blog.mikeswanson.com/backseat-software/?replytocom=1439#respond) Reply     (Don Barth Avatar)   Don Barth (https://blog.mikeswanson.com/backseat-software/#comment-1440) January 30, 2026    Thank you for this excellent article  (https://blog.mikeswanson.com/backseat-software/?replytocom=1440#respond) Reply     (Leon Zandman Avatar)   Leon Zandman (https://blog.mikeswanson.com/backseat-software/#comment-1442) January 31, 2026    Fun fact regarding push notification spam: On early Windows Phones (7/8), there actually was a technical reason to send push notifications regularly.The push channel (MPNS) could expire after inactivity, often without clear errors.If you didn\u2019t send anything for a while, pushes would just stop working until the app was reopened.So many apps sent \u201ckeep-alive\u201d notifications\u2014not for engagement, but to keep push delivery functional. Functional spam \ud83d\ude09  (https://blog.mikeswanson.com/backseat-software/?replytocom=1442#respond) Reply      Leave a Reply (/backseat-software/#respond) Cancel reply   Your email address will not be published. Required fields are marked *   Comment *    Name *  ()  Email *  ()  Website ()  (yes) Save my name, email, and website in this browser for the next time I comment.  (Post Comment) (1267) (0)  (383f3205a5)  \u0394  (1769962735635)           Click to Copy   "
                ],
                "output": "htmltotext.txt",
                "pwd": "/data/archive/1769962716.839376",
                "schema": "ArchiveResult",
                "start_ts": "2026-02-01T16:19:14.445032+00:00",
                "status": "succeeded"
            }
        ],
        "media": [
            {
                "cmd": [
                    "/usr/local/bin/yt-dlp",
                    "--restrict-filenames",
                    "--trim-filenames",
                    "128",
                    "--write-description",
                    "--write-info-json",
                    "--write-annotations",
                    "--write-thumbnail",
                    "--no-call-home",
                    "--write-sub",
                    "--write-auto-subs",
                    "--convert-subs=srt",
                    "--yes-playlist",
                    "--continue",
                    "--no-abort-on-error",
                    "--ignore-errors",
                    "--geo-bypass",
                    "--add-metadata",
                    "--format=(bv*+ba/b)[filesize<=750m][filesize_approx<=?750m]/(bv*+ba/b)",
                    "--skip-download",
                    "--cache-dir=/data/yt-dlp-cache/",
                    "--cookies=/data/yt-dlp-cache/cookies.txt",
                    "--proxy=socks5://tor-socks-proxy:9150",
                    "--no-playlist",
                    "https://blog.mikeswanson.com/backseat-software/"
                ],
                "cmd_version": "2024.10.7",
                "end_ts": "2026-02-01T16:19:20.944369+00:00",
                "index_texts": [],
                "output": "media/",
                "pwd": "/data/archive/1769962716.839376",
                "schema": "ArchiveResult",
                "start_ts": "2026-02-01T16:19:16.217608+00:00",
                "status": "succeeded"
            }
        ],
        "mercury": [
            {
                "cmd": [
                    "/home/archivebox/.npm/bin/postlight-parser",
                    "https://blog.mikeswanson.com/backseat-software/"
                ],
                "cmd_version": "2.2.3",
                "end_ts": "2026-02-01T16:19:14.412068+00:00",
                "index_texts": null,
                "output": "mercury/",
                "pwd": "/data/archive/1769962716.839376",
                "schema": "ArchiveResult",
                "start_ts": "2026-02-01T16:19:11.386805+00:00",
                "status": "succeeded"
            }
        ],
        "pdf": [],
        "readability": [
            {
                "cmd": [
                    "/home/archivebox/.npm/bin/readability-extractor",
                    "/tmp/tmpbkek7uly",
                    "https://blog.mikeswanson.com/backseat-software/"
                ],
                "cmd_version": "0.0.11",
                "end_ts": "2026-02-01T16:19:02.941807+00:00",
                "index_texts": [
                    "What if your car worked like so many apps? You\u2019re driving somewhere important\u2026maybe running a little bit late. A few minutes into the drive, your car pulls over to the side of the road and asks:\n\n\n\n\u201cHow are you enjoying your drive so far?\u201d\n\n\n\nAnnoyed by the interruption, and even more behind schedule, you dismiss the prompt and merge back into traffic.\n\n\n\nA minute later it does it again.\n\n\n\n\u201cDid you know I have a new feature? Tap here to learn more.\u201d\n\n\n\nIt blocks your speedometer with an overlay tutorial about the turn signal. It highlights the wiper controls and refuses to go away until you demonstrate mastery.\n\n\n\nRidiculous, of course.\n\n\n\nAnd yet, this is how a lot of modern software behaves. Not because it\u2019s broken, but because we\u2019ve normalized an interruption model that would be unacceptable almost anywhere else.\n\n\n\nI\u2019ve started to think of this as backseat software: the slow shift from software as a tool you operate to software as a channel that operates on you. Once a product learns it can talk back, it\u2019s remarkably hard to keep it quiet.\n\n\n\nThis post is about how we got here. Not overnight, but slowly. One reasonable step at a time.\n\n\n\nSoftware Came on Disks\n\n\n\nThere was a time when software shipped on physical media: floppy disks, CD-ROMs, sometimes even with a spiral-bound manual.\n\n\n\nSoftware felt like a product back then. You bought it, installed it, and used it. If you upgraded, it was because you chose to. The software didn\u2019t constantly change underneath you, and it didn\u2019t have the opportunity to ask for your attention beyond whatever UI the developers shipped on day one.\n\n\n\nThat era had real downsides. If you shipped a serious bug, you lived with it until the next release, which could be weeks or months away. If security issues were discovered, your options ranged from \u201cmail a patch\u201d to \u201cgood luck.\u201d In hindsight, it\u2019s amazing we survived!\n\n\n\nBut something else was true too. When you were using the software, you were alone with it.\n\n\n\nAs a software developer, if something was wrong, you found out because users told you. Sometimes loudly. Sometimes angrily. Often on message forums or during support calls.\n\n\n\nFeedback was slower and scarcer, but it was real. It was also \u201cexpensive\u201d in the way that matters. You had to earn it, listen to it, and interpret it.\n\n\n\nAlways Online\n\n\n\nThen the internet arrived, and for a while it was almost entirely upside.\n\n\n\nSoftware could finally be updated after it shipped. Bugs could be fixed. Security holes could be closed. Documentation got easier. Support got easier. The idea of \u201cship it and hope for the best\u201d started to fade.\n\n\n\nMicrosoft\u2019s update infrastructure is a good example of the era. Updates moved from \u201cgo download this\u201d toward automation over time, and by the early 2000s the industry was normalizing the idea that your machine could check for and apply updates regularly.\n\n\n\nThis was a genuine leap forward in quality and safety. If you\u2019ve ever been on the receiving end of a serious bug report, you know how valuable it is to fix something now rather than in the next boxed release.\n\n\n\nSo far, so good.\n\n\n\nThe Back Channel\n\n\n\nOnce software could reliably connect to the internet, it no longer just received instructions. It could talk back to the company that made it.\n\n\n\nAt first, this too was mostly good. Crash reports made it easier to fix real problems, update checks were convenient, and license activation reduced some kinds of piracy. Teams could finally see patterns in failure modes instead of guessing.\n\n\n\nDevelopers like me love this kind of feedback loop, and for good reason. A tool that improves over time is better than one that doesn\u2019t.\n\n\n\nBut that back channel didn\u2019t stay limited to \u201cthis crashed\u201d and \u201cthere\u2019s an update.\u201d It expanded, quietly, because once you can send some data home, the next question arrives right on schedule:\n\n\n\n\u201cSince we\u2019re already connected\u2026what else can we learn?\u201d\n\n\n\nEverything Gets Measured\n\n\n\nOnce software could send data home, the next natural thought was:\n\n\n\n\u201cCan we understand how people actually use this?\u201d\n\n\n\nAgain, that\u2019s not an evil thought. In fact, it\u2019s useful! Before analytics, if you wanted to understand user behavior, you had to ask people, watch them, or infer patterns from support tickets. That requires time, empathy, and effort.\n\n\n\nSuddenly, you didn\u2019t have to guess anymore.\n\n\n\nWeb analytics going mainstream is one of those quiet accelerants. Google\u2019s acquisition of Urchin in 2005, and the rise of Google Analytics shortly after, helped normalize the idea that instrumentation and dashboards were simply part of building software.\n\n\n\nInstead of arguing in a meeting about which features mattered most, you could look at usage data. Instead of guessing where people struggled, you could see drop-offs. Instead of relying on the loudest customer, you could get a broader view.\n\n\n\nBut somewhere along the way, the center of gravity shifted.\n\n\n\nUsage data stopped being a tool for improving software and became a tool for optimizing behavior. The question quietly changed from:\n\n\n\n\u201cIs this good software?\u201d\n\n\n\nto:\n\n\n\n\u201cDoes this increase engagement?\u201d\n\n\n\nAnd that\u2019s when the vocabulary starts to creep in. DAU. MAU. Retention. Funnels. Stickiness. Cohorts. Conversion. Gamification. Oh my!\n\n\n\nIf you\u2019ve worked inside a modern product organization, you\u2019ve heard these words so often they start to feel unavoidable.\n\n\n\nMetrics Can Be Correct and Still Be Wrong\n\n\n\nOne of the most dangerous things about analytics is that they feel objective. A chart is a chart. A number is a number. They have the aesthetic of truth.\n\n\n\nI\u2019ve always liked this quote by William Bruce Cameron (often misattributed to Albert Einstein):\n\n\n\n\u201cNot everything that can be counted counts, and not everything that counts can be counted.\u201d\n\n\n\nMetrics don\u2019t measure reality. They measure what your product currently makes easy.\n\n\n\nThere\u2019s a well-known warning about this, often summarized as: when a measure becomes a target, it stops being a good measure. It\u2019s commonly referred to as Goodhart\u2019s Law, and the broader point shows up in multiple fields, because it keeps happening to humans in systems with incentives.\n\n\n\nWhen I was at Microsoft, a team wanted to remove a feature because \u201cthe analytics show that nobody uses it.\u201d If you looked at the UI, though, that feature had been moved deeper and deeper over time:\n\n\n\n\nit used to be easy to find\n\n\n\nthen it moved into a menu\n\n\n\nthen into a submenu\n\n\n\nthen into a settings panel\n\n\n\nthen behind an \u201cadvanced\u201d section\n\n\n\nthen it was basically invisible\n\n\n\n\nOf course nobody used it!\n\n\n\nThe analytics didn\u2019t prove the feature was unwanted. The analytics proved that we buried it.\n\n\n\nEven worse, once a metric becomes a target, people get promoted for moving it. That doesn\u2019t require anyone to be malicious. It just requires incentives and a dashboard.\n\n\n\nExperimenting in Production\n\n\n\nMeasuring behavior changes what feels possible:\n\n\n\n\u201cWhat if we try two versions to see which one performs better?\u201d\n\n\n\nThis is where A/B testing enters the story.\n\n\n\nOn paper, it\u2019s an engineering triumph! Instead of arguing about opinions, you can test ideas. Instead of debating copy or layout in a meeting, you can ship both and let real-world behavior decide.\n\n\n\nBut A/B testing quietly changes the role of the product team. You\u2019re no longer just building a tool and observing how it\u2019s used. You\u2019re now running experiments on people\u2026adjusting wording, placement, timing, friction, and flow to see what moves the metric.\n\n\n\nAt that point, the product stops being a finished artifact and starts behaving like a laboratory. Every screen becomes provisional, and every interaction becomes a hypothesis. Once that mindset takes hold, it\u2019s very hard not to optimize for what moves fastest, even if it moves the wrong thing.\n\n\n\nThere\u2019s a quieter consequence here that doesn\u2019t get talked about much. When experimentation becomes the primary decision-making tool, a strong product vision becomes optional.\n\n\n\nNot because anyone argues against vision, but because you don\u2019t strictly need it anymore, and because backing a chart is safer than backing an opinion. Metrics have numbers and experiments have winners. If a decision goes wrong, you can always point to the data and say, \u201cwe followed the evidence.\u201d\n\n\n\nOver time, this can change the role of a product team where judgment slowly gives way to iteration, and taste gives way to performance. The product still evolves, but it does so without a clear sense of direction\u2026only a sense of momentum.\n\n\n\nGuidance Everywhere\n\n\n\nOnce experimentation becomes the default way decisions get made, changing behavior stops being theoretical and starts being procedural.\n\n\n\nAt that point, nudges aren\u2019t a new idea. They\u2019re the obvious next move. It usually starts reasonably:\n\n\n\n\u201cWe shipped a feature. Users might not notice it.\u201d\n\n\n\nFair.\n\n\n\nSo you add a little callout. Then a tooltip. Then an onboarding tour. Then a \u201cWhat\u2019s New\u201d screen. Then a little survey. Then another survey, because you didn\u2019t get enough responses the first time. By the time you\u2019re done dismissing everything, the tool has already taken more time than the task itself.\n\n\n\nIf you\u2019ve ever read about \u201cchoice architecture\u201d and nudging, this will feel familiar. The modern language for it was popularized in the late 2000s, and the core idea is simple: how choices are presented changes what people do, even if nothing is technically forced.\n\n\n\nThen product teams go one step further. Instead of just shaping choices, you can shape timing. Prompts start showing up in the middle of workflows because that\u2019s when the user is \u201cmost engaged.\u201d\n\n\n\nThe industry also has a whole discipline around persuasive design and how to move someone from intention to action with prompts, friction removal, and well-timed triggers. B.J. Fogg\u2019s behavior model is one of the more cited frameworks in this space.\n\n\n\nSome nudges are genuinely helpful. But the same machinery that helps you discover a feature can also be used to push you into something you didn\u2019t come here to do. And once the machinery exists, it gets reused.\n\n\n\nIt\u2019s also why coming back to an app after you\u2019ve been away for as little as a week can feel like a game of Whac-A-Mole. Not because you forgot how to use the tool, but because the tool has been busy while you were gone. There\u2019s new tips, new tours, new \u201cwhat\u2019s new\u201d overlays, new announcements, new prompts that all want a click before you\u2019re allowed to do the thing you actually opened it for.\n\n\n\nPush Notifications\n\n\n\nThen the smartphone era arrived and made interruption cheaper. Once you can send push notifications, you no longer have to wait for the user to open the tool. You can tap them on the shoulder whenever you want.\n\n\n\nApple\u2019s push notification service arrived with iOS 3.0 in 2009, and it\u2019s hard to overstate what a shift this was for the \u201cwho initiates the interaction?\u201d question.\n\n\n\nSome of this is legitimate and genuinely helpful:\n\n\n\n\nmessages you asked for\n\n\n\nalerts you configured\n\n\n\nreminders you chose\n\n\n\n\nBut we all know where it went:\n\n\n\n\n\u201cWe miss you.\u201d\n\n\n\n\u201cYou haven\u2019t finished setup.\u201d\n\n\n\n\u201cYou haven\u2019t tried this feature.\u201d\n\n\n\n\u201cCome back and see what\u2019s new.\u201d\n\n\n\n\nAll framed as helpful. All measured in engagement. And just like that, the tool starts acting less like a tool and more like a stalker.\n\n\n\nIn Defense\n\n\n\nTo be fair, not every prompt is evil, and not every notification is marketing.\n\n\n\nSome software is genuinely complicated, and a little guidance prevents real mistakes. Some categories are basically made of alerts: messaging, security, banking, calendars, delivery tracking, anything where timing actually matters.\n\n\n\nTelemetry exists because some problems can\u2019t be found any other way. It\u2019s often the only method that enables teams to find the weird crashes that happen on one driver version, one device model, or one edge case you\u2019ll never reproduce in-house.\n\n\n\nEven the \u201cfeature tour\u201d has a defensible origin story. Users ask for improvements, teams ship them, and then users complain they didn\u2019t know the improvements existed. In other words, the same people who hate popups also punish you when you make changes silently. If you\u2019ve ever shipped a big UI redesign, you already know this.\n\n\n\nSo the problem isn\u2019t that software ever teaches, asks, or informs. The problem is that once a company builds the machinery to do it, that machinery becomes cheap to reuse, and the incentives gradually pull it away from \u201chelp the user succeed\u201d toward \u201cmove the metric.\u201d\n\n\n\nWhat starts as an occasional heads-up becomes a permanent layer of UI exhaust. What starts as support becomes a funnel. What starts as a reminder becomes a habit-forming system.\n\n\n\nThat\u2019s the drift I\u2019m talking about. Not guidance existing at all, but guidance becoming the default posture of the tool\u2026always talking, always nudging, always taking the first turn in the conversation.\n\n\n\nAnd once the tool decides it should initiate the interaction, the rest of the story is mostly mechanics.\n\n\n\nEven the Builders Hate It\n\n\n\nOne of the most bizarre contradictions in modern software is that the people building these engagement systems don\u2019t like them either!\n\n\n\nAsk anyone who works on onboarding popups, feature tours, lifecycle messaging, or in-app announcements how they feel when an app interrupts them mid-flow to announce something they didn\u2019t ask for. The answer is almost always the same.\n\n\n\nThey hate it! Or at least they\u2019re annoyed.\n\n\n\nFind me the telemarketer who likes being called during their own dinner. The job exists because it works enough in aggregate, not because anyone enjoys being on either end of it.\n\n\n\nSo why does it keep happening? Because inside companies, the incentives are clear and the measurements are easy. You can measure clicks and track whether they led to a \u201ccompletion.\u201d You can measure whether a nudge led to the next step in the funnel.\n\n\n\nYou cannot easily measure the resentment. Or the rage clicks when they smash a button to dismiss another \u201cdid you know\u201d pop-up. You cannot easily chart the moment a user thinks, \u201cI used to like this product, and now it feels needy.\u201d You cannot easily quantify the slow erosion of trust.\n\n\n\nThere\u2019s an older framing for this that I like: in an information-rich world, attention becomes the scarce resource. Herbert Simon wrote about this dynamic in 1971, long before push notifications, app stores, or social media feeds.\n\n\n\nIf your business runs on attention, and attention is scarce, then the pressure to \u201ccapture\u201d it becomes constant.\n\n\n\nTools Are Supposed to Get Out of the Way\n\n\n\nAs the marketing adage goes:\n\n\n\nPeople don\u2019t want a drill. They want a hole in the wall.\n\n\n\nThe drill is just the tool. The outcome is the job. Nobody wakes up and says, \u201cI\u2019d like to buy a new drill today!\u201d Well, except drill enthusiasts, I suppose. Likewise, nobody wakes up and says, \u201cI\u2019d like to buy a new app today!\u201d In fact, your app is in the way of their objective.\n\n\n\nI could argue that nobody wants the hole either.\n\n\n\nWhat they really want is what comes after the hole. They want to hang photos of family and friends, souvenirs from trips, and artwork that makes a room feel like home. The drill and the hole are both just steps along the way.\n\n\n\nThat distance matters. The further a tool is from the real human outcome, the more invisible it should be. The drill doesn\u2019t ask how you\u2019re enjoying your experience drilling. It doesn\u2019t upsell you on premium hole-making. It exists to disappear the moment it\u2019s done its job.\n\n\n\nThis is a useful way to think about software. Most users don\u2019t want \u201csoftware.\u201d They want the outcome:\n\n\n\n\nwrite the document\n\n\n\nedit the photo\n\n\n\npay the invoice\n\n\n\nfile the taxes\n\n\n\nship the code\n\n\n\ncommunicate with the team\n\n\n\n\nGreat tools get out of the way so the user can accomplish their goal.\n\n\n\nYour favorite products feel like they\u2019re not there. You open them, do the thing you came to do, and close them again without ever feeling managed, marketed to, or delayed.\n\n\n\nYour least favorite products tend to do the opposite. You use them because you have to, not because you want to.\n\n\n\nEverything Gets \u201cSmart\u201d\n\n\n\nThis pattern is spreading because \u201csmart\u201d is spreading. Smart TVs. Smart speakers. Smart thermostats. Smart appliances. Anything that joins your Wi-Fi can:\n\n\n\n\nupdate itself (often good)\n\n\n\nsend diagnostics (often good)\n\n\n\ncollect usage data (sometimes defensible)\n\n\n\ninterrupt you (almost always annoying)\n\n\n\nmarket to you (almost never what you bought it for)\n\n\n\n\nIt\u2019s the same story as software, just with plastic and a power cord.\n\n\n\nOne more backchannel: some \u201csmart\u201d TVs use Automatic Content Recognition (ACR) to identify what\u2019s on the screen and turn that into data. It\u2019s basically a pixel-sampled fingerprint of anything that shows up on your screen whether streamed, broadcast, or just played back locally.\n\n\n\nIf you want a more academic version of how \u201cdata collection leads to prediction which leads to intervention\u201d becomes a business model, this is adjacent to what Shoshana Zuboff describes as surveillance capitalism. It\u2019s not just observing behavior, but intervening to shape it.\n\n\n\nHow We Got Here\n\n\n\nNone of these events ruined software by themselves. They just made the next step easier.\n\n\n\n\n1990s: consumer internet connectivity becomes mainstream, and \u201conline\u201d stops being a special mode.\n\n\n\n1996\u20131997: PointCast popularizes \u201cpush\u201d to the desktop (including ads): software starts initiating the interaction.\n\n\n\n1997: pop-up ads arrive and interruption becomes a business model.\n\n\n\n1997: Office 97 ships with \u201cClippy\u201d the Office Assistant, the friendly ancestor of in-app nudges.\n\n\n\n2000: \u201cautomatic updates\u201d becomes a normal expectation for consumer operating systems.\n\n\n\n2005: Urchin \u2192 Google Analytics: instrumentation and dashboards go mainstream.\n\n\n\nJuly 10, 2008: the App Store launches and app distribution becomes frictionless.\n\n\n\nJune 17, 2009: push notifications arrive at scale on iOS (even if they weren\u2019t first): the app no longer has to wait for you to open it.\n\n\n\nNov 4, 2009: Apple announces 2 billion push notifications already delivered, early proof that \u201ctap on the shoulder\u201d scales.\n\n\n\n2010s: \u201cgrowth hacking\u201d becomes a discipline; nudges, tours, overlays, and lifecycle messaging become standard product surface area.\n\n\n\nBy 2011, Apple\u2019s review rules explicitly forbade using push for \u201cadvertising, promotions, or direct marketing.\u201d\n\n\n\nMar 4, 2020: Apple changes course and allows marketing push, but only with explicit opt-in.\n\n\n\n2020s: \u201censhittification\u201d becomes a word people recognize because enough people feel the pattern.\n\n\n\n\nPeople use \u201censhittification\u201d to describe platform decay. What I\u2019m describing here is one of the mechanisms that makes that decay feel personal. It\u2019s the constant conversion of your attention into a KPI.\n\n\n\nDesigning for Quiet\n\n\n\nI don\u2019t want to go back to floppy disks. I like fast updates. I like security patches. I like sync. I like crash reports when they help fix real issues.\n\n\n\nWhat I want is for \u201cphone home\u201d to be treated like a privileged capability, not an assumed right. In other domains, we treat privileged capabilities with care. We put them behind intentional choices. We build guardrails. And we treat abuse as a bug, not a growth opportunity.\n\n\n\nHere are a few practical ways out. And yes, we\u2019ve heard many of these before.\n\n\n\n1) Make interruptions opt-in, and make opt-out permanent\n\n\n\nIf you want to announce a feature, fine. Put it somewhere predictable.\n\n\n\nIf you want to educate, fine. Let me ask for help.\n\n\n\nIf you want to survey me, fine. Ask at a sensible moment and accept \u201cno\u201d as a real answer.\n\n\n\nMost importantly, if I turn something off, it should stay off! A tool should not require me to keep saying \u201cnot now.\u201d Or conveniently \u201cforget\u201d my choices in its next update.\n\n\n\n2) Separate product health telemetry from growth telemetry\n\n\n\nCrash reports, performance metrics, and error logs are about stability.\n\n\n\nEngagement nudges are about behavior.\n\n\n\nWhen those get mixed together, the growth incentives win, because they produce the cleanest charts and the easiest wins. If you can\u2019t draw a clear line between \u201cthis helps us fix bugs\u201d and \u201cthis helps us juice numbers,\u201d the product will drift toward the numbers.\n\n\n\n3) Use analytics as a flashlight, not a steering wheel\n\n\n\nAnalytics are useful for asking better questions. They are not answers by themselves. Before removing a feature because \u201cnobody uses it,\u201d ask:\n\n\n\n\nIs it discoverable?\n\n\n\nDid we move it?\n\n\n\nDid we rename it?\n\n\n\nIs it used rarely because it solves rare but important problems?\n\n\n\nIs it used by a small set of power users who keep the whole system running?\n\n\n\n\nThen talk to humans. Analytics can reduce guessing, but it can also create false certainty.\n\n\n\n4) Optimize for trust, not just return visits\n\n\n\nShort-term engagement can be increased by annoyance. Long-term loyalty is harder and more valuable.\n\n\n\nThe best products I use don\u2019t constantly remind me to use them. They quietly do their job so well that I come back when I need them. That\u2019s what tools are supposed to do.\n\n\n\n5) Ship a real \u201cquiet mode\u201d\n\n\n\nNot \u201cquiet except for what we care about.\u201d\n\n\n\nQuiet.\n\n\n\nNo popups. No tours. No surveys. No \u201cnews.\u201d No nudges.\n\n\n\nIf the product is genuinely valuable, quiet mode should improve retention, because it respects the user\u2019s attention and intent.\n\n\n\nAlso, it\u2019s a nice forcing function. If your product can\u2019t stand on its own without constantly poking the user, that\u2019s a signal. Maybe not the signal you want, but definitely a signal.\n\n\n\nSoftware didn\u2019t break all at once. It eroded slowly, one reasonable justification at a time.\n\n\n\nEach step made sense in isolation, and each step could be defended. Together, they reshaped the priorities of an entire industry. Once software became measurable in this way, it became optimizable in this way. And optimization has a way of eating everything else.\n\n\n\nInstead, let\u2019s make software that respects your attention, does its job well, and lets you get on with your life. That\u2019s what good software used to feel like and what it could feel like again. Good software is a tool that you operate, not a channel that operates on you.\n\n\n\nAs always, I love hearing from you."
                ],
                "output": "readability/",
                "pwd": "/data/archive/1769962716.839376",
                "schema": "ArchiveResult",
                "start_ts": "2026-02-01T16:18:59.328456+00:00",
                "status": "succeeded"
            }
        ],
        "screenshot": [],
        "singlefile": [],
        "title": [
            {
                "cmd": [
                    "/usr/bin/curl",
                    "--silent",
                    "--location",
                    "--compressed",
                    "--proxy",
                    "socks5://tor-socks-proxy:9150",
                    "--max-time",
                    "60",
                    "--user-agent",
                    "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)",
                    "https://blog.mikeswanson.com/backseat-software/"
                ],
                "cmd_version": "8.10.1",
                "end_ts": "2026-02-01T16:18:58.654678+00:00",
                "index_texts": null,
                "output": "Backseat Software \u2013 Mike Swanson's Blog",
                "pwd": "/data/archive/1769962716.839376",
                "schema": "ArchiveResult",
                "start_ts": "2026-02-01T16:18:58.573236+00:00",
                "status": "succeeded"
            }
        ],
        "wget": []
    },
    "icons": null,
    "is_archived": true,
    "is_static": false,
    "latest": {
        "archive_org": "ArchiveError: Failed to find \"content-location\" URL header in Archive.org response.",
        "dom": "output.html",
        "favicon": "favicon.ico",
        "git": null,
        "media": "media/",
        "pdf": null,
        "screenshot": null,
        "singlefile": null,
        "title": "Backseat Software \u2013 Mike Swanson's Blog",
        "warc": null,
        "wget": null
    },
    "link_dir": "/data/archive/1769962716.839376",
    "newest_archive_date": "2026-02-01T16:19:20.984729+00:00",
    "num_failures": 1,
    "num_outputs": 8,
    "oldest_archive_date": "2026-02-01T16:18:41.229972+00:00",
    "path": "/backseat-software/",
    "schema": "Link",
    "scheme": "https",
    "snapshot_abid": "snp_01KGCZZFPE45C5A268013BKK9Z",
    "snapshot_id": "0a76dfa8-a54b-4b12-a96b-7ab186b9cd3f",
    "sources": [
        "/data/sources/1769962715-import.txt"
    ],
    "tags": null,
    "tags_str": "",
    "timestamp": "1769962716.839376",
    "title": "Backseat Software \u2013 Mike Swanson's Blog",
    "url": "https://blog.mikeswanson.com/backseat-software/"
}