Marketing executive at Bolt.new on AI code editor adoption patterns

We spoke with a former marketing executive at Bolt.new who helped launch their AI code generation platform during its early growth phase.

Key points via Sacra AI:

What's the biggest misconception people have about Bolt or about AI app builder tools more broadly?

The biggest misconception is generally who they're for and who's using them. In some cases, the perception is that they are for people who have absolutely no idea how to code. While there are AI builders out there that would allow someone with no knowledge of front end code to start with a plain English prompt and end up with a working website, the reality is that for the most part, these platforms, Bolt included, output code that you'll need to work with if you want to get something into production or into a working state. You'll need some working knowledge of what's being generated to get the level of customization you want.

You could continue to just prompt in English, but that would be pretty inefficient and you would likely get frustrated. The pattern is either you just want something that's a prototype and you don't really care exactly how it looks or the form factor you end up with, or you're using it to create some boilerplate or a starting point, and then you're probably jumping into the code to do those finishing touches and last mile changes.

Can you give an example of a typical user group where this misconception shows up? For instance, how often did Bolt attract true nontechnical users versus more technical prosumers or developers using it as a jump start tool?

The biggest example I can think of is a product manager. Product managers are often tasked with coming up with feature or product concepts and validating them rapidly before they get any engineering resources to actually build it. They have a vested interest in getting something that looks real without a lot of engineering investment.

Until about last year, they would use Figma mock-ups or, before that, Envision app click-through prototypes. Now we're seeing them skip over that whole designer iteration cycle and go straight into something like Bolt to come up with a realistic-looking proof of concept that they can put in front of potential users or customers. Generally speaking, a product manager is technical enough that if they need to make specific tweaks to better reflect the product they're trying to envision, they would be able to do that.

How did Bolt segment its users across technical skill level? Say, nontechnical users, prosumers like technical PMs or designers, and full developers. What mattered about each audience in terms of usage or monetization?

To be clear, I left StackBlitz before we got to the point where there was meaningful segmentation on the marketing side, but I can speak to the original hypothesis and what I saw until I left.

The initial hypothesis for building Bolt was to drive usage of StackBlitz's existing underlying technology called web containers. Web containers is a WebAssembly-based operating system that runs entirely within a user's browser, and it was the technology that made predecessor products like StackBlitz's editor possible.

Their main monetization strategy at the time was generating demand for web containers technology from enterprises who would need to run it on-prem. One idea was that if we created and open-sourced an AI code editor, large enterprises would want to run that entirely air-gapped in their own environment. Bolt was never built as a direct revenue-generating tool, and is actually open source to this day.

The initial pricing strategy was simply to charge a monthly subscription fee of $9, which was exactly the same price as the predecessor product. There wasn't deep thought put into monetization for Bolt as a standalone tool.

The results surprised everyone—the AI code editor as a standalone tool was wildly successful. Only now, about a year later, are they finally doing that enterprise motion where a team or company can buy a license for internal usage.

The founders were not only off-base in terms of how they would generate revenue from this platform, but also surprised by who was interested in the product. The initial hypothesis was that this would allow anybody to build a website—marketers building landing pages or technical writers building doc sites. But in the early days, we saw a lot of adoption from existing front-end engineers, design engineers, and front-end developers—basically StackBlitz's core audience—who liked that they could generate code much faster than before.

With that surprise adoption from experienced front-end devs and design engineers, how did those users typically behave once they got in? Were they just using Bolt as a faster way to scaffold front ends? Or were you seeing agent style workflows as well? Where they were wiring logic tools or APIs together through prompts?

In the early iterations of the product, some of those more advanced use cases where you're using external APIs or databases weren't even possible. It was entirely front-end focused. We were seeing a lot of simple website use cases, similar to what you might use Squarespace for—simple websites or simple internal tools or widgets.

Over time, we saw people use it for hobby side projects, some of which had a viral pull where they built web tools to do various things, but it was very much a front-end only use case. Later on, after my time there, they layered in Supabase integrations and things like that, which allowed for more full-stack use cases.

How often would users export their Bolt projects? Either to host elsewhere or continue development in another environment? Did that slow down monetization, or was it considered a feature, not a bug?

Actually, I don't know the answer to that. I can speak to what we saw with Bolt's predecessor, StackBlitz—for the most part, people weren't looking to export code. It was living in StackBlitz. More frequently, the request was "I have existing code already, can I bring it into the platform?" So there was a lot of effort put into GitHub integration, which allowed you to take existing code bases and pull them in. You could keep them in sync.

It was a new user pattern to go from starting with a blank slate, building out an idea in Bolt or StackBlitz, and then wanting to deploy to production through integration with Netlify or something similar. We didn't see that in the original StackBlitz, and I don't believe we saw that a lot in the early days of Bolt. But now, after my time there, they've built hosting integrations where, in theory, it's a one-click deploy.

If you look at one of the early Vibe coding platforms, V0 by Vercel, their strategy is fairly transparent. Vercel is a web hosting company, and their main revenue-generating engine is limited by how quickly people can build projects. If they accelerate the top of that funnel with an AI tool, they'll have a much higher volume of new projects coming online that they can then charge for hosting on Vercel.

I don't know if that revenue model is still exactly what they use now. As I mentioned earlier, Bolt was surprised by the revenue-generating capability of just the AI tools. But I think the underlying long-term assumption has always been that while there's money to be made on the AI code generation piece, ultimately it's a means to an end in terms of driving up more consumption of your hosting platform.

While you were leading growth and marketing, where did new sign-ups for Bolt actually come from? What acquisition channels or programs were most effective during your time there?

In the very early days, it was through our existing community and ecosystem. At the time Bolt was launched in the third quarter of 2023, StackBlitz had between 2 and 2.5 million monthly active users coming to the predecessor product. That had grown through inroads into the open source community, particularly the Angular front-end community and to a lesser extent the React front-end community.

These communities relied heavily on StackBlitz as a vehicle to share code, whether between individual developers who were debugging something, or more visibly, StackBlitz was embedded into the open source documentation sites of some of the most popular front-end frameworks in the world. That's where the organic virality came from.

We already had a pretty large user base when Bolt was launched. That user base combined with our social media reach and visibility in the community was a giant launching pad. Bolt was actually announced at a virtual event that StackBlitz had been doing for a few years called ViteConf. Vite is the build engine for a lot of popular modern front-end frameworks, and there were 30,000 to 50,000 people who signed up for that virtual event every year. So unlike many startups who start with friends and family, Bolt was shipped to an already substantial audience. Then the virality took off.

Can you break down what those viral mechanics looked like in practice? Was it project sharing, templates, social demos, or something else that drove that word-of-mouth?

It was project sharing, and what made that work so well for StackBlitz is that, if you think about any product that has built-in virality because of project sharing, it's all things that you can immediately consume with no upfront work. If you're sharing a Canva template, anybody with an internet browser can see that and consume it in its fullness. If you make a YouTube video, anybody with an internet-connected device can immediately watch that video—there are no special requirements or prerequisites.

Many dev tools companies have struggled to replicate that because in so many cases, there are technical requirements for code or a technical product to just work and be consumable. Tools like CodePen changed the game because when you shared a CodePen, which was HTML, CSS, and JavaScript, the experience was the same between the person who created it and the person who opened the link when it was shared. It leveraged fundamentals of how code renders on the internet.

StackBlitz is the same thing, but for modern front-end frameworks. Instead of having to pull down a code base locally, install dependencies, and hope that it runs as the original creator intended (which you might do with GitHub projects), you can click a link and get exactly the same experience as anybody else clicking it. And because it's front-end code, it's very visual.

Similar to CodePen in the early days of web development, things that went viral were examples where someone hacked JavaScript to make a cool animation or interaction that people hadn't seen before or didn't think was possible. In the same way, people were sharing StackBlitz projects and now Bolt projects where they're using React and Angular frameworks in new and exciting ways. You can click the link and immediately not only see the end user effect but also get the code to see exactly how they made it.

How did you think about Bolt's positioning versus other players like Lovable or V0 by Vercel? Where was Bolt strongest? And where did those others hold the edge?

To be honest with you, I don't think the go-to-market strategy was very thoroughly thought through. The culture of StackBlitz and the founders is to ship things and see what happens. We were aware of V0 at the time, and there was an open source clone of V0 where we had engaged with the developer of that tool. I think the strategy at first was to make this as close to V0 as possible.

The differentiator was that we were using the web containers technology, so all of the code was being executed in the browser itself. We could do things like server-side rendering or use more advanced front-end frameworks without any compute infrastructure, which is the whole benefit of StackBlitz in the first place.

The original differentiation was identical to the differentiation between StackBlitz and running code locally or trying to share code in a GitHub project. Later on, after I left, the differentiation has come down to code quality, efficient token usage, price, integrations, and more platform-level features.

While you were there, were there any specific integrations or starter templates that helped Bolt users activate more quickly or get to value faster? Or was that still too early in product maturity?

That was definitely too early when I was there. Any integrations we had would have been directly related to what StackBlitz's core platform had—GitHub, and very early Supabase and Netlify integrations. It was very much early days when I was there.

From your standpoint, where did retention tend to break with Bolt users? Was it onboarding friction, not enough ROI, unclear next steps? What did you learn about keeping users around?

From the early experience I had, we got a lot of people who would come in, test it out, and never come back. Early token limits had an impact on retention—there wasn't an easy way to keep going and get into that state where you can just keep iterating, and people would hit a pretty hard wall, which could seriously impact retention.

But I also think, like with so many of these tools, you need to come in with a job to be done or an idea, and not everybody has those ready to go. So we would see people come in, check it out, get the concept of how the product works, but they didn't actually have a use case they were ready to start building.

Were there any onboarding patterns, template starter flows, or prompting strategies that noticeably improved retention or time to value? Things that helped bridge the gap from just trying it to building something meaningful?

From my experience, again because I left in the very early stages, it was basically just templates and suggested prompts to help people understand what was even possible as a jumping-off point. But I don't know how that's evolved more recently.

From everything you saw at Bolt and this broader category, what do you think will be required for agentic coding platforms or AI app builders to reach more mainstream, durable adoption beyond the novelty stage?

I think the company or product that really cracks the code-to-visual-editor transition will be a winner here. Code is an abstraction that works really well for engineers.

We'll likely see these platforms divided into two buckets. One bucket is still code-first at its core, where the person who knows, understands, and is comfortable with code is the first-class citizen and has the best experience. The other bucket is what I'd call "Vibe building platforms," where there's a code option, but it's more of a WYSIWYG, drag-and-drop, Figma, or Webflow type of experience.

I think we're likely to see a repeating of what happened in web development where the first platforms were great for developers, then we saw a wave of no-code or low-code platforms for citizen website builders. But the platforms with the most reach are those that allow you to go back and forth fairly seamlessly—no-code for small visual tweaks, but with a first-class development environment when you want to do something more custom.

We'll see the same thing for these AI web building tools: how seamlessly do they serve each cohort of users, and how easily can you flip back and forth as needed or desired?

Anything else you'd add that we haven't covered? Maybe a specific lesson, surprise, or signal you think is important for investors or founders watching this space?

I guess the lingering question I have about these platforms is their long-term defensibility. Ultimately, what has enabled these tools is the foundational model providers. To the best of my knowledge, Bolt, Lovable, or V0 aren't training their own models—they're basically using off-the-shelf models from Anthropic or OpenAI, which makes sense since building and maintaining a model is expensive.

As soon as there's a step-function improvement from the foundational model providers, you'd immediately be saddled with outdated tech. However, those models are available to anybody, so I think distribution is ultimately going to win. I have questions around the core differentiation or defensibility of the technology.

Right now, they're differentiating on cost, user experience, features, and integrations. I don't know how long that's sustainable. A small scrappy startup can out-ship at the moment, but once a larger platform player decides to move into the space in a meaningful way, they're going to win on distribution.

Based on your time at Bolt, including what worked and what didn't, what leading indicators would you advise investors or founders to watch in the AI app builder space going forward? Anything that signals more durable value or breakout potential?

I think it's a combination of a longer-term strategy and hypothesis about the space, along with execution ability. A company like Vercel has the revenue incentive to get people up on their hosting, so they'll have a very different point of view and set of priorities to make the journey to production as smooth and fast as possible. We'll probably see the same thing for other website builders who have that hosting incentive, whether that's Webflow or Squarespace.

On the other hand, we have tools whose revenue model isn't based on hosting the final product—the one that jumps to mind is Figma. Figma is in an interesting position because they are historically this middle ground between design and development, which were two critical pieces of getting something onto the web.

I think they're probably having some existential conversations at the moment because the biggest change AI web development has brought is the role of the designer. There's still an important role for designers to play, but it's not as fundamental as it may have been a few years ago. That brings into question what the future is for platforms like Figma.

We've seen them release Desmodo, which was their attempt to get further into the actual production of assets for the web and bring in that new persona—the design engineer, that web developer who is actually creating the visual design of these products.

It will be interesting to see what they produce in the AI builder space because they don't have the incentive of getting something to production as their revenue source. It could be that they actually have a better ability to serve the needs of users who are just looking to build something that looks differentiated and clean, and then they outsource the hosting piece and the path to production through integrations.

You mentioned earlier that Bolt initially had a $9 monthly subscription, largely inherited from the predecessor product. Did you see any changes or run any early experiments around the pricing, credits, or packaging that materially affected user conversion or retention while you were there?

When they first shipped, they had just a single-player plan with a hard token limit and then à la carte token packages you could buy. That quickly broke with people burning through tokens at a clip where they'd hit a paywall and have to buy more. After my time there, they iterated pretty quickly on how those limits work and how you could true up.

We've seen a lot of these platforms flip back and forth between token-based and credit-based or request-based pricing. Request-based is very easy for a user to understand, but creates risk for the vendor since requests are definitely not created equal—one request could be incredibly expensive and subject to gaming and abuse. I think we've seen many tools consolidate around token-based pricing. As the market gets more familiar with how that works and thinking about work in terms of these units, we'll see that be more successful.

In terms of other pricing, they've layered on more plans. Initially, it was just that single-player plan. They've now added a team plan with collaboration features and end-user seats, and also an enterprise plan for companies that want a higher degree of control and governance over an internal set of users. There was demand for that latter offering long before it was available—they had an exceptional amount of inbound from enterprises and large companies asking for enterprise and team plans long before they existed.

Did you see any particular usage metric—whether tokens used, number of deploys, or something else—that served as a reliable predictor of conversion to paid or long-term retention?

Token usage, absolutely. For the free tier, the only way to get to a paid conversion moment was through consumption of those tokens and the number of requests users were sending to the platform.

When users did convert, did you notice any particular jobs to be done or use cases that tended to correlate with higher token usage and therefore higher revenue potential? And did any pricing levers like bundling seats or team credits work particularly well for upsell?

I don't have visibility into the upsell piece as that was after my time. In terms of what was a good predictor of conversion, it really came down to whether the project was critical or important, which can be measured in a couple of different ways.

The foundational question is: is anybody else going to see this? If it's a personal tool to help your individual life work better, it's probably unlikely to convert. But if you're going to share this publicly, like on your own website or even on social media, there's a level of polish that people want to achieve. That was the first heuristic we saw—is this just for you, or is this going to be shared?

For things that are going to be shared, there are further stratifications. What is this web page actually doing? Is it relatively static and just communicating information? That's probably a low propensity to convert. Is it dynamic, where an end user is interacting with it? That has a higher propensity to convert because there are more complex user experience considerations.

The last bucket, which I didn't see much of in my time because it was so early, was: is this revenue-generating? Is there actually a monetization angle for the tool you're building? In that case, that's the strongest signal that there's going to be budget or paid spend behind it.

You're seeing some of the more recent releases speak to this. Lovable just announced projects having built-in search engine optimization. SEO only matters if it's something you want people to find, and it generally only matters if there's revenue potential from more users. This points to more users using these tools for revenue-generating products, and that is where the platforms are driving an outsized portion of their revenue from and what's now driving feature roadmaps.

I think we'll see investments in built-in analytics, integrations to Stripe and payment processors, SEO as I mentioned—those features and capabilities that turn a static web page into something that's more of a fully featured product. I expect that the roadmaps for Lovable and Bolt will start to resemble the roadmaps of Squarespace from 5-10 years ago.

If you were advising a founder entering this space today, what's one positioning or product mistake you'd warn them to avoid?

The first thing that comes to mind is having a clear answer to the question, "Who are you for?" I think that was a challenge for a lot of these platforms—their initial hypothesis was either incorrect or they lacked one entirely.

One of the most fundamental things about building a product is that you have to know who your user is, and I don't think that was terribly clear. Having a hypothesis of who you're building for, what they actually need, what abstractions they prefer to use, and then maybe pushing the envelope a little bit where those abstractions that were previously off-limits to them are no longer as off-limits or uncomfortable because of the AI changes—it comes down to having a really clear hypothesis of what gap you're filling.

This transcript is for information purposes only and does not constitute advice of any type or trade recommendation and should not form the basis of any investment decision. Sacra accepts no liability for the transcript or for any errors, omissions or inaccuracies in respect of it. The views of the experts expressed in the transcript are those of the experts and they are not endorsed by, nor do they represent the opinion of Sacra. Sacra reserves all copyright, intellectual property rights in the transcript. Any modification, copying, displaying, distributing, transmitting, publishing, licensing, creating derivative works from, or selling any transcript is strictly prohibited.