Why Bolt.new Won and Most DevTools AI Pivots Failed - Victoria Melnikova

In December 2023, Eric Simons walked into a StackBlitz board meeting facing a shutdown threat. In Victoria Melnikova’s account, the company had raised millions over a seven-year journey, yet revenue was practically zero and growth was flat. Its central technical bet—WebContainers, which brought a development environment into the browser—had not translated into a viable business. The board gave Simons until the end of 2024 to show real progress.

The turnaround came with Bolt.new. Melnikova reports that Bolt.new reached $20 million in annual recurring revenue in two months. ARR describes an annualized recurring revenue rate, not revenue collected during those two months. At the time of the talk, she expected a forthcoming update to put Bolt.new above $100 million ARR. That second milestone was a forecast. The striking growth story rested on capabilities built long before the new product appeared.

Melnikova had seen that work through Evil Martians’ partnership with StackBlitz, which began in 2021, when browser-based development still attracted skepticism. She says Evil Martians works with more than 40 early-stage developer-tool startups each year. Across those companies, the recurring question was how to bring AI into an existing product. StackBlitz’s experience suggests that the more useful starting point is the capability the company already owns.

Adding a chatbot looks like a small product change, but it spends something scarce: a user’s willingness to try again. Melnikova describes customers already tired of chatbot interfaces and reluctant to test another AI feature. If the first result disappoints, they may never return. The feature can then drift toward quiet deprecation before the team finds a useful application for it. The failure begins with an interaction that asks for attention without delivering enough value.

Expanding the scope creates a different problem. Trying to make everything AI-powered puts a smaller developer-tool company into competition with OpenAI and Anthropic, without comparable teams or investment. A narrower starting point is the company’s distinctive domain, expertise, or technology: something that makes its particular application of AI difficult to reproduce.

Waiting for AI to become perfect also postpones the work that makes it useful. Tool builders have to develop the surrounding tooling as the models evolve, using practical, creative solutions to close the gaps. But speed alone does not establish demand. Melnikova describes companies investing heavily in beautiful, intricate interfaces that users do not need.

Talk to users before committing to the interface. A technically impressive implementation still needs a market. With that constraint in place, the StackBlitz case becomes a three-step procedure: identify the competitive advantage, work out what AI makes possible with it, and redesign the workflow around that possibility.

The first step is to identify an unfair advantage, rather than inventory product features. For StackBlitz, that advantage was running a full development environment inside the browser. Melnikova presents this as a unique competitive position; the concrete technical capability is browser-local execution. Her shorthand—no containers, servers, or local setup—describes removing the need to provision a separate development environment. It does not mean that model inference, hosting, or the whole Bolt service requires no servers.

Other companies may find their advantage elsewhere:

• Domain expertise: knowledge of a specialized problem and the people who face it.
• Data or distribution: information or access that gives the product a distinctive position.
• Infrastructure: an existing technical capability that changes what the product can deliver.

The useful question is which of these assets gives the company a competitive edge, before deciding where AI belongs in the interface.

The next question is what becomes possible when AI meets that capability. This shifts the design task from placing AI somewhere in the existing product to finding an outcome the combination can make easier. For StackBlitz, browser execution supplied a way to close the distance between asking for an app and seeing it work.

Melnikova describes other vibe-coding workflows as too complicated for an average user. Bolt’s proposed experience has three direct steps:

1. Describe the app in words.
2. See the app directly in the browser.
3. Share its URL publicly.

The browser environment matters because generated code can become something the user immediately sees, rather than an artifact they must move into a separate development setup. AI supplies the creation interface; the existing runtime makes the result accessible within the same flow.

The third step is to consider whether the capability can change the whole workflow enough to create a category. Improving an individual step leaves the surrounding handoffs intact. Melnikova’s slide instead contrasts two complete paths:

The slide’s immediate-deployment framing makes the intended product experience explicit: move the user from describing an app to sharing it, with fewer development tasks exposed along the way. Melnikova credits StackBlitz with reinventing how people vibe code through that change.

The differentiator was the combination of an existing capability and a redesigned user flow. Access to Anthropic was available to others; unique AI was not the advantage Melnikova identifies. Once StackBlitz recognized how its browser technology could support this experience, it committed fully to the new product direction.

The difficult part is being honest about the product you already have. What is its moat? How could AI amplify that advantage? Could the combination reinvent a workflow, and could that workflow support a new category? These questions may expose a gap between the features a team has invested in and the capability customers actually value. Answering them gives the next product decision a direction; it does not guarantee another Bolt.new.