I recently became a parent for the first time, as my wife and I welcomed a beautiful baby boy into our lives in January of this year. As I write this, we are still in the first weeks of adjusting to the maelstrom of caring for a fragile, precious life that demands round-the-clock attention. In other words, we are not getting very much sleep.
As a productivity nerd, I have in recent years been getting more data-driven about my health. I now wear a FitBit, which I use, among other things, to track my sleep, and so of course I was curious to see what the FitBit app could tell me about my new sleep patterns. Unfortunately, I hit a limitation quite quickly: the UX largely expects you to have a single, unbroken sleep session each night. With a newborn that needs feeding every 2-3 hours, and sleep often coming in snatched naps throughout the day, much of what I wanted to see was hidden behind design decisions that catered to the median user rather than the edge case.
But hey, it’s 2026, AI coding agents exist, and FitBit has a public API. So I did what any self-respecting sleep-deprived engineer would do: I vibe coded a custom interface to help me visualise my sleep throughout each day. Then I added features to help answer some questions I had: When should I have a nap? Why did I sometimes feel more tired after a sleep session than before? What was the impact on my health? Was I gradually getting more tired each day?
It took me an hour or two with my coding agent of choice, and I had something. Here’s a view of a typical day:
This immediately told me a few things: during the middle of the night, my lack of sleep plus the impact of my circadian rhythm meant I was dangerously tired until the baby settled enough for me to eventually go to sleep; my afternoon nap was too short to really refresh me enough; I was ending the day more or less as tired as I started it; the disruption to my schedule and sleep patterns would be affecting my hormones and mean I’d gradually feel worse over time.
The app is very basic, but at the moment this is genuinely useful to me, and a few weeks later I am still checking it more frequently than the FitBit app.
“Did I just create a new product?”
Leaving aside whether you’re impressed by this basic view or not, it might be tempting to think that I just vibe coded a cool little product that I could ship to other sleep-deprived dads. While the idea is flattering, it mistakes the tip of the iceberg for the whole thing. A valuable product is much more than simply an interface.
Fundamentally, a FitBit is a wearable health watch, a database of my health data over time, and a whole platform for modelling, understanding, and analysing that. Those are the unique product capabilities of FitBit, and the mobile app and website are just interfaces sat on top of that which expose the value to the user. In generic terms, that looks a bit like this:
The “product” is all of these pieces put together. The mobile app and the web UI both draw from a set of common exposed capabilities, which for simplicity’s sake we’ll group under a common “API” (though of course the reality is likely more nuanced ). As a user, I experience the unique capabilities of the product via one or more interfaces that draw from the services exposed by the platform.
So where does my custom sleep UI fit in? Well, we can think of it as an additional component in the interface layer, but one that is built by and for only me:
I have written before about AI giving rise to a new class of disposable software, and my custom interface is a prime example. The customer segment of people already wearing a FitBit who are also experiencing sleep disruption like this is vanishingly small, and (I hope) won’t even include me in a few months time. It is also a long way from meeting even the modest demands of an MVP (no login, no security, no onboarding, no vetting of the underlying science, etc). I have no desire to invest the time or effort in clearing that low bar. And, to be clear, the app is absolutely useless if I stop being a FitBit customer.
Instead, my app augments an existing product with a niche customer need that only applies to me at this particular moment, and once I’m done with it, I’ll throw it away. It is truly disposable software, and the time, effort, and token cost of building it reflect that.
How durable products can benefit from vibe coding
My sleep app exists only because FitBit made its data available through a public API long before AI coding tools came along. That decision, made for entirely different reasons, is what allowed me to extend their product into a use case they never designed for. AI-assisted coding is putting that kind of personal software within reach of anyone.
So vibe coding is therefore useful for more than prototyping new products: it also enables end users to extend the products they already love with features that matter only to them. Even better, they can do this without diminishing their loyalty or value as a customer of the core product. Enabling users to build their own personal interfaces that extend services they love can be a great driver of product stickiness, and businesses can encourage this level of interaction without risking revenue loss.
The easiest and most reliable way to enable this mass personalisation is also the most well-established: exposing and documenting a comprehensive API that enables customers to access each of your product’s unique capabilities programmatically.
FitBit's API dates from a time when this approach was standard, but in recent years the trend has been away from openness and more towards control. For example, in its early days, Twitter was little more than an API, and a glorious ecosystem of third party tools that used it in different ways helped to drive adoption. But as the Internet slowly became enshittified, those tools were killed off and customers were funnelled into the approved website and apps, in the hopes of driving greater monetisation from an established customer base. Of course, X still has a public API, but you must now pay to access it. The interface layer for customers, in other words, shrank to include only a small number of first party components.
But in 2026, AI might be turning back the tide.
AI agents are bypassing traditional interfaces
Users are rapidly adopting autonomous AI agents, including those that entirely bypass first and third party interfaces and deliver product capabilities directly within external AI products such as ChatGPT. While some agents can directly use a headless or regular browser, adoption of standards such as MCP is helping make it efficient for agents to programmatically call existing services.
Instead of vibe coding my sleep app, I could, of course, have simply asked my preferred agent to answer my questions directly. Open source MCP servers for the FitBit API would make this trivial to do, and the one-off calculations that the agent would have run represent perhaps the most disposable of all software. There would have been no need for me to even open the FitBit app:
This disintermediation will seem alarming to businesses who primarily monetise their products in the interface layer. This includes publishers that rely on visual advertising on their website, though of course this is merely the latest step in a long line of ways that technology is being used to surface their unique product capability (journalism) via channels that bypass their monetisable interfaces.
While some businesses will be harmed by this rapid broadening of the interface surface, those who primarily monetise at the service level (such as subscription products) are better placed to withstand the disruption, or even to benefit. The key point here is that vibe coded apps, MCP servers, and any future paradigms developed in the coming years all continue to connect the user to unique product capabilities via your API:
By making the service layer a public surface of your product, you embrace a world in which you can safely surrender control of your interfaces without losing the product relationship with your customer.
The service layer is the product
In closed product ecosystems, the service layer is often the durable part of the stack. APIs grow and mature at a steady pace, while above it the interface layer churns through new apps and websites at a speed driven by fashion, taste, and economics.
In the past, businesses could expand their footprint by opening up their API to external developers, adopting an open source mindset, and building a technical community that integrated core product capabilities into different workflows.
In 2026, AI is set to tear apart the concept of a closed product ecosystem in multiple ways. AI agents interact with products on behalf of human users, and consumers can vibe code features that you cut or never intended to build. Inevitably, interfaces will be called programmatically, and businesses that monetise that interaction will outlast those who do not.
In a world of industrial software creation, interfaces are cheap and disposable.
The opportunity for product designers is to monetise the capability, not the interface. In a world where custom interfaces can be created in an afternoon, the only durable part of your product is the service layer. Build that well, and let everything above it fragment.