Building an App People Actually Use is an Art

A few weeks ago, a developer named Sayan Nayak posted this on Twitter: “At this rate everyone’s gonna have their own app and zero users.” It got 16,000 likes in about a day. The reason is obvious to anyone who has shipped anything in the last twelve months.

The barrier to building an app in 2026 is approaching zero. AI can hand you a working prototype in an afternoon. Vibe coding has turned “I have an idea” into “I have something to demo” faster than at any point in the history of software. And the result, predictably, is that the market is now drowning in half-baked prototypes that nobody opens twice.

I want to be precise about something before I go further: I have made this mistake. More than once. The frameworks below are not me hovering above the industry pointing at other people’s failures. They are the lessons I learned the slow way, by building things that did not get used, and then having to ask the only question that matters when an app you built launches into silence.

Why doesn’t anyone open this?

The answer is almost never “the code isn’t good enough.” It is almost always one of three things. Over the years I have given each of them a name, because naming a pattern is how you stop falling into it.

1. Be a bucket of water to someone on fire

The first and most under-appreciated test of an app is the urgency of the problem it solves.

Most apps that fail to get used fail because they are  nice-to-have. The problem they address is real but small, or real but slow, or real but easily worked around with a notes app and a bit of friction. The founder feels the problem strongly because they have lived it for two years. The user has never thought about it.

The apps that get used solve problems that are on fire. Right now. Today. With a cost the user can feel.

When someone is on fire, they don’t browse the App Store comparing buckets. They grab the nearest bucket of water and use it. Friction doesn’t matter. Polish doesn’t matter. Branding doesn’t matter. The thing that matters is relief.

This is the test I run on every brief that lands on my desk now:

• What does the user do today, without this app, when this problem hits them?
• How painful is that workaround?
• On a scale from “minor annoyance” to “drop everything and fix this now,” where does the pain sit?

If the honest answer is anywhere south of “drop everything,” the project has a marketing problem long before it has a software problem. No amount of polish will rescue a nice-to-have. You are not selling software. You are selling relief. If there is no fire, there is no demand for buckets.

The corollary is more useful than it sounds: the strongest founder briefs I have ever taken on are the ones where the founder couldn’t sleep until they built the thing. Not because they’re founders. Because the fire was real enough that they noticed it themselves.

2. Think like a pitcher plant

So you’ve found a fire. The user has downloaded the app. Now the harder problem starts: keeping them.

I borrow the model for this from biology. A pitcher plant is a carnivorous plant that catches insects without ever moving. It does three things, in this order:

1. Irresistible lure. Bright colours, sweet nectar, a smell the insect can’t resist.
2. Frictionless slippery slope. The rim is waxy. Once the insect steps onto it, gravity does the rest.
3. Impossible to leave. The interior is lined with downward-pointing hairs. Climbing out is harder than the climb in.

If your app is doing its job, your onboarding should be the lure, your first-use experience should be the slippery slope, and your retention loops should be the inescapable interior.

The lure

The lure is what gets the user from “I tapped the icon” to “I see something I want.” Most apps get this wrong by front-loading account creation, permissions requests, onboarding tours, and “let us tell you about all our features.” A user who downloaded out of curiosity has burned about thirty seconds of patience before they swipe away. If you spend that thirty seconds asking them to verify their email, you have lost. The lure is not your splash screen. It is the user’s first encounter with something they didn’t expect would be that easy.

The slippery slope

The slippery slope is the path from first taste to first real value. The smoother this slope, the harder it is for the user to bail before the product has done its job. Every form field, every confused tap, every moment where the user has to think about what to do next is friction that pulls them back up the slope. The best onboarding flows I have built feel less like flows and more like the app doing the work for the user. They drop in. They are caught.

The interior

The interior is retention. This is where most products that nail onboarding still die a quiet death three weeks in. Pitcher plants don’t just trap insects, they make leaving harder than staying. In software terms: notifications timed to real-world signals, social hooks that compound (other people are here, doing things, talking to you), data the user has accumulated that they would lose by switching, habits that form because the app shows up at the moment the habit fires. None of this is manipulation. It is the difference between a product that becomes part of the user’s life and one that sits on the third page of the home screen until they uninstall it on a phone-cleanout Sunday.

Onboarding is the lure. Frictionless first-use is the slope. Retention loops are the interior. A product with one of the three doesn’t survive. A product with all three is sticky in a way that has almost nothing to do with how its code is written.

3. The MVP is dead. Long live the MLP.

Here is the part that most surprises the founders I work with.

The Minimum Viable Product, as the lean-startup canon defined it fifteen years ago, is dead. It was a brilliant idea in 2010. It does not work in 2026.

The reason has nothing to do with the framework being wrong. It has everything to do with what users now expect.

In 2010, the iPhone was three years old. The benchmark for app polish was set by what was technically achievable with the tools of the day, and “minimum viable” meant something rough enough to ship and learn from. Users were forgiving because the alternative was nothing.

In 2026, your user opens TikTok forty times a day. They use Duolingo on their commute. They have been swimming in apps built by teams of hundreds with budgets in the hundreds of millions, all of which work flawlessly, all of which are tuned to the millisecond. Then they download your MVP, hit a janky transition or an unclear button label or a flow that takes two extra taps, and they delete it. They are not being unreasonable. They are calibrated.

The new baseline is what I call the Minimum Lovable Product.

An MLP is not “MVP with more features.” It is structurally different. An MVP says: the smallest thing we can ship to learn. An MLP says: the smallest thing we can ship that someone falls in love with.

The shift sounds subtle. The implications are not.

Most MVPs fail because they try to do eight things at sixty percent quality. An MLP does three things at ninety-five percent. Every product I have ever shipped that got real traction was a more disciplined cut of its original scope, executed to a higher standard, than its founder originally wanted. Every product I have ever shipped that did not get traction had a scope I should have argued harder against.

The polish in an MLP is not everywhere. That would be unaffordable and unnecessary. The polish is strategically placed. It sits at the exact touchpoints where the user makes a snap judgement about whether this is a real product or another weekend AI prototype. Those touchpoints are not where most builders think they are. They are:

• The first three seconds after the app opens.
• The moment the user does the thing the app is fundamentally for.
• The empty state they see when they haven’t given the app any data yet.
• The error message they hit when something goes wrong.
• The notification that pulls them back.

Five touchpoints. Get them right and the app feels like it was made by people who care. Get them wrong and it feels like a prototype, regardless of how feature-complete it is.

The MLP discipline is harder than the MVP discipline, because it requires saying no to features the founder loves and yes to invisible craft on features that already work. AI tools, ironically, have made this harder, not easier. They make it cheap to add the eighth and ninth and tenth feature. They make it expensive to throw seven of them away.

What AI can’t do (yet)

A specific point about AI, because it is the elephant in the room when anyone writes about software in 2026.

AI can do a lot of what I just described. It can write the code. It can suggest the layout. It can stub the onboarding flow. It can generate the copy on the empty state. It can even, increasingly, build a passable first prototype from a paragraph of plain English.

What AI cannot do, today and likely for some time, is the work that sits underneath all three frameworks above:

• It cannot tell you whether your user is actually on fire, or whether they’re politely interested.
• It cannot feel the difference between a smooth slope and a friction-filled one.
• It cannot judge where the five touchpoints are for your product, with your users, in your market.

That work is human. It is product judgement, user psychology, and strategic taste. It is the part of building software that AI commodifies the inputs to but does not commodify the output of. It is also the part that decides whether your app has users or has nothing. We’ve written before about the engineering layer around the code in Working Code Isn’t Production-Ready Code; this is the product layer above it. Both matter. AI replaces neither.

This is the gap I think Sayan was pointing at in his tweet. Everyone is going to have their own app. Almost nobody is going to have users. The reason isn’t that the apps are buggy. It is that the apps are competently built solutions to problems that aren’t on fire, with onboarding that doesn’t slope, and feature lists eight items long executed at sixty percent each.

The art of it

I called this piece Building an App People Actually Use is an Art, and I meant it.

Building an app, in the technical sense, is no longer an art. It is closer to assembly. The tools have caught up to the task. Anyone with a paid AI subscription and a weekend can produce something that compiles and looks plausible.

What is still an art, and is now scarcer than the code itself, is the upstream judgement that decides whether the thing being built is worth building. Whether the problem is hot enough. Whether the path in is slippery enough. Whether the interior is sticky enough. Whether the three things you chose to do are the right three. Whether the five touchpoints are polished to the level the user has been conditioned to expect.

The frameworks above are the closest I have come to writing down how I do that work. They are not algorithms. They are mental models I run a brief through, before I write a line of code or quote a single hour. Most projects fail one of the three tests on the first pass. The good ones, the ones I take on and that ship into actual users, pass all three before the first sprint starts.

If you are about to ship an app, run yours through the three tests. If you are halfway through building one and the usage numbers are looking quiet, run it through the three tests. If the answers are not what you hoped, the fix is upstream of the code, almost every time.

Building an app is easy. Building an app people actually use is an art. It is also, by happy accident, where almost all the value is.