Arc Never Broke Through. Why Did Dia Sell for $610M Three Months After Launch?

If the same team had the chance to rebuild a product that failed to break through, what would they remove, what would they keep, and where would they invest the attention they saved?

Arc and Dia give us a rare chance to see the answer. Arc attracted enormous attention and built a loyal following, but it never reached the mainstream. Dia was created by the same people, and three months after it launched, the company was acquired for $610 million.

The interesting part is not simply that the second product produced a better business outcome. It is what the team changed when they were given a second attempt.

Why the second attempt tells us more

The Browser Company built Arc first.

Arc raised around $128 million and gathered a genuinely devoted user base, but its share of the global browser market never rose above 0.1 per cent. In May 2025, the team put Arc into maintenance mode and stopped directing its main development resources towards it.

A month later, Dia launched. By September 2025, Atlassian had acquired The Browser Company for $610 million.

There were only three months between Dia's launch and the acquisition. Two browsers came from the same company and the same core team, yet the outcomes were completely different.

Josh Miller, the founder of The Browser Company, later shared an observation from former Apple executive Scott Forstall in his farewell to Arc:

Arc felt like a saxophone. It was powerful, but difficult to learn. The team needed to build a piano, something almost anyone could sit down and play.

The comparison fits.

Arc contained a large number of inventive features and interactions, and most of them asked the user to learn something unfamiliar. Each concept made sense on its own. When they appeared together, the user had to learn an entirely new product language before they could understand why the browser was useful.

Dia took a more practical direction. It kept the parts of Arc that had proved valuable, then placed them back inside a browser model that people already understood.

That is what makes Dia an unusually useful product to study.

We do not have to rely entirely on speculation about which decisions in Arc went wrong, because the same team answered many of those questions through the product they built next. What survived, what disappeared, what was renamed and what returned later all give us a clearer picture of where the product's real value was.

If the Arc teardown was an examination of what went wrong, Dia shows what the team chose to do differently once it had the evidence.

The first correction: helping the right users recognise themselves

When someone encounters a product for the first time, they usually have not started reading the copy or examining the feature list.

What reaches them first is the typeface, the colour, the imagery, the layout and the overall mood. Within a few seconds, those signals begin to answer a simple question:

Does this look like it is meant for me?

Arc's website was beautiful. It had a warm, slightly retro and artistic quality that placed it somewhere near Notion, Substack and Linktree. That visual style appealed to people who enjoyed experimenting with new tools and shaping their digital environment.

Arc's most devoted users, however, were largely engineers, designers and product managers. Their daily concerns were more practical: managing tabs, moving between projects, keeping workspaces organised and processing large amounts of information.

There was a clear gap between the way Arc presented itself and the people who found the most value in using it.

Many people could look at Arc, appreciate its design and still struggle to understand what problem it would solve for them. Before they had even tried the product, the visual presentation had already delivered an invitation that was slightly too vague.

Dia corrected this directly.

Its website presents a morning work brief, a meeting countdown, document planning and page summaries. The typography, layout and demonstration scenarios are more restrained, and they resemble the tools knowledge workers already use every day.

A few seconds of scrolling leaves a relatively clear impression: this is a browser for work.

I call this the Fit Audit.

It looks beyond whether an interface is attractive and asks which kind of person the visual language is inviting. Every visual direction draws some people closer while quietly telling others that the product may not be for them, and this judgement often happens before the first sentence has been read.

Visual style is never only packaging. It is also the first filter a product applies to its potential users.

Dia has not resolved this perfectly.

Its homepage still includes Spotify and picture-in-picture video, which sit closer to consumer browsing. At the same time, Atlassian describes Dia much more narrowly as a browser for knowledge workers moving between SaaS applications.

There is still some hesitation in the positioning. Dia wants to serve professional users without closing the door on a broader consumer audience.

It is much clearer than Arc, although the product has not fully committed to one side.

Arc asked users to learn too much, too soon

Arc's deeper problem can be found in the number of concepts it expected a new user to understand.

Someone starting with Arc encountered Profile, Space, Folder, Easel, Boost, Tab, Command Bar and Pinned Tab.

Tabs and pinned tabs were familiar browser concepts and required almost no explanation. Most of the others were created by Arc, and each came with a logic that differed from a conventional browser.

Consider Space. What exactly was it?

It behaved partly like a browser window and partly like a workspace, without mapping neatly onto anything the user already knew. Easel was a canvas inside the browser. Boost changed the appearance of a webpage. Profile represented more than the account switching found in other browsers.

Each idea had a reason to exist. Presented together, however, they stopped feeling like a handful of new features and began to feel like an entirely new product language.

The amount of attention anyone is willing to spend learning a new product is limited. Every invented concept therefore has to justify the attention it consumes.

Suppose a new user is willing to spend around 90 minutes during the first week learning how a product works. Every genuinely unfamiliar concept requires reading, experimenting, making mistakes and gradually forming a habit.

If six invented concepts each consume ten minutes, an hour disappears quickly. By the time the user reaches the features that make Arc meaningfully different, they may have little patience left to explore them.

One of the most dangerous moments for a product is when the user's attention has already been spent on learning, while the value has yet to appear.

The numbers Arc later published support this interpretation.

Only 5.52 per cent of daily active users had used multiple Spaces. Live Folders reached 4.17 per cent, while the calendar hover preview reached only 0.4 per cent.

Josh Miller called this the novelty tax.

Looking further upstream, Space may not have been badly designed. A more likely explanation is that Profile, Folder, Easel and Boost had already consumed too much attention before users reached it.

Dia's response was direct.

It reduced the core concepts to three: Profile, Tab and Group. It also retained Split View and introduced the AI-generated Report.

There are at least three changes contained in this decision.

The first is quantity. With fewer concepts to hold in mind, it becomes easier to start using the product.

The second is the use of existing habits. Dia's Profile maps closely to Chrome's account model, so most people already have a rough understanding of what it means. Arc used the same word for a container system that had to be learned separately.

The same label can carry a completely different learning cost depending on the behaviour behind it.

The third change is easier to miss. Dia delays much of the learning until the user actually needs it.

Arc's sidebar presented Space, Folder and the other concepts from the beginning. Dia's Group usually appears after someone drags two tabs together, and the AI can name it automatically.

The user does not have to study a definition of Group and then decide when it might be useful. They perform a natural action first and understand the feature in context.

Anything that can be learned at the point of use should not have to be memorised on the first day.

I call this the Cognitive Budget Audit.

The method is straightforward. List every concept a new user must understand before they experience the product's value. Then classify each one as familiar or invented, and as necessary upfront or safe to introduce later.

When people describe a product as too complicated, the instinct is often to delete features. That can be expensive, because valuable capability may disappear along with the complexity.

A better first move is to replace invented concepts with familiar ones, then move upfront learning to the moment of need. In many cases, the product does not need less capability. The cost of understanding that capability simply needs to come down.

Dia spent the attention it saved on AI

The clever part of Dia is not simply that the interface became easier to understand. The team also had a clear destination for the attention it had saved.

Many products add AI by placing a chat window on the right-hand side. The user has to find the entry point, switch into an AI mode and decide what to type.

Dia took a different approach. It placed AI in four situations, each with a different level of friction and a different kind of value.

AI in the address bar

Dia's primary AI entry point is the address bar people already use every day.

You can type a URL or type a question. The design builds on one of the most established habits in the browser. There is no new button to find and no separate AI page to enter. You begin by typing, just as you always have.

My estimate is that 60 to 70 per cent of Dia's AI usage happens here. This cannot be confirmed through public data, but the structure of the product makes the address bar clearly dominant.

A side conversation while you read

The second entry point is the side chat.

While reading a page, you can ask Dia to summarise it, explain a passage or answer further questions about the material in front of you. It requires one more deliberate action than the address bar, but it is better suited to sustained reading and conversation.

My estimate is that this accounts for around 15 to 25 per cent of AI usage.

A report across several tabs

The third entry point is the most distinctive.

You can select several tabs and ask Dia to compare them, identify patterns and produce a structured report.

You might open several competitor websites and ask it to compare their pricing models, or collect a group of articles and ask where the authors disagree.

This requires the user to select multiple pages deliberately, so the interaction carries more friction. I would expect it to account for perhaps 5 to 10 per cent of use, while delivering more value each time it is used.

Suggestions initiated by the browser

The final category is a suggestion initiated by the system.

Dia might tell you that 28 tabs have not been opened for some time and ask whether you would like to clear them.

This has the highest trust barrier. When a browser suddenly recommends closing my tabs, my first instinct is usually to ignore it, and I suspect many users respond in the same way. Usage may therefore sit somewhere between 0 and 5 per cent.

How many AI entry points does a product need?

The important design decision is that Dia does not treat all four entry points equally.

It makes the address bar the primary surface, then uses the others for more specific jobs. This is likely to become a lasting pattern in AI products. Because AI can perform so many tasks, teams are tempted to create a separate entry point for every capability, eventually producing several usable surfaces without building a strong habit around any of them.

Cursor, Linear and Dia follow a similar pattern. They identify the most frequent and natural entry point, concentrate investment there, then let supporting surfaces handle the more specialised cases.

An AI product usually needs one strong primary surface, with the other entry points organised around it. Four surfaces competing for equal attention rarely create a clear habit.

This leads to another useful question.

Once a team has lowered the cost of learning its product, where does the saved attention go?

Some products become simpler and cleaner without helping users reach the core value any faster. Complexity decreases, but the product also loses part of what made it distinctive.

Dia avoided that outcome. It reduced the effort required to understand Arc's original concepts, then used the space it created to introduce AI.

I call this the Freed Budget Audit. In simpler terms, it asks whether the attention saved through simplification has been redirected towards the capability that matters most.

Josh Miller has published two relevant figures. Dia's chat-with-tabs feature reached 40 per cent of daily active users, while personalisation reached 37 per cent.

These are among the few public usage figures available for Dia. They suggest that AI became a meaningful part of the product's value instead of remaining a feature that only looked impressive in a demonstration.

When a product removes complexity, it needs to know what the newly available space is meant to support. Otherwise simplification becomes little more than deletion.

What survives a rebuild is usually the real product

Ask a product team which features matter and they will often say all of them. Ask the same team to rebuild from scratch and the answer becomes much more revealing.

It is similar to moving house. Space, time and money are limited, so you carry what you genuinely need and leave the rest behind.

When moving from Arc to Dia, the team kept the Command Bar, Split View, the basic sidebar structure and the tab lifecycle that automatically archived inactive tabs.

It removed Spaces, Folders, Easel and Boost, along with some of the AI features added later to Arc, including Tidy Tabs and Call Arc.

The most important item on that list is the Command Bar.

In Arc, it had already become more than a place to type URLs. It served as a single surface for receiving user intent. Opening a page, searching, running a command and calling AI could all begin there.

Dia kept this interaction and pushed it further, turning it into the primary AI entry point.

This suggests that the Command Bar was one of Arc's most valuable product assets. It has survived two generations of the browser and remains at the centre of the experience.

I call this analysis the Moving List.

When you want to understand which features genuinely matter, ask the team a more demanding question:

If you had to rebuild tomorrow and could keep only half of the product, which half would survive?

Asking what is working badly often invites explanation and defence. Asking people to choose half forces an actual ranking.

Dia is the Moving List that The Browser Company wrote for itself, with the complete user data available.

The list changed again later.

Around six months after Dia launched, the team began bringing back some of Arc's popular features, starting with a sidebar mode. This suggests that some elements had been removed too quickly.

A Moving List therefore becomes more useful when read twice.

What survives the initial rebuild reflects what the team believes is core under pressure. What returns later shows what users missed enough to demand back.

What a team keeps tells you what it believes matters. What users demand back tells you where the value was felt.

The difference between those two lists is often where the first judgement was too aggressive.

A $610M acquisition still does not prove product-market fit

At this point, Dia appears to be a complete success story.

It clarified the positioning, reduced the learning cost, directed the saved attention towards AI, retained Arc's most important interaction and ended with a $610 million acquisition by Atlassian.

There is another side to the story.

Many of Arc's differentiating features had usage rates between 5 and 12 per cent. If the goal is to build a free browser for the mainstream market, those figures are dangerous. The team invested heavily in capabilities that most users never adopted.

Under a different business model, however, the same numbers could lead to a different conclusion.

Suppose Arc had accepted that it was a paid professional tool. A group representing 5 to 12 per cent of its users might then have been a valuable core audience. The company could have charged them and continued building deeper, more specialised features around their needs.

Data does not tell a team what to do on its own.

The same usage rate can signal failure in a mass-market product and identify a valuable group of paying users in a professional tool.

The interpretation depends on the business model and the scale the company is trying to reach.

Dia chose the more familiar, more accessible and easier-to-distribute direction. That decision led to the acquisition, but we still do not know whether Dia could have grown into a mainstream browser independently.

Dia launched in June 2025 and was acquired in September. Three months is far too short to validate long-term retention, willingness to pay or the potential market size of a new browser.

After the acquisition, Dia can grow through Atlassian's customers and distribution channels. That is a very different environment from competing independently with Chrome, Safari and Edge.

Its reachable market is also limited by platform availability. For now, the product is focused largely on Apple Silicon Mac users. Until Windows, Intel Mac and Linux versions arrive, its coverage remains restricted.

There is also an interesting repetition in the company's history.

In 2014, Josh Miller sold Branch to Facebook for $15 million. Eleven years later, he sold Arc's successor to Atlassian for $610 million.

Both products were well designed and loved by a relatively small group. Both were acquired by a larger platform before reaching mass scale on their own.

Dia may show that The Browser Company finally found genuine product-market fit. It may also show that this team is exceptionally good at creating polished, distinctive products that large platforms want to acquire.

Both interpretations remain possible.

The open-market data required to separate them does not exist, because the acquisition happened before Dia had time to produce it.

Five questions to take from Arc and Dia

Remove the product names and this case leaves five questions worth asking repeatedly.

1. Who is your product inviting at first glance?

Do the visual style, examples and language allow your real customers to recognise themselves quickly? Or are you attracting people who appreciate the design but never become committed users?

2. How much must a user learn before reaching value?

List every concept. Which ones are already familiar, and which require explanation? Which must be understood immediately, and which can appear only when they become relevant?

3. Once the product becomes simpler, where does the saved attention go?

Simplification is a process, not the final goal. The attention you free should be redirected towards the capability that genuinely differentiates the product. Otherwise the experience may become cleaner and more ordinary at the same time.

4. If you rebuilt from scratch, which half of the features would survive?

This question quickly separates core value from historical baggage. After making the cut, watch which removed features users ask to have restored.

5. Does the meaning of your data depend on the business model?

A feature used by 10 per cent of users may indicate that the direction is wrong. It may also belong to a small group willing to pay. Before acting on the number, check whether the assumed business model is the right one.

What Dia really fixed was the allocation of attention

Arc gave us two useful tools for examining a product: the Fit Audit and the Moving List.

Dia supports both and adds a fuller way of thinking about cognitive cost.

First reduce what the user must understand. Then examine where the attention you saved has been invested.

Complexity has no value by itself. The important question is whether each piece of complexity is asking for attention in a place that deserves it.

Arc spent a large amount of user attention explaining its own invented concepts. Dia used more familiar structures such as Profile, Tab and Group, then redirected the attention it saved towards AI.

It did not abandon Arc's design ambition. It became more selective about which ideas deserved the user's time and which burdens the product should carry on the user's behalf.

That is what makes Dia worth studying.

When a team gets the chance to build a product again, the choices it makes are often more revealing than any retrospective article. What was removed, what survived and what later had to return all answer the same question from different directions:

Which part of the product was actually valuable?

If you are building something now, it may be worth writing your own Moving List.

If you had to start again tomorrow, what would you carry into the new product? What remains only because it has been there for a long time and no one wants to be responsible for removing it?

---

If any of those questions landed without a clean answer, that gap is worth a closer look.

I write diagnoses like this one for other products: where your design is quietly serving the wrong outcome, what that is costing you, and what to change first. If you would like one for yours, email me at hi@bearliu.com.