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

After designing mobile apps that made everyone miserable, I figured out which clients are worth the headache.

Some 10 years ago, I'd take any UX/UI design project that walked through the door. Mobile apps, SaaS dashboards crammed into phone screens, e-commerce apps with seventeen-step checkout flows, productivity tools that required a PhD to understand.

I was hungry for mobile UI UX design services work, optimistic, and completely clueless about what it makes to succeed or fail spectacularly.

The breaking point came with a fintech trading app. Six months of work. Beautiful design. Stakeholders loved it. Users hated it. App Store rating: 2.8 stars. Pulled after three months.

That project taught me mobile isn't just desktop with smaller buttons. It's a completely different context requiring different thinking.

Now I'm brutally selective about mobile work. Some might say unreasonably picky, but after watching that trading app crash and burn, I've earned the right to filter hard.

Here's the disaster that changed everything, the red flags I now spot in discovery calls, and why saying no to most mobile projects was the best business decision I ever made.

Three years ago, a 40-person fintech startup hired me for mobile UI UX design services on their trading platform. Series A funded. Growing fast. Ambitious product vision.

They wanted a mobile app for their desktop trading platform: real-time market data, interactive charts, portfolio analytics, news feeds, trading tools. Everything their power users loved about the desktop version, now pocket-sized.

"Make it simple," they said. "Like Robinhood, but with professional features."

Translation: make it look easy while doing impossible things. Bloomberg terminal in a greeting card.

Red flag parade, but the money was good and I was still naive enough to think good design could solve any problem.

Six months later:

We'd designed an interface that displayed real-time market data across four asset classes, interactive charts with 12 technical indicators, portfolio analytics with drill-down capabilities, news feeds filtered by relevance, and one-tap trading with confirmation flows.

It looked clean. Modern. Overwhelming.

The stakeholders loved it. "Finally, all our features in one place!"

Beta users (500 traders) hated it:

"Too much information"
"Can't find anything quickly"
"Easier to just use desktop"
"Why does checking my portfolio take 8 taps?"
"Charts are impossible to read on my commute"

App Store rating: 2.8 stars. The review that stuck with me: "This feels like someone shrunk their desktop and called it mobile design."

We'd designed for the stakeholders who paid the bills, not the humans who'd actually use it in subway cars and coffee shop lines.

The app got pulled three months post-launch. Not before consuming nine months of my life (six months design, three months watching it die slowly) and nearly destroying my faith that mobile could work for anything complex.

What actually failed:

The chart interface required pinch-zoom and precise taps to change timeframes. Unusable one-handed while standing on a train.

The portfolio screen showed 14 data points per holding. Users just wanted to know if they were up or down today.

The navigation had five tabs with nested menus. Finding the logout button required three taps and a prayer.

We'd preserved desktop complexity instead of reimagining for mobile context. I'd failed at the most basic UX design principle: design for how people actually use the thing, not how stakeholders wish they would.

That failure taught me something crucial about mobile UI UX design services: mobile isn't about cramming desktop functionality into smaller screens. It's about understanding when and where people actually use phones.

Mobile usage happens in:

Fragments of attention (waiting, commuting, multitasking)
Suboptimal conditions (bright sunlight, noisy environments, one-handed use)
Urgent situations (need information quickly, complete task fast)
Casual moments (browsing, killing time, light exploration)

Desktop usage happens with:

Focused attention (dedicated work time)
Optimal conditions (good lighting, stable environment, both hands free)
Complex tasks (detailed analysis, lengthy forms, multi-step workflows)
Deliberate sessions (planned activities, research, creation)

The fintech app failed because we designed for desktop context on mobile devices. Users wanted quick portfolio checks and simple trades. We gave them comprehensive analysis tools that required sustained focus.

Wrong tool for the job, like trying to use a chainsaw for bonsai pruning.

This is what separates good product design from beautiful failure: understanding context determines everything else.

After that disaster, I can predict mobile project failure in the first client call. Here are the phrases that make me politely decline:

"We want it to work exactly like the web version."

Translation: They think mobile is responsive design with an app wrapper. They don't understand people use phones differently than computers.

You'll spend months explaining why their 47-field form doesn't work on a 4-inch screen, the same way I spent months explaining why real-time chart analysis doesn't work on subway commutes. These are the hidden costs of design projects nobody mentions upfront.

"Can we fit all our features above the fold?"

There is no fold on mobile. There's a thumb-sized viewport and infinite scroll.

But they want their entire value proposition visible without any user interaction, like that fintech client who wanted portfolio overview, trading tools, news feed, and charts all visible simultaneously on a 5-inch screen.

"Our users are different — they love complex interfaces."

No. Nobody loves complex interfaces on mobile. Your enterprise users aren't superhuman. They're just trapped by your existing system.

The fintech traders weren't asking for more complexity. They wanted to check portfolio performance and execute trades without switching to desktop. We gave them a mobile Bloomberg terminal instead.

"We need it to look exactly like [successful app] but for our industry."

This is like saying "make me a car that looks like a Ferrari but works like a submarine." Different contexts require different solutions.

The fintech client wanted "Robinhood for professional traders." Those are contradictory design goals. Robinhood works because it strips away complexity. Professional trading requires complexity. You can't have both on mobile.

After the fintech disaster, I developed strict criteria for mobile UI UX design services projects. I only work with clients who understand:

Mobile means single clear purpose.

The app does one thing really well, not seventeen things adequately. The fintech app tried to do everything their desktop did. It should have focused on portfolio monitoring and simple trades only.

The best mobile apps I've designed since: an expense tracker, a meditation timer, a food delivery interface. Each does one thing. Each works.

Mobile requires accepting trade-offs.

Fitting everything on screen means nothing works well. You have to prioritize ruthlessly and hide complexity behind progressive disclosure.

The fintech client wanted zero trade-offs. "Our users need access to everything." What users actually needed: quick answers to "am I up or down?" and "buy/sell this holding." Everything else was desktop work.

Mobile excels at specific strengths:

Immediate access to information
Location-aware functionality
Camera and sensor integration
Quick, focused task completion
Habit-forming routine integration

Everything else probably belongs on desktop, reimagined entirely, or accessed as SaaS product design via web instead of forced into native app.

I only work with mobile UI UX design services clients who:

Can describe their core user scenario in detail.

Not demographics. The specific situation where someone uses their app. "Between meetings checking if proposal was approved" or "while cooking dinner looking up ingredient substitutions."

The fintech client couldn't do this. They said "professional traders need mobile access." But they couldn't describe when/where/why someone would choose mobile over desktop for trading. Because the answer was: almost never for complex analysis.

Have strong opinions about what to exclude.

They know their app won't do everything. They've made deliberate choices about scope.

The fintech client wanted to exclude nothing. Every desktop feature had to exist on mobile. This is how you end up with everything and nothing working.

Think in user journeys, not feature lists.

They care about what someone accomplishes, not what buttons they can access.

Good mobile clients say: "Users need to submit expense reports in under 2 minutes." Bad mobile clients say: "Users need access to expense categories, receipt capture, approval workflows, reimbursement tracking, and historical reports."

Same outcome, different focus. One leads to focused design. The other leads to fintech trading app disasters.

Trust the design process.

They won't demand to see their entire feature list above the fold. They understand good mobile UX often means showing less, not more.

The fintech stakeholders never trusted this. Every design review: "Where's the options chain?" "Where's the Level 2 data?" All desktop features that had no business on mobile. But they paid the bills, so we included everything.

When you hire a designer, either trust their expertise or hire someone who'll build what you ask for regardless of whether it works.

Enterprise dashboards.

Complex data visualization belongs on larger screens with mouse precision. Mobile dashboards usually become unusable compromise interfaces that satisfy nobody.

The fintech portfolio screen was this disaster. Twelve data points per holding, color-coded performance indicators, sparkline charts, percentage changes. Impressive on desktop. Incomprehensible on mobile.

Multi-step productivity tools.

If your workflow requires more than three focused steps, it probably shouldn't be mobile-first. Mobile excels at quick captures and simple completions, not complex processes.

The fintech trading flow: select asset class → search holding → view chart → analyze data → check portfolio impact → execute trade → confirm → check execution. Eight steps requiring focus. Wrong device entirely.

"Everything apps."

Swiss Army knife applications that try to replace multiple tools. They sound impressive in pitches but create decision paralysis for users.

The fintech app was this. Trading, portfolio monitoring, research, news, alerts, education. Six apps wearing a trench coat. None worked well because we couldn't focus.

All-in-one products fail for the same reason: trying to serve everyone serves nobody well.

Exact mobile replicas of existing systems.

If you want desktop software in app form, you don't want mobile design — you want miniaturization. Different services, like the difference between architecture and dollhouse construction.

The fintech project was exactly this mistake. We miniaturized when we should have reimagined.

These phrases make me politely end mobile UI UX design services conversations now:

"Our power users need access to everything."

Power users on mobile are usually people trapped by circumstance, not choice. They'll use a better tool the moment it's available.

The fintech "power users" checking portfolios on mobile weren't demanding complex analysis tools. They were checking simple numbers while away from desk. We built for imaginary power users instead of actual casual checkers.

"We want to disrupt the industry with mobile-first thinking."

Usually means they want conventional features in an app wrapper. Real disruption rarely announces itself this way.

"The app should work for both casual users and professionals."

This is like designing a vehicle for both city commuting and mountain climbing. Different contexts need different solutions.

The fintech app tried this. Casual investors got overwhelmed. Professional traders found it inadequate. Neither group was happy.

"We have existing users who love our web interface."

Those users probably hate your mobile experience but tolerate it because they have no choice. Starting with different assumptions might serve them better.

My mobile UI UX design services work improved dramatically when I started saying no to impossible projects:

Better outcomes.

The apps I design now actually get used. Higher engagement, better reviews, fewer support tickets about "confusing interface."

Since the fintech disaster, I've designed three mobile apps: expense tracking, appointment scheduling, delivery tracking. All focused. All 4+ star ratings. All actually used.

Happier clients.

Projects finish closer to timeline and budget because we're not fighting fundamental mobile constraints. No more months-long debates about whether data tables belong on mobile (they don't). When design partners and clients align on goals, projects actually finish.

Less stress.

No more explaining why seventeen-step workflows don't work on phones. No more design reviews that become existential crises about feature parity.

Clearer expertise.

Focusing on mobile-appropriate projects made me better at actual mobile challenges: thumb navigation, attention fragmentation, context switching. Not fighting over desktop feature replication.

The clients worth working with understand:

They can describe their core scenario specifically.

Not "users need portfolio management" but "users standing in grocery store line want to know if they're up or down today before deciding whether to splurge on nice cheese."

That level of specificity reveals real mobile use cases versus desktop fantasies.

They have strong opinions about what to exclude.

They know their app won't do everything. They've made deliberate choices.

The best mobile client I've worked with since fintech: "The app only tracks mileage. Nothing else. Users can export to their accounting software for everything else." Clear scope. Focused purpose. Actually worked.

They think about habit formation.

They understand mobile apps succeed by becoming part of daily routines, not by offering occasional utility.

They measure mobile-appropriate metrics.

Time-to-completion. Return usage. Specific task success rates. Not page views or session duration.

The fintech client measured feature adoption. "Only 12% of users access advanced charting!" Because advanced charting on mobile while standing on a train is impossible. Measuring wrong things.

Here's what I tell potential mobile UI UX design services clients on discovery calls now:

Mobile users are not patient. Not forgiving. Not going to watch tutorials, read documentation, or give you the benefit of the doubt.

They want to open your app, accomplish something specific, and get back to their lives. They're not looking for a digital relationship — they want a tool that works without an instruction manual.

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 fintech app required explanation. We created tutorial videos. In-app tooltips. Email onboarding sequences. All evidence we'd failed at basic mobile UI UX design services principle: if it needs explanation, it's too complex.

This isn't a limitation — it's a design constraint that forces clarity and purposefulness. The best mobile experiences emerge when you embrace these constraints instead of fighting them.

The mobile UI UX design services industry is full of projects that shouldn't exist. Desktop software forced into app containers. Web interfaces wrapped in native frameworks. Complex business processes miniaturized for touchscreens.

These projects consistently fail, frustrate users, and waste everyone's time. But they keep getting commissioned because stakeholders confuse "mobile presence" with mobile-appropriate design.

Great design services diagnose the real problem before proposing solutions. Sometimes the diagnosis is: "You don't actually need a mobile app."

The mobile UI UX design services that matter focus on what mobile does uniquely well:

Immediate access to information
Location-aware functionality
Camera and sensor integration
Quick, focused task completion
Habit-forming routine integration

Everything else probably belongs on desktop, web, or reimagined entirely.

Working with the right mobile clients feels completely different from the fintech disaster.

Instead of explaining why their requests won't work, you're collaborating on solutions that leverage mobile strengths.

Instead of designing compromises that satisfy nobody, you're creating focused tools that people actually want to use.

Instead of fighting device constraints, you're using them to create clarity and purpose.

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 ones who understand mobile UI UX design services mean reimagining, not shrinking.

The others can find someone else to design their mobile Bloomberg terminals. I'm busy making apps that people actually open twice.

The fintech app taught me the most expensive lesson of my career: some projects shouldn't be mobile apps at all. The courage to say that upfront saves everyone months of suffering and disappointment.

Now I say it early. Often on the discovery call. Before anyone gets hurt.

It's not pickiness. It's pattern recognition from expensive experience.