mailwal

Desktop Apps Aren't Dead. Pick Your Tradeoffs

Dev Leader

TL; DR:

Are Desktop Applications Obsolete?

Hey folks!

I came across a question on the ExperiencedDevs subreddit about software moving from desktop applications toward web apps. Why does that happen? And aren’t we losing something if the software no longer lives on our computers?

I think those are fair questions. But I don’t think desktop is dead, and I don’t think web automatically wins.

I’ve been programming for more than 20 years. More than half of my programming career has been in desktop development. So this isn’t coming from someone who has only ever built things for a browser.

My perspective is that web apps can open up opportunities for a product. Desktop apps still make sense when their capabilities fit what you’re building. The interesting part is figuring out which tradeoffs you’re actually willing to make.

You can check out my full thoughts on this in the video below:

Cross-Platform Doesn’t Make The Cost Disappear

Let’s say you’re building an app for Windows customers.

If Windows is the only platform you need, building specifically for it might be a perfectly reasonable choice. But what happens when you also want Mac and Linux users?

You have options. You could build separate native interfaces and share the parts of the application that don’t depend on the platform. You could use a cross-platform framework. Or you could ask whether the product belongs in a browser.

None of those options makes the engineering work disappear.

With separate native interfaces, you have more platform-specific work to maintain. With a cross-platform framework, I would want to examine how much complexity moves into the framework and how the experience feels on each platform.

Maybe the interface doesn’t feel completely native. Maybe it does, but your team has more work to get it there. I’m not saying that makes cross-platform a bad choice. I’m saying you need to look for where you’re paying the cost.

The browser has its own version of this tradeoff. Reaching users through a URL can be attractive, but “it opens on a phone” and “it’s a good product on a phone” are not the same thing.

You still need to consider layout, interaction, and the devices your customers actually use. Mobile isn’t free just because the page loads.

Start With What The Product Must Do

What if your app needs frequent access to local files? What if it interacts with other things on the computer? What if a very specific native experience is part of what customers are buying?

Those are more useful questions than asking which platform is winning.

And I want to be careful here: the browser isn’t simply incapable of working with local files. The File System Access API can read and save files after the user grants access. But browser support, permissions, and the exact workflow still matter. That is not the same as assuming every browser can provide every desktop interaction you need.

For a product where those boundaries keep getting in the way, I would seriously consider desktop. For a product where they aren’t important and reaching people on different platforms is valuable, I would explore web.

What about performance?

I wouldn’t choose based on a blanket statement that native is always faster or that browsers are now fast enough for everything. I would identify the interaction that matters, build a representative slice, and measure it on the devices we need to support.

Actionable Tip

Before choosing your stack, write down:

  • Which platforms your customers actually need.

  • What must work without a network connection.

  • Which local files, devices, or system integrations matter.

  • What “fast enough” means for the important workflow.

  • Who will maintain the application after the demo works.

Then compare the options against that list. Not against your favorite framework’s homepage.

Dev Leader Weekly is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.

Your Team Is Part Of The Decision

Historically, team familiarity has been a big factor for me.

If you have developers who are very effective in a particular stack, and no strong requirement pushing you away from it, leaning into that experience can help you get the product out the door.

A theoretically better technology doesn’t help much if you can’t ship.

I think AI can change some of that calculation. It may make an unfamiliar stack more approachable. That is part of why I’ve been talking about how AI changes the reasons we choose programming languages.

But “I can generate this” isn’t the same as “we can support this.”

You still need to evaluate the output and understand the important boundaries. Owning the quality of AI-written code doesn’t stop being your responsibility because the stack is new to you.

If your first attempt misses a requirement, use that to improve the process. Fixing the feedback loop is more useful than repeatedly asking for a better result without explaining what better means.

Installed, Offline, And Owned Are Different Questions

The original question also brought up ownership. Maybe people feel better about buying software if they have a copy installed on their computer.

I can understand that preference. It’s just not a requirement I personally have for every product.

For example, I pay for Office outside of work, and I mostly use the web apps. I work at Microsoft, but this is my perspective as a paying customer, not a statement on Microsoft’s behalf. Whether Office is installed on my computer isn’t what makes that purchase valuable to me.

Would I prefer a one-time purchase over a subscription? Sure. But that’s a different question from whether I need a desktop application.

And offline access is another question again.

Imagine you have a document on your computer, but the application you need to open it requires an internet connection. If the network is down, being unable to view your own local file would feel pretty bad.

That’s a hypothetical workflow, not a claim that every Office application behaves that way.

The same concern comes up for me with single-player games that require an online connection. It feels weird even when it isn’t frequently stopping me from playing.

But web doesn’t automatically mean online-only, either. Progressive Web Apps can store data locally to support offline work. You have to deliberately build and test that experience. A product that depends on a remote service still needs a plan for what happens when that service is unavailable.

So ask the customer what they mean by ownership. Is it a one-time payment? Access to their data? Being able to keep working offline? Those answers can point you toward different product decisions.

Dev Leader Weekly is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.

Lock-In Is Not Loyalty

Another part of the question was whether a desktop app makes it harder for users to switch away.

Maybe. But I don’t think making it difficult to leave is the same as earning loyalty.

I would rather have people stay because the product does something valuable for them. Creating barriers can also give someone a reason not to buy in the first place.

From the business side, I can see why a subscription model might be attractive. You can think about retention, expanding usage, and offering more value to existing customers.

That doesn’t prove a subscription is the right model for your product. And it doesn’t prove web apps are more profitable. I’m describing why I think a business might explore that direction, not presenting market research.

The implementation and the pricing model deserve separate decisions. Don’t let “we want subscriptions” quietly turn into “therefore our users don’t need offline access.”

Don’t Rewrite A Working Product To Follow A Trend

If you already have a desktop application, this conversation isn’t automatically a reason to replace it.

What problem would the replacement solve?

If you’re weighing rewriting against refactoring, start with the capability you need rather than assuming a new platform fixes everything.

You might be able to share more of the underlying logic. You might need a new client for a particular audience. Or keeping the current product might be the right answer.

And remember the maintenance side. Managing technical debt is still work in a web app. A different delivery mechanism doesn’t erase the cost of supporting what you’ve built.

Actionable Tip

Pick one important customer workflow. Try the smallest realistic version of it in the alternative you’re considering. Include the awkward parts, not just the happy-path screen.

Can it work offline when required? Can the user access what they need? Does it perform adequately? Can your team maintain it?

Desktop isn’t dead. Web isn’t a universal answer.

I think the opportunity is having more choices. Our job is to understand the product well enough to make one deliberately.

Which requirement has actually pushed your team toward desktop or web? I’d be interested in hearing the tradeoff, not just the technology you picked.

As always, thanks so much for your support! I hope you enjoyed this issue, and I’ll see you next week.

Nick “Dev Leader” Cosentino
[email protected]

Socials:
– Blog
– Dev Leader YouTube
– Follow on LinkedIn
– Dev Leader Instagram

P.S. If you enjoyed this newsletter, consider sharing it with your fellow developers!

© 2026 Nick Cosentino
548 Market Street PMB 72296, San Francisco, CA 94104