Allen Pike

Why is ChatGPT for Mac So Good?

2025-11-30T23:45:30+00:00

This year, even as Anthropic, Google, and others have challenged OpenAI’s model performance crown, ChatGPT’s lead as an end-user product has only solidified. On the Dithering podcast last week (paywalled), Ben Thompson called out an aspect of why this is:

I need someone to write the definitive article on why the ChatGPT Mac app is so good, and why everyone else is in dereliction of duty in doing these.

Gemini 3 is reportedly coming this week. […] And I’m looking forward to it. I expect it to be good. And it’s just going to have to be so astronomically good for me to not use ChatGPT, precisely because the [Mac] app is so useful.

A model is only as useful as its applications. As AI becomes multimodal and gets better at using tools, these interfaces are getting even more important – to the point that models’ apps now matter more than benchmarks. And while every major LLM has a mobile app, only three have a Mac app: Copilot, Claude, and ChatGPT.

And of those, only one is truly good.

Hold on – we’re diving in.

The Apps

ChatGPT for Mac is a nice app. It’s well-maintained, stable, performant, and pleasant to use. Over the last year and a half, OpenAI has brought most new ChatGPT features to the Mac app on day one, and even launched new capabilities exclusively for Mac, like Work with Apps.

The app does a good job of following the platform conventions on Mac. That means buttons, text fields, and menus behave as they do in other Mac apps. While ChatGPT is imperfect on both Mac and web, both platforms have the finish you would expect from a daily-use tool.

ChatGPT for Mac (left) vs. ChatGPT on the web (right).

Meanwhile, the Mac apps for Claude and Microsoft’s “365 Copilot” are simply websites residing in an app’s shell, like a digital hermit crab. 365 Copilot is effectively a build of the Edge browser that only loads m365.cloud.microsoft, while Claude loads their web UI using the ubiquitous Electron framework.

Claude.app: a website with window controls.

While the Claude web app works pretty well, it only takes a few minutes of clicking around Claude for Mac to find various app-specific UI bugs and bits of missing polish.

As just one example: Mac apps can typically be moved by dragging the top corner of the window. Claude supports this too, but not when you have a chat open?

Your viewer doesn't support HTML5 video, but you [can see the video here](/images/2025/claude-drag-high.mp4). A classic case of `-webkit-app-region: no-drag` over-application.

Unsurprisingly, the Microsoft 365 Copilot app is even worse, and Gemini doesn’t have a Mac app at all. The desktop has not been a focus for the major AI labs thus far.

The oddball here is the plain “Copilot” app, which is of course unrelated to the “365 Copilot” app other than sharing an icon, corporate parent, and name. Copilot for Mac is, it seems, a pared-down native Mac reproduction of the ChatGPT app with a bit of Microsoft UI flavor. It’s actually weirdly nice, although it’s missing enough features that it feels clearly behind ChatGPT and Claude.

Fascinatingly, the Copilot app doesn’t allow you to sign in with a work account. For work – the main purpose of a desktop app – you must use the janky 365 Copilot web app. While this dichotomy might be confusing, it’s a perfect illustration of the longstanding tension that’s made cross-platform the norm for business apps.

The Strategies

Cross-platform apps like Claude’s are, of course, cheaper to develop than native ones like OpenAI’s. But cost isn’t the most important tradeoff when these very well-capitalized companies decide whether to make their apps cross-platform. The biggest tradeoff is between polished UX and coordinated featurefulness.

ChatGPT has focused more on the vertical axis, Claude more on the horizontal.

It’s easier to get a polished app with native APIs, but at a certain scale separate apps make it hard to rapidly iterate a complex enterprise product while keeping it in sync on each platform, while also meeting your service and customer obligations. So for a consumer-facing app like ChatGPT or the no-modifier Copilot, it’s easier to go native. For companies that are, at their core, selling to enterprises, you get Electron apps.

This is not as bad as it sounds, because despite popular sentiment, Electron apps can be good apps. Sure, by default they’re janky web app shells. But with great care and attention and diligence and craft, they can be polished almost as well as native apps.

While they might not feel native, Electron apps like Superhuman, Figma, Cursor, and Linear are delightful¹. These apps are tools for work, and their teams invest in fixing rough edges, UI glitches, and squirrelly behaviour that might break users’ flow.

Meanwhile, ChatGPT, despite being built on native tech, has its share of problems. These range from the small (the Personalization settings pane currently has two back-arrows instead of one) to the hilarious.

View this post on Instagram

A post shared by Allen Pike (@allenjpike)

At the end of the day, the ChatGPT app for Mac is good because they care. They have a product-led growth model that justifies spending the resources, an organizational priority on user experience, and a team that can execute on that mission.

Meanwhile, Anthropic’s been going hard on enterprise sales, so it’s not shocking they’ve neglected their desktop experience. It’s unlikely they have a big team of developers on the app who don’t care about these issues – they probably haven’t had many folks working on it at all.

Still, I wouldn’t count out the possibility of a change in course here. While mobile is king, desktop is still where work happens. While OpenAI has acquired Sky to double down on desktop, Google has long been all-in on the browser. That leaves Anthropic as the challenger on desktop, with their latest models begging to be paired with well-crafted apps.

While Anthropic could surprise everybody by dropping a native Mac app, I would bet against that. There’s a lot of headroom available to them just by investing in doing Electron well, mixing in bits of native code where needed, and hill-climbing from “website in shell” to “great app that happens to use web technology”.

Just as ChatGPT’s unexpected success woke OpenAI to the opportunities of being more product-centric, the breakout hit of Claude Code might warm Anthropic to the importance of investing in delightful tools. Last year they brought on Mike Krieger as CPO, who certainly seems like he could rally a team in this direction given the chance.

Until then, ChatGPT will reign supreme.

We’ve done some Electron work at Forestwalk, and it was surprising how easy it was to cause classic Electron bugs like the whole app being a white square, the top navigation scrolling out of view, and the like. It was even more surprising how tractable it is to just refuse to tolerate these common issues, and put in the time to fix them one by one. It can be done. ↩

How to Not Get Acquired

2025-10-31T23:45:30+00:00

Building something new from 0 → 1 is hard, so it requires your full attention. Given that, a key part of creating a new product is limiting distractions – anything that pulls your attention away from finding product-market fit. There are a lot of things a founder can be distracted by, but one of the most distractive distractions has become more common in recent months: the acquisition inquiry.

Here are some tips on how to avoid these¹.

Trade offer

A year into my first startup, we got our first legit inquiry about an acquisition.² This was very exciting! It feels validating to be wanted by somebody you respect, a company you find interesting.

Back then, I sat down with my then co-founder and worked through a huge new question: Did we want to give up our mission, relocate to the Bay Area, and join a FAANG company?

This is the kind of question that consumes not only work hours, but in-between hours. At lunch, we talked about the acquisition idea. When I talked to my wife, we would discuss it. When I was lying in bed or taking a shower or walking around, instead of thinking about how to build a great product and team, I was instead thinking about building products for this whole other company.³

In time, we came to a conclusion: we didn’t want to stop, and we didn’t want to move, but the prospective company and mission were compelling enough that there was indeed an amount of money we’d be willing to do the deal for.

With trepidation, we met for the follow-up call with the Big Deal Company. We heard out their much-anticipated offer, which was, basically, to just offer us jobs. If we gave up on Steamclock, we could become IC developers at their company, at the normal salaries we would make if we’d applied to work there with our dang resumes, and a typical signing bonus.

We politely declined, then sat back to reflect on what had just happened. We’d been distracted for weeks by an opportunity that never was. Or, maybe more accurately, an opportunity we already knew was there (get hired at a big company) but had been repackaged as something that initially sounded novel.

This experience, and others, have led me to simply decline most such inquiries since.

Still, though, every year or two an inquiry will be interesting enough that I can’t just say no. On occasion, the email about “discussing opportunities to work together” is not automated outreach, but a thoughtful question from a founder or leader I am deeply curious to learn more from, at a company I find intriguing. When the problem they’re tackling is fundamentally one we’re already obsessed with, just at a far larger scale, I’m gonna want to talk to them!

In these cases – when I can’t bring myself to just politely say no thank you, we’re busy building – I’ve developed a simple approach for responding in a way that maximizes learning yet minimizes distraction: meet them, then advise them against acquiring you.

A simple algorithm

Firstly, when taking these exploration calls it’s worth getting something for your time. While naturally you’ll be sharing about your work, also seek to learn about their business. While I’ve kept these conversations short and sweet, they’ve still enabled me to learn about some fascinating businesses, and even made friends. Every person who considers buying your business is a potential mentor – doubly so in the unlikely case they actually pull the trigger and become your new boss.

If you’re not careful, though, an acquistion inquiry will fractal into a long distracting back-and-forth. Most big companies have professionals whose full-time job is to learn about startups and try to acquire them at competitive prices – affectionately referred to as Corp Dev. The asymmetry here is why the Pocket Guide of Essential YC Advice flatly says “Don’t talk to corp dev.” This is an oversimplification, but the plausibility of any deal will indeed hinge not on the M&A folks, but on a champion – a product leader or founder who wants you on their team.

Your key point of contact for sanity-checking an inquiry is this “exec sponsor” in acquisition jargon. The idea is to talk through, together, the big opportunity or problem on their plate, and why they think buying you might be the best and/or fastest way to pursue it. I’ve had some fascinating conversations with tech execs in this context. Sometimes they haven’t even thought it through and you can easily convince them it doesn’t make sense. Other times they’ve done some really thoughtful analysis, and you learn some useful things about the business and the market.

As much as I enjoy these conversations, it’s still best to be disciplined and limit them until you have a ballpark number in writing. This is because, very likely, the number will be disappointing, and you can get back to work.

Here’s a way to get a number.

Explain that it’s your policy not to have more than one or two calls about an acquisition unless there’s a ballpark number to consider, and agreement on some basic non-negotiables⁴. Explain that you do this because, in your experience, the amounts acquirers can justify don’t generally match up with how much you and your team value the company. (Of course if this isn’t true then don’t lie, though you can say you’ve heard that this is typically the case.)

If they really want you, they’ll give you a number. Optionally you can expedite things by seeding them with an anchor. You could say, “Well, this early we would need to consider anything exceeding $50M but most acquirers can’t justify something like that given our stage” or “Well our valuation at last round was $10M, so we don’t expect to consider any offers until we’ve substantially exceeded that level.” Being transparent might not maximize how much you get if they do acquire you, but it speeds things up, and statistically they’re not gonna acquire you anyway! So you’re instead optimizing for the more important thing: getting back to building with minimal distraction.

When asked for a number, their corp dev person might push to collect a lot more info about your business, or even interview all your team members – basically derailing your startup so they can get more confidence in the number. This disruption is not worth improving the accuracy of a number that you’re probably going to decline anyhow. Instead, have them give a range based on what they do know, then just consider the bottom end of their provided range.

Attempt to decline the offer

If you fail to convince them not to acquire you, you’ll get a number – which (probably) does not meet your “hell yeah” threshold. Then you can thank them for their time, appreciate having had a couple calls where you learned about a scaled tech company and one of their execs, and get back to work.

If the number seems almost good enough to be compelling but you’re not sure, I would encourage you to turn it down. Day 1 is probably the best that number will ever feel. If you agree to it in principle, that begins a process where the acquirer’s full-time staff of expert acquisition analyzers will halt your forward progress by assessing you every way from Sunday, considering ways to negotiate down the number, and lawyering you into submission. If $10M doesn’t sound awesome now, it will sound less awesome when it’s been walked back significantly, divided among your investors and cofounders and team, spread over 4 years, then finally taxed.

Naturally, if you have investors, you are obligated to consider their perspective, which will probably be that they want you to keep building for the long term, and if need be they’d prefer you took the deal with the biggest financial upside. For early-stage deals, though, the non-financial aspects matter too. Once you’ve made enough money to no longer have a mortgage, you’re going to get more happiness from a deal that accelerates you and the awesome team you’ve assembled to put that dent in the universe, rather than a 20% higher offer that would disassemble your people and spread you across the Legacy Settings Screen Maintenance org at IBM. If the offer feels like the latter, get your heads back down.

Get back to building

A lesson I’ve re-learned starting up for a second time is that when you’re trying to do something very difficult, it’s all too easy to find yourself distracted by less-difficult opportunities, even if they’re not the thing that really matters.

Talking to leaders at big companies about the problems on their plate can absolutely support your mission – they often have a wealth of experience, and they could make for great customers, or even someday hires. Just be well aware of the asymmetry. It costs them nothing to ask if you’ve thought about selling, but it can cost you a lot if you don’t have a quick algorithm for getting to, “Sorry – we’ve still got a lot of work to do.”

This post assumes you don’t actually want to sell right now – your company is neither doomed nor succeeding so spectacularly that you’ll get superlative offers. If you do want to sell now, Justin Kan and Daniel Debow have guides on how to go about that. ↩
Now that we’re one year into Forestwalk this has happened as well. Not sure if people keep a timer, or just know not to bother somebody who’s less than 1 year down a 10-year path. ↩
Any time you are in the shower and thinking about a work thing that is not hiring the right people, having enough money, or building the right product, that’s a signal that something is going wrong. ↩
Non-negotiables might include things like no forced relocation, ensuring your investors get treated fairly, the rough mix of cash vs. stock, and so on. These aren’t meant to be contentious, it’s just “FYI we wouldn’t take a deal that doesn’t have these attributes.” ↩

UX Entropy

2025-09-30T23:45:30+00:00

In the olden days, video calls were hard.

Circa 2012, if your next meeting was online, it was important to start the process 5-10 minutes early. The process, at that time, was some or all of the following incantations and rituals:

Find the meeting URL
Find the meeting passcode
Download a specific videoconferencing app
Agree to and accept various things
Dial in separately to get audio
Troubleshoot your audio or video
Wait for an update to download
Wait for the videoconferencing app to restart
Wait for your whole computer to restart
Repeat some of the above steps, now that your computer has restarted

With luck, you would eventually be in the meeting. The other participants, often, would not be. Regrettably, each participant also needed to do the incantations, and they might not have started early. They might even be stuck.

For example, the person you’re meeting might think they’re waiting for you, so they’ve multi-tasked to another app – but surprise! GoToMeeting or WebEx or whatever actually needed them to click “OK” or “Update” or “Ẓ̴͝a̴̡̕l̷̙̓g̶̫̔ó̸̻” to continue the joining process. After 5-10 minutes you would politely email your colleague, asking if they were still joining. Often enough you’d find yourself attempting to help people troubleshoot the above steps via email, which was… not enjoyable.

This was all obviously bad. Any user could see it was bad, but it seemed – oddly – like the companies supporting these apps were kind of blind to it. Or, at least, their enterprise customers weren’t demanding better.

As the story goes, Eric Yuan, then an executive at WebEx, was aware how clunky these product experiences were, and was ashamed of it. He felt that customers deserved a more user-centric video product, with excellent call quality, that ensured anybody could join a call with one click.

In January 2013, his new startup launched Zoom 1.0. They employed some clever tricks to make sure Zoom seamlessly installed and stayed up to date, so anybody could always join a call in one click. They pushed hard to ramp up the video quality. They prioritized UX at all costs.

Zoom as it once was.

The formula worked. A few months after launching 1.0, Zoom had 1 million users. In April 2019, they IPOed with $600M of revenue, were profitable, and were doubling yearly. By then they were well-known as the video app with the best call quality and UX, so when the pandemic happened the following year, Zoom was propelled to household name status.

Today, they have over $1B/yr in profit, and continue to grow. Zoom is one of the great startup success stories.

It’s also slowly falling apart.

Enterprise rot

Success at scale always causes problems. Enterprise software success, doubly so.

The first hurdle for Zoom, shortly after their IPO, was security issues. These ranged from underpowered encryption to leaky analytics to the revelation that their legendary one-click meeting flow was itself a security vulnerability. With market dominance in hand and billions of dollars of enterprise revenue on the line, Zoom started to unwind their approach of usability at all costs. Zoom founder Eric Yuan on this shift:

One-click is important. However, you need to make sure there’s not any potential issue, any potential violation of the operating system. Sometimes we have to sacrifice usability for privacy or security, that’s exactly what we did. We now think security or privacy [is] even more important than that.

And objectively, this is good! We want the software everybody uses to communicate to be private and secure. But it’s also a change in mindset from what made the product great in the first place. The defaults get locked down, the settings panels balloon, and Zoom is that much less likely to incubate the next team communications breakthrough.

Zoom was also one of the companies most thrashed around by the pandemic. While from the outside the surge in usage might have seemed like a blessing, it ultimately caused Zoom more trouble than it was worth. Yuan again:

I really wish there was no COVID. Zoom would be a much better company today. COVID, I do not think really helped us that much except for the brand recognition. For everything else, I feel like there was a negative impact to our business in terms of culture, and growth, and the internal challenge, or the competitive landscape. Everything else… I feel like it’s not good for us.

When your company goes from 2000 employees to 6000 in 2 years because of an event outside your control, you’re gonna have a bad time! You’re also going to get even more settings screens. How many settings, you ask?

The first two layers of Zoom’s admin settings now offer 63 sections and sub-sections worth of settings. These sub-sections are further divided into as many as 17 sub-sub-sections, which are then divided into as many as 12 sub-sub-sub-sections.

Developing a clear and coherent product is hard. Developing a clear and coherent product with 6000 other people is even harder!

The other day I had to log in to Zoom to change one of these myriad settings. Shown below is what Zoom looks like today when somebody at a 2-person startup logs in.

Now. In your opinion, what is the ideal number of times this screen should try to sell a startup an upgrade to allow over 100 people in a meeting? Maybe… 6 separate upsells? (The sixth is hard to spot, it’s partially hidden by the popover for the 5th upsell.)

There are even more upsells below the fold.

Of course nobody at Zoom decided 6 was the right number. While there is probably somebody at Zoom thinking about the 2-person startup UX, there are clearly 20x as many people concerned about increasing the number of customers who sign up for 500-person meetings. This dashboard is a veritable <marquee> banner that says “Our KPI is selling Large Meeting add-ons.”

Which I’m sure is logical! At least in the short term.

At the same time though, this stuff gives users the ick. “Avoid the ick” is not an OKR, and “% of users that hate navigating your settings” does not appear on your KPI dashboard. But it still accumulates.

When this kind of rot happens, it’s obviously bad. Any user can see it’s bad. But, importantly, enterprise customers don’t demand fewer settings, nor sane marketing position toward startups. So, often, these situations degrade.

It’s a tale as old as time. Occasionally a market leader who’s gotten off track will rally – especially if they’re still founder-led – to save themselves from fossilization and reinvent. In theory, Zoom could lever their position, in the center of billions of work meetings, into becoming a critical part of future AI-accelerated work.

More often, the gaps grow large enough that they spawn new startups. Blind spots and product debt compound until they recreate the situation that inspired Yuan in 2011: the market leader’s UX will be bad enough, and the potential for what could be will be compelling enough, that a worthy successor will launch. People will love it, and it will grow like wild.

Either way, we’ll look back on today as the bad old days, and appreciate how much better software has gotten. Customers will continue to demand better, and eventually someone will provide.

It’s the circle of life.