Growth Machines: The Cursor Story
Lessons in scale you can steal from the fastest growing SaaS ever
Four MIT students fork a code editor in 2022. Two years later, they are running the fastest-growing SaaS company in history.
$1 million in revenue in 2023. $100 million in 2024. $1.2 billion in 2025. A valuation of $29.3 billion by November 2025. An 11x increase in twelve months.
Here is the detail that should bother every startup founder reading this: they spent zero dollars on marketing to reach $100M ARR. Not “low marketing spend.” Not “efficient growth.” Zero. If you are building a product right now and your growth plan starts with “demand gen,” this story is about to rearrange your priorities.
Cursor is the most instructive growth story in software since Notion. It made five specific product decisions that any builder can study, steal, and adapt, whether you are building an AI-native startup, a developer tool, or a productivity product in any category.
This is a teardown of those five decisions. What they chose, what they rejected, and what made each choice compound into the kind of growth that makes VCs rewrite their models.
Michael Truell, Sualeh Asif, Arvid Lunnemark, and Aman Sanger met studying computer science and math at MIT. They collaborated at MIT CSAIL, MIT’s Computer Science and Artificial Intelligence Laboratory, before founding Anysphere in 2022..
Everyone was saying AI is the future of coding, but their bet was more specific and more interesting: the right place to embed AI is not on top of the code editor as a plugin. It is inside the code editor itself. That distinction, on top vs. inside, is the entire story of Cursor’s product.
They raised $3.38 billion in total funding from Accel, Coatue, Thrive Capital, Andreessen Horowitz, Google, and NVIDIA. Today, Cursor has over 1 million daily active users, 360,000 paying customers, and more than 50,000 enterprise accounts. It generates nearly a billion lines of code daily. Major customers include Stripe, OpenAI, and Spotify.
The numbers are staggering. The decisions behind them are useful.
Decision 1: Fork, Don’t Build
The first decision Cursor made saved them two years. They forked VS Code. They took the open-source codebase of the most widely used code editor in the world and made it theirs.
This gave them three things instantly:
Muscle memory. Every developer who uses VS Code (hundreds of millions) already knew how to navigate Cursor on day one. Keyboard shortcuts, extension ecosystem, settings, themes — all familiar. The switching cost was almost zero.
Maturity. VS Code is decades of engineering work. The file system, the debugging tools, the terminal, the Git integration, and everything that makes it work, Cursor did not have to build any of it. They inherited a production-grade foundation.
Depth permission. A plugin sits on top of VS Code, it can suggest a line of code. It can autocomplete. But it cannot fundamentally change how the editor understands your project. A fork on the other hand can rewrite the way context flows between files. It can introduce Composer mode, a multi-file, project-aware AI that understands the relationships between your modules, your tests, and your config.
The lesson is clean: when a mature, open-source platform exists in your domain, forking it is not lazy, it is strategic. You skip the years of infrastructure work and go straight to the layer where your actual differentiation lives. Every month you spend building what already exists is a month your competitor spends building what doesn’t.
Decision 2: Custom Models for Workflow, Foundation Models for Reasoning
The second trap Cursor avoided was the “API wrapper” trap.
In 2023 and 2024, thousands of startups launched products that were thin interfaces around OpenAI or Anthropic API calls. The problem is, when the model provider ships a better default UI, your product becomes redundant overnight.
Cursor built custom AI models trained specifically for coding workflow tasks. Things like advanced autocomplete that understands multi-file context, predictive edits based on your recent changes, and code generation that respects your project’s patterns and conventions. These custom models handle the workflow-specific tasks. Foundation models like GPT and Claude handle the general reasoning.
This is a deliberate architectural split: proprietary models for the 80% of interactions that are workflow-specific, foundation models for the 20% that require open-ended reasoning.
By the time Cursor 2.0 shipped, it included a multi-agent architecture and a proprietary Composer model that could orchestrate complex, multi-step coding tasks across an entire project. This was not something you could replicate by calling an API.
If your only moat is a nice UI around someone else’s model, you do not have a moat. Build custom intelligence for the workflows that are specific to your domain. Use foundation models for everything else. The custom layer is where your product becomes irreplaceable.
Decision 3: Serve Power Users First, Everyone Else Later
GitHub Copilot has over 20 million users. Cursor has around 1 million. Cursor makes roughly four times the revenue.
20x fewer users, 4x more revenue.
How? Copilot optimized for the broadest possible audience. Single-line autocomplete suggestions works fine for casual code. It’s a great convenience tool.
Cursor optimized for professional developers doing the hardest work. Multi-file edits. Project-wide context. Agent-mode workflows that can scaffold entire features. Composer sessions that understand the relationships between your API routes, your database schema, and your frontend components.
When you serve power users first, three things happen:
They pay more. Cursor Pro at $20/month and Business at $40/month convert at higher rates because the value proposition is clear: this tool does not help you write code a little faster. It fundamentally changes how much you can ship in a day.
They evangelize harder. A casual user who saves 10 minutes a day tells nobody. A senior engineer who ships a feature in an afternoon that used to take a week tells everyone on their team. And their team tells other teams. This is how you get $100M ARR with $0 marketing spend.
They are harder to displace. Once a power user has rewired their workflow around your tool, switching costs are enormous because of habit, muscle memory, and accumulated context.
By October 2025, Cursor had captured approximately 40% of all AI-assisted pull requests despite having a fraction of Copilot’s user base. The power users were producing the majority of the output.
The lesson is counterintuitive for founders raised on “total addressable market” thinking: a smaller market of high-intent users is more valuable than a larger market of casual users.
Decision 4: Let the Product Be the Marketing
Cursor’s growth was entirely product-led. No ads. No content marketing. No sales team (until enterprise). No growth hacks. The product itself was the distribution mechanism.
Here is how this worked:
A developer tries Cursor’s free tier (2,000 monthly completions). They experience the difference between single-line autocomplete (Copilot) and project-aware AI editing (Cursor). They upgrade to Pro. They mention it in a team standup. Their teammates try it. Their manager notices the team is shipping faster. The company starts a Business plan. That company’s engineers mention it at a conference. The loop repeats.
This is not a new idea. Slack did it. Figma did it. Notion did it. But Cursor executed it in a category (developer tools) where the word-of-mouth dynamics are unusually potent. Developers are opinionated about their tools. When one of them switches editors, everyone notices and everyone asks why.
The free tier was not a lead-gen funnel in disguise. It was genuinely useful. 2,000 completions per month is enough to get real work done. This matters. A free tier that feels crippled creates resentment. A free tier that feels generous creates evangelists.
Revenue doubled approximately every two months during the hypergrowth phase. That does not come from marketing campaigns. That comes from a product that makes people want to tell other people about it.
The principle for builders: if your product requires a sales pitch, it is not ready. The product should be the pitch. The users should be the sales team.
Decision 5: Usage-Based Pricing for the AI Layer
In August 2025, Cursor shifted to usage-based pricing for its agent features. The logic: the more the AI does for you, the more you pay. If Cursor’s agent writes 500 lines of code that would have taken you two hours, you pay proportionally more than when it autocompletes a function name. The price reflects the value delivered, not the time spent in the editor.
This matters for two reasons.
First, it makes the economics self-correcting. As AI capabilities improve, users get more done per session, which means they pay more per session, which means revenue grows with capability, not just with headcount.
Second, it signals confidence. A usage-based pricing model says: “We believe you will use this so much that you will be happy to pay for what you consume.” A flat-rate model says: “We hope you use this enough to justify the price.”
The pricing tiers: free (2,000 completions), Pro ($20/month), Business ($40/month), plus usage-based agent pricing create a natural upgrade path. You start free. You hit the limit. You upgrade. You start using agent features. You pay for what you consume. At every step, the value is obvious before the payment is required.
The Copilot Counterpoint
What Happens When You Go Broad Instead of Deep
No teardown is useful without a counterexample. Copilot is the counterexample.
GitHub Copilot launched with Microsoft’s distribution muscle. It is bundled with GitHub. It is integrated into VS Code as a plugin. It has the backing of OpenAI. It has over 20 million users and penetration in 90% of the Fortune 100. It generates roughly $300 million in ARR. Cursor, with 5% of the user base, generates $1.2 billion.
Why? Because Copilot is constrained by the plugin architecture. A VS Code plugin cannot do what a VS Code fork can. It cannot rewrite how the editor processes project context. It cannot introduce multi-agent workflows that operate across files. It cannot build Composer mode. The plugin model inherently limits how deeply AI can integrate with the development workflow. Copilot optimized for breadth: every developer, every use case, every company.
The Moat Question: Is This Sustainable?
Intellectual honesty demands we address this. Cursor’s moat is real, but it is thinner than the valuation implies.
Three threats worth watching:
Microsoft’s bundling power. GitHub Copilot is already included in enterprise contracts. When your competitor can offer “free with GitHub Enterprise,” you need your product to be dramatically better, not marginally better. So far, Cursor clears that bar. But the bar moves every quarter.
Agent platforms targeting non-developers. Tools like v0 and Bolt.new are not competing with Cursor for professional developers. They are competing for the “vibe coder”, the non-developer who can now build software with AI assistance. If that market becomes larger than the professional developer market, Cursor’s power-user strategy becomes a ceiling, not an advantage.
Model providers building vertically. OpenAI, Google, and Anthropic all have incentives to build their own coding environments. They have direct model integration advantages that third parties cannot match. If Claude or GPT ships a native IDE experience, Cursor’s custom model layer becomes less differentiating.
The current valuation of $29.3 billion sits at roughly 58x ARR. That prices in sustained hypergrowth. If any of these three threats materializes faster than Cursor’s product evolves, that multiple compresses quickly.
There is also a sentiment signal worth noting: developer favorability toward AI coding tools dropped from over 70% in 2023-2024 to 60% in 2025, even as adoption rates rose to 91%. Developers are using these tools more but trusting them less.
The Fork-and-Deepen Playbook: What You Can Steal
Strip away the specifics of code editors and AI models. What is the replicable playbook?
At 0 to 1: Fork, don’t build. Find a mature, open-source or widely used platform in your domain. Fork it or build deeply on top of it. Skip the infrastructure years. Go straight to the differentiation layer. Your users get instant familiarity. You get instant focus on what matters.
At 1 to 10: Serve the 10x user. Do not build for the average user. Build for the most demanding user in your category. The user who will restructure their workflow around your product if it is good enough. These users pay more, evangelize more, and are harder to displace. They are your growth engine.
At 10 to 100: Let the product be the distribution. If you need a sales deck to explain your product’s value, the product is not ready. Build until the experience is so obviously better that users become your marketing department. Free tiers should be genuinely useful, not crippled demos.
At every stage: Build custom intelligence for your domain. Do not be an API wrapper. Foundation models are commodities. Your custom models trained on your domain’s specific workflows are your advantage.
When scaling: Align pricing with value delivery. Usage-based pricing for AI features is a signal of confidence in your own product. If your AI delivers real value, you should be willing to price it based on how much value it delivers, not on a flat subscription that averages out the power users with the casual ones.
Where you should exercise caution
One caveat worth naming: playbooks extracted from hypergrowth stories are seductive precisely because the outcomes are so clean. Cursor’s decisions look inevitable in retrospect, but each one carried real risk that happened to break their way.
Forking creates a dependency on an upstream project you do not control.
Serving power users first means saying no to revenue from a larger, easier market while you burn cash.
Product-led growth with zero marketing spend works until it doesn’t, and you have no distribution muscle to fall back on.
Usage-based pricing can suppress adoption in cost-sensitive segments.
The value of this piece is in the underlying logic: choose depth over breadth, align your architecture with your differentiation, and price to the value you deliver. When the logic fits your context, the decisions follow naturally. When it doesn’t, copying the moves will hurt you.
The Number That Matters Most
Here is the data point I keep coming back to: Copilot has 20 million users. Cursor has 1 million. Cursor makes 4x the revenue. Depth beats breadth. Power users beat mass users, integration depth beats surface-level convenience, a fork beats a plugin.
Every founder I talk to worries about total addressable market. The Cursor story says the opposite: worry about depth of value per user. The market follows the product.