Why I Only Design Mobile Apps for One Type of Client Now

Some three-four years ago, I would have designed a mobile app for literally anyone with a budget and a vague idea about "going mobile."

SaaS dashboards that looked like airplane cockpits crammed into phone screens? Absolutely. E-commerce apps with checkout flows so complex they required a flowchart to navigate? Sure thing. "Revolutionary" productivity apps that needed user manuals thicker than phone books? Where do I sign?

I was hungry, optimistic, and completely delusional about what separates mobile projects that change people's lives from ones that make everyone involved question their career choices.

Now I'm so picky about mobile work that I probably sound like a snob. I turn down about 80% of the projects that come my way, and I've never been happier or more successful.

Because here's what I learned the hard way: most mobile app projects shouldn't exist at all.

The Death Sentences Disguised as Project Briefs

I can smell disaster within minutes of a discovery call now. It's become this weird, depressing superpower.

"We want it to work exactly like our web version, but mobile." This is like saying "I want a boat that drives like a car." These clients fundamentally misunderstand that mobile isn't just desktop with smaller buttons. They think mobile users are just desktop users holding smaller screens.

"We need everything above the fold so users can see our full value proposition immediately." There is no fold on mobile. There's a viewport the size of a playing card and infinite scroll. They want their entire business model visible without any user interaction, like a highway billboard at 70 mph.

"Our users are different – they actually prefer complex interfaces because they're power users." No. Your enterprise users aren't superhuman productivity machines. They're accountants and project managers who got stuck with your system and learned to tolerate its complexity because switching costs are high.

"Think Uber for [insert industry that has nothing to do with transportation]." They want the elegance of a ruthlessly focused app, combined with all the feature bloat of their existing business model. It's like wanting a sports car with the cargo capacity of a pickup truck.

I used to think I could educate these clients. Now I just politely decline and save us both months of frustration.

The Project That Almost Killed My Love for Design

Two years ago, a fintech startup hired me to design their trading platform app. "Make it like Robinhood," they said, "but with professional features for serious traders."

I should have run. That sentence contains two completely contradictory requirements.

Instead, I spent six months designing what was essentially Bloomberg Terminal on a phone screen. Real-time market data, interactive charts, portfolio analytics, news feeds, trading interfaces for options and futures.

In Figma, it looked incredible. Clean typography, thoughtful color coding, elegant micro-interactions.

In reality, it was like trying to pilot a fighter jet while riding a motorcycle in traffic.

Beta users hated it with a passion I didn't know was possible. "Too overwhelming." "Can't find anything." "Went back to using my laptop for everything."

But the internal stakeholders loved it. "Finally," the CEO said, "all our capabilities in one beautiful interface."

We'd designed for the people paying the bills, not the humans who'd actually use it while commuting or grabbing coffee between meetings.

The app launched to devastating reviews and was pulled from both app stores within six months. Not before consuming most of a year of my life and nearly making me switch to designing restaurant menus instead.

What I Finally Understood About Mobile Context

That disaster taught me that mobile isn't just a platform – it's a completely different relationship between humans and technology.

Desktop usage is intentional. People sit down, open applications, dedicate focused time to specific tasks. They have both hands free, good lighting, stable internet, minimal distractions.

Mobile usage is opportunistic. People pull out phones during micro-moments of availability. Waiting for elevators. Walking between meetings. Standing in lines. They're using one hand while holding coffee, squinting in bright sunlight, being interrupted by notifications.

This isn't a limitation to overcome – it's the entire point. Mobile's strength isn't doing everything desktop can do, but smaller. It's doing specific things that desktop can't do at all.

The Only Type of Client I Work With Now

After that revelation, I developed ruthlessly specific criteria for mobile projects. I only work with clients who:

Know mobile means brutal prioritization. They understand that trying to fit everything on screen means nothing works well. They see constraints as creative opportunities, not obstacles to overcome.

Have one crystal-clear purpose. When I ask what their app does, they can explain it in one sentence without buzzwords. They know exactly what problem they're solving and for whom.

Think in moments, not sessions. They understand their app will be used in 30-second bursts while people are doing other things.

Trust the design process. They won't demand to see every feature prominently displayed on the home screen. They understand that good mobile design often means hiding complexity behind progressive disclosure.

What's Actually Worth Building

The mobile projects that succeed have specific characteristics:

They solve urgent, frequent problems. The best mobile app I ever designed was for a food delivery service. People use it when they're hungry and don't want to cook. The need is immediate, the solution is clear, the interaction is over in two minutes.

They leverage what phones do uniquely well. Camera input instead of typing. GPS awareness instead of address forms. Push notifications for time-sensitive information. They use mobile capabilities as core features, not afterthoughts.

They start embarrassingly simple. New users can accomplish something valuable in their first session without tutorials or learning curves. Advanced functionality exists but doesn't interfere with the basic experience.

They become invisible habits. The apps people keep using solve small problems consistently rather than big problems occasionally.

The Projects I Turn Down Now

Enterprise dashboards.
Complex data visualization belongs on large monitors with mouse precision. Mobile dashboards inevitably become unusable compromise solutions.

Multi-step business processes.
If your workflow requires more than three focused interactions, it probably shouldn't be mobile-first.

"Comprehensive" productivity tools.
Swiss Army knife applications that try to replace five different specialized tools create decision paralysis and feature bloat.

Direct desktop conversions.
If you want your existing software shrunk down to phone size, you don't want mobile design – you want miniaturization.

The Questions That Reveal Everything

I've developed questions for discovery calls that instantly reveal whether a project is worth pursuing:

"Describe the exact moment when someone would use your app. Not just where they are, but what they're doing, how they're feeling, what just happened."

Clients who understand mobile can paint vivid pictures: "They're walking out of a client meeting that ran over, and they need to update their team before they forget the details."

Clients who don't give vague answers: "They'd use it whenever they need to access our platform."

"What will people accomplish in their first thirty seconds?"

Good answers are specific: "They'll see if their package arrived and where it is if it didn't."

Bad answers are generic: "They'll understand our value proposition and explore the features."

What Changed When I Got Ruthlessly Selective

My mobile work transformed when I started saying no to impossible projects:

The apps I design now actually improve people's lives. Users leave reviews like "This saves me 20 minutes every day" instead of "Confusing and slow."

Projects finish on time and under budget. When everyone agrees on what success looks like, there are fewer surprise requirements and scope creep discussions.

I sleep better. I'm not lying awake wondering if the thing I'm building will make someone's day slightly worse.

My expertise deepened. Focusing on mobile-appropriate challenges made me better at solving mobile-specific problems: thumb navigation patterns, attention management, progressive disclosure.

Why Most Mobile Projects Are Doomed

The mobile app ecosystem is cluttered with projects that were dead on arrival:

They solve desktop problems with mobile constraints. Complex data analysis, elaborate workflow management – these problems exist, but mobile isn't the right solution.

They prioritize feature parity over user experience. They measure success by how much functionality they can cram in, not by how effectively users accomplish their goals.

They design for edge cases instead of core use cases. They spend months perfecting features that 5% of users might need while making the basic experience worse for everyone.

What I Tell Potential Clients Now

"Mobile users aren't patient. They're not forgiving. They're not going to watch tutorials, read documentation, or give your app multiple chances to make sense. They want to accomplish something specific and get back to their lives."

"If your app requires explanation, training, or multiple attempts to understand, it's not a mobile app – it's desktop software that happens to run on phones."

"The best mobile experiences don't feel like using software. They feel like having a superpower for thirty seconds."

This scares away clients who want comprehensive business platforms. It attracts clients who want to solve specific problems elegantly.

The Work That Energizes Me Now

When I work with the right clients, everything changes:

Instead of explaining why their requests won't work, I'm collaborating on solutions that leverage what mobile does uniquely well.

Instead of designing compromises that satisfy nobody, I'm creating focused tools that people genuinely love using.

Instead of fighting device constraints, I'm using them to eliminate unnecessary complexity and create clarity.

That's why I only work with one type of mobile client now: the ones who want to build something that belongs on mobile, not something that merely fits.

The others can find someone else to design their digital Swiss Army knives.

I'm busy making apps that people actually want to open more than once. Apps that solve real problems in real moments. Apps that make life slightly easier instead of slightly more complicated.

That's the only mobile work worth doing.