Bolt.new: How we scaled $0-20m ARR in 60 days, with 15 people

What happens when a company preparing to shut down suddenly finds demand for the technology it has spent years building? Before Bolt.new, StackBlitz had been operating for seven years. Eric Simons puts its ARR at $7.7 million at the October starting point he describes, with fewer than 20 people when Bolt launched.

The launch slide presents Bolt’s growth as zero to $20 million ARR in two months; the talk title specifies 15 people. Those figures frame Bolt’s launch, while Simons separately gives the company’s earlier ARR and a broader team-size bound. They should not be combined into a single reconciled revenue series. The immediate business problem was finding a venture-scale commercial offering for the same core technology the team had already built. Simons says they were preparing to close the company and hoped Bolt might add $100,000 in ARR by year-end.

Instead, demand exceeded their expectations. Simons says the result had since more than doubled, without specifying a fresh total. What surprised him about the plotted ramp was its smoothness: the product underneath it was an MVP he compares to a stripped race car, with bare metal and no passenger or back seats. The team had to absorb growth that he would ordinarily expect to take at least a year to grow into.

Simons estimates that around month two, roughly 30,000–40,000 active customers were being served by fewer than 20 staff. His comparison is the film 300: a small group surrounded by tens of thousands. Nobody had support or customer success in their title. Simons and his chief of staff largely answered the tickets themselves. What made that pressure survivable was a team that had already spent seven years working together; alignment, leanness and speed were established habits.

That operating style began before StackBlitz. Simons and his cofounder were childhood friends who had built websites together. They bootstrapped their previous company while broke and living on couches, learning how far a dollar could stretch and how expensive an inefficient search for product-market fit could become.

Their resulting principle was a small number of people with more context per head. Context gives an individual enough understanding to act without repeatedly asking permission. Removing chains of approval lets people build, make decisions and have an immediate effect. Smallness matters here because it supports informed agency, not simply because it reduces payroll.

Finding product-market fit requires enough attempts to survive the ideas that fail. Simons compares it to an enterprise salesperson trying to close $1 million: talking to three prospects and assuming they will all buy is not a pipeline. His illustrative funnel starts much wider.

Product experiments have the same need for a broad starting set. A company must remain alive long enough to try them, which makes burn rate part of its product-discovery strategy.

In Simons’s account, people are the largest expense. That does not mean never hiring; it means treating each hire as a decision that affects how many more attempts the company can afford. He describes an unnamed competitor from StackBlitz’s IDE business as having been acquired and stripped for parts two weeks before Bolt launched. He believes it could have been a meaningful competitor in the new market, but ran out of runway. StackBlitz had been heading toward a similar outcome.

A lean team also needs people who can function under pressure. The traits Simons emphasizes are mutually reinforcing:

• Low ego and high trust: Set personal status aside and cooperate on the problem.
• Commitment to user success: Keep attention on whether customers can accomplish their goals.
• Grit and resilience: Stay effective through volatility and chaos.

He considers those behaviors necessary for what Bolt experienced. They also matter in ordinary startup crises, when several urgent problems arrive at once.

Customer growth can set a company on fire just as readily as failure can. Imagine one firetruck in a town where everything is burning. The crew cannot respond everywhere; it has to choose the critical infrastructure and people to save. Identifying those priorities is difficult, but making that judgment is the job.

Some fires have to keep burning. A small team must accept that constraint and concentrate on the work whose impact compensates for what it cannot address. Hiring broadly can create the opposite pressure: once people are available, every problem appears to deserve its own effort. Simons’s heuristic is that focusing on 10% of the work often produces most of the meaningful result. It is a prioritization rule of thumb, not a measured allocation formula; the constraint forces clearer decisions about what matters.

Over the company’s life, startup advice repeatedly changed direction. Remote work was widely discouraged when StackBlitz began in 2017–2018. The founders initially rented an office in San Francisco, but their strongest candidates kept coming from elsewhere. Simons says they paid $5,000 a month for six months without hiring anyone locally. They committed fully to remote work around 2018; the pandemic subsequently made remote work fashionable, before sentiment swung back again. Following every reversal would have distracted them from the evidence in their own hiring process.

The same pattern appeared in funding and headcount. In 2021, investors urged the company to raise more money and hire more people. Roughly a year later, the advice became layoffs and spending cuts. Simons says StackBlitz had never made the earlier headcount increase. The point is not to oppose conventional advice automatically—some of it lasts—but to make decisions from an independent assessment of the business rather than adopting each new consensus.

During Bolt’s first week online, the product was brittle enough that Simons feared users would churn and lose confidence before the team could fix it. He and the team needed to become visible to the community. They began weekly office hours on YouTube and X, open to all users, showing what they were building.

The sessions made the work understandable: acknowledge what users were reporting, explain what was being addressed, share expected delivery dates and answer questions. That gave customers a way to see progress while capabilities were still missing. Simons credits this direct engagement with building affection for the product, while acknowledging that its effect is hard to quantify. Doing work that does not scale can help a young product retain the people it needs time to serve better.

Support was an obvious place to reduce the workload. For the first two months, Simons and his chief of staff spent substantial time answering emails. The team then adopted ParaHelp, whose assistant was called Sam. Simons reports that Sam automatically handled 90% of Bolt’s tickets and was its top-rated support assistant. He does not provide the measurement window, ticket denominator or rating methodology.

Simons estimates that serving this support volume one or two years earlier would have required 50 hires. The company was also training small models to help users inside the product, addressing needs that previously would have required human assistance. An AI product can use AI throughout the customer-success journey, beyond the feature customers initially come to use. When asked for the vendor’s name, he repeats ParaHelp and says he thinks Cursor is another customer.

Community fills a different need. Simons argues that AI cannot replace actually talking with users and creating a place where they can experiment, learn from one another and get help from experienced practitioners. For an AI product, that shared learning extends the customer experience without requiring the company to employ everyone who provides assistance.

Bolt put that approach into practice with the month-long World’s Largest Hackathon, which was underway during the talk. Simons reports more than 80,000 participants at that point and says the event had already surpassed the Guinness World Record. That is his contemporaneous claim, rather than evidence that Guinness adjudication was complete. Dozens of helpers were supporting participants as they built projects and tried the product.

The event combined scale with assistance: AI support and community support helped participants keep building. Simons describes it as the strongest marketing ROI the company had seen, without supplying a numerical return. The acquisition activity and the work of helping new users succeed were part of the same event.

Looking back, he describes the first two months as especially precarious because the team was so unprepared for the demand. His closing hiring principle returns to the 300 comparison: hire a small number of Spartans rather than an army. It is a description of the mentality the company seeks when adding people—people able to carry responsibility together under pressure.

The final audience question returns to the decision that preceded all this growth: how did the team decide what to build? Did it use a framework for talking with users, or generate ideas, ship experiments and see what stuck? The question covers both Bolt’s origin and what came afterward.

Simons says the team tried approximately five different ideas in the previous year. The products he had built that resonated most often began with something he personally found exciting. He contrasts that with projects that merely sounded commercially sensible—ideas that might increase ARR but did not produce the same intrinsic enthusiasm. Bolt was exciting enough to keep him awake, and the team then put it in front of users.

Users seemed excited, but that signal did not predict the size of the outcome. Simons says early feedback on Bolt was the same as early feedback on StackBlitz, despite their very different results. Prelaunch enthusiasm cannot settle whether a product will succeed. It can inform a decision, but the next necessary step is to launch into the world and iterate quickly. Preserving enough runway to take another shot matters because even promising early reactions leave that uncertainty unresolved.