Base44 in Practice: How Claude Code Powered Rapid Scaling from 1 to 80 People

From Solo Developer to an 80-Person Team

At an Anthropic talk, Yoav, product lead at the vibe coding platform Base44, and Gabriel, its AI team lead, shared a story that's emblematic of team scaling in the AI era: growing from a single founding engineer all the way to an 80-person engineering team, with Claude Code playing the key role of an "efficiency amplifier" throughout.

What is vibe coding? Vibe coding is an AI-assisted software development paradigm that emerged around 2024, popularized by figures like Andrej Karpathy. Its core idea is to describe intent in natural language and let AI generate the code, enabling developers—and even non-technical users—to build software in a "feel-based" way rather than writing it line by line. The foundation of this paradigm is the breakthrough progress of large language models in code generation. After 2023, models like GPT-4 and Claude 3 achieved pass rates above 85% on code benchmarks such as HumanEval, making the loop of "describe a requirement → generate runnable code" a reality in actual products. HumanEval is a standard code-generation benchmark released by OpenAI, comprising 164 function-level programming problems; the pass@1 metric (passing on the first generation) is the industry standard for measuring a model's coding ability. Early GPT-3 had a pass@1 close to zero, while GPT-4 and Claude 3 have surpassed 85%, meaning the vast majority of everyday programming tasks can be completed by AI in a single shot. Software development has thus undergone a paradigm shift from "precise instructions" to "intent expression": in the past, developers had to master syntax, API call paths, and edge conditions precisely, whereas now they only need to clearly express business goals, leaving AI to translate intent into executable code. The deeper significance of this shift is that the "cognitive barrier" of software development has dropped from mastering precise syntax and API call paths to being able to clearly articulate business intent—that is, from the programmer's "declarative thinking" to the product manager's "goal-oriented thinking." This also explains why the user base of vibe coding platforms is no longer limited to professional developers but extends to product managers, designers, entrepreneurs, and even domain experts: the core bottleneck of programming ability has shifted from "technical execution" to "requirement articulation." Base44 is precisely the productization of this trend—it packages AI code-generation capabilities into a visual interface, enabling product managers, designers, and entrepreneurs to directly build runnable applications.

Base44 is a platform that lets both technical and non-technical users build software. Not long after founder Maor launched the project, he had a usable product, and by "building in public" on LinkedIn and Twitter, he accumulated a large following. After the product became profitable, Yoav joined the team. With its profitability, AI-oriented user base, and a founder with exceptional execution, Base44 quickly attracted the attention of many companies and was ultimately acquired by Wix.

The entire scaling journey is broken down into two phases: from 1 to 15 people, and from 50 to 80 people. And the core methodology running through it all can be summed up in a single phrase: keep it simple.

Phase One: The Four Challenges of Scaling from 1 to 15

After the acquisition, Base44 needed to scale rapidly while maintaining speed, growing from a two-person squad to a 15-person team. They faced four problems that couldn't scale linearly: onboarding new hires, code review, product quality validation, and quickly getting up to speed on a vast product surface.

Solving Onboarding with Two Prompts

Faced with the onboarding challenge, the team didn't build complex onboarding docs or nightly update pipelines. Instead, they chose a minimalist approach: every new engineer just uses two prompts before starting work. The first has Claude traverse all commits to generate an organizational map of "who's responsible for what." The second, before diving into a particular module, has Claude draw a mermaid diagram illustrating how that component works.

About Mermaid diagrams: Mermaid is a text-based diagram generation language. Developers can describe flowcharts, sequence diagrams, class diagrams, and more using concise Markdown-like syntax, and the tool automatically renders them into visual graphics. It's widely integrated into platforms like GitHub, Notion, and Obsidian, letting you generate technical architecture diagrams without specialized drawing software. Mermaid's design philosophy embodies the "Diagrams as Code" concept: bringing architecture documentation into version control so it evolves in sync with the code, rather than becoming a separately maintained static file. This characteristic fits perfectly with the needs of AI-assisted documentation generation—Claude can generate accurate architecture diagrams based on the latest code state at any time, rather than relying on possibly outdated manually maintained docs. Having Claude generate Mermaid diagrams means new engineers get a component-relationship diagram that can be rendered in a browser at any time, offering both readability and maintainability.

The elegance of this approach lies in its real-time nature—you don't need to bother maintaining docs that constantly go stale; Claude generates them for you on the fly based on the latest codebase. One prompt gives a new hire all the understanding they need to start working.

The capability boundary of Claude Code: Claude Code is a command-line AI programming assistant from Anthropic that lets developers invoke Claude models directly in the terminal environment to handle coding tasks, including code generation, refactoring, debugging, and codebase analysis. Unlike IDE plugins such as GitHub Copilot, Claude Code emphasizes deep understanding of the entire codebase and the ability to autonomously execute multi-step tasks. It supports reading local files, running commands, and calling external tools (via the MCP protocol), and is regarded as one of the representative tools of "agentic programming."

So-called "agentic programming" means AI no longer passively responds to a single query, but can autonomously plan multi-step tasks, invoke tools, and dynamically adjust strategy during execution—more like a junior engineer capable of completing tasks independently, rather than a query system that only answers single questions. Achieving this paradigm depends on "Tool Use" capabilities: the model can not only generate text, but also select and invoke external tools as needed—file systems, terminal commands, API interfaces, and so on—and incorporate the tool's returned results into its next step of reasoning. From an architectural standpoint, the core of an agentic system is the "Plan-Act-Observe" loop: the model first decomposes a complex task into a sequence of subtasks, executes them step by step, and uses each step's result as context for the next, until the final goal is achieved. This is fundamentally different from the traditional "single query, single response" mode. Claude Code's distinctiveness in this paradigm lies in its "global codebase awareness": by reading the project structure, analyzing Git history, and calling terminal commands, it can work like an engineer who truly understands the entire codebase, rather than giving suggestions based only on the current file fragment. It's precisely this global codebase awareness that enables it to handle tasks requiring cross-file understanding, such as "traversing all commits to generate an organizational map."

Using Claude to Replicate the Founder's Code Review Ability

Founder Maor was extremely cautious about code entering the Base44 backend and Agent, insisting on personally reviewing every PR. To amplify his review capacity, after accumulating a week or two of PR comments, the team had Claude analyze this historical feedback, distill the most critical points, write them into instructions, and run them periodically—resulting in a "Maor avatar" PR reviewer, all without building any complex process.

The results were immediate. The case the team remembers most vividly was the WhatsApp integration feature: it involved third-party integration, an agentic flow, and Meta's new API, originally estimated to take one to two weeks. Instead, a new engineer completed onboarding with those two prompts on Thursday night, and by Sunday morning the feature was ready. The PR review had only two or three minor comments, and it shipped to production right away.

Quantifying User Frustration with the Haiku Model

How do you ensure that the product (especially the Agent) truly serves customers in production? The team abandoned the common approach of investing heavily in a complete eval suite (too costly for a 15-person team) and instead leveraged the vast amount of production traffic they already had.

They observed a simple pattern: when everything works, users stay silent and move straight on to the next feature; but the moment something breaks, users frequently complain in the conversation that a feature doesn't work. That's an extremely strong signal. So they used the lightweight Haiku model to classify each message and gauge the level of user frustration.

Why choose Haiku over a more powerful model? Haiku is the lightweight, fast, low-cost model in Anthropic's Claude family (contrasted with the more powerful but more expensive Sonnet and Opus). For high-frequency, large-scale classification tasks in production, using Haiku is a classic cost-optimization strategy—sacrificing some reasoning depth in exchange for millisecond-level latency per call and extremely low token costs. This design reflects the core principle of "matching model capability to task complexity" in AI engineering: determining whether a message contains frustration doesn't require top-tier reasoning ability, but it does require handling a massive volume of concurrent calls. In real engineering decisions, this kind of tiered selection (model tiering) can produce order-of-magnitude cost differences—priced per million tokens, Haiku typically costs 1/10 to 1/20 of Opus, while for tasks like sentiment classification, the accuracy difference between the two is often under 5%. It's worth noting that "model tiering" is not merely a cost-optimization technique but one of the core decisions of system architecture design: in a complete AI system, routing different tasks to capability-matched models—from simple text classification and intent recognition (well-suited to the Haiku level) to complex multi-step reasoning and code generation (requiring the Sonnet/Opus level)—not only lowers costs but also optimizes overall system latency, since lightweight models typically respond 3–5 times faster than flagship models. Mistakenly using Opus for simple classification creates enormous hidden cost waste in scaled production, while using Haiku for tasks requiring deep reasoning causes accuracy to drop.

Each time a new version of the Agent is released, they first give it to a small subset of users and track the frustration metric—whether the change is to infrastructure, prompts, or the model, they can validate its effect.

Phase Two: From 40 to 80 Overnight

With more external hiring, internal transfers from within Wix, and even the merger of another vibe coding product, the team doubled from 40 to nearly 80 people "in one night." Gabriel narrated the three new challenges of this phase: scaling experiments, a stronger evaluation system, and the scalability of QA.

Distilling A/B Testing Guidelines from Past Experiments

The difficulty of scaling experiments is this: you can't expect every new hire to know which KPIs to test, how long to test, or when it's safe to just ship boldly. The team wanted to "shift left" product management decisions into the development workflow.

Their goal: when a PR is ready, a process runs automatically, and a bot comments on GitHub—whether it can be shipped directly, rolled out gradually, or needs an A/B test; how long to test; which KPIs to monitor—and automatically starts the experiment in PostHog. The shell is easy to build; the hard part is the underlying judgment logic, and the team had never explicitly codified these "product instincts."

Once again, they chose not to hold meetings: they fed the last 100 experiments on PostHog and their corresponding PRs into Claude Code (connected via the PostHog MCP), and had Claude distill a first version of the guidelines.

Technical background on PostHog and the MCP protocol: PostHog is an open-source product analytics platform offering user behavior tracking, A/B testing, funnel analysis, and more, favored by startup teams for its self-hosting capability and complete data ownership. Compared with SaaS product analytics tools like Mixpanel and Amplitude, PostHog supports fully self-hosted deployment, allowing companies to keep user behavior data on their own infrastructure and avoid third-party data leakage risks—particularly important for AI product companies handling sensitive user behavior data. MCP (Model Context Protocol) is an open protocol proposed by Anthropic that allows AI models to connect to external data sources and tools through a standardized interface—essentially giving AI a "plugin bus." Its core design idea is to decouple "tool capabilities" from "model capabilities": any data source or service only needs to implement an MCP server to be callable by any MCP-supporting AI model, without developing separate integrations for each model. From a broader perspective, the MCP protocol represents an important step for the AI tooling ecosystem to move from "fragmented integration" to "standardized interconnection"—before MCP, each AI tool's integration with external systems required custom development, producing large amounts of repetitive "glue code." MCP, by defining unified specifications for service discovery, capability description, and invocation, enables the tool ecosystem to be plug-and-play like a USB interface. Through the PostHog MCP, Claude Code can directly read historical experiment data, eliminating the intermediate step of manually exporting data and pasting it into the model, achieving real-time connectivity between AI and business data. This "AI directly connected to business data sources" pattern is becoming a foundational architectural paradigm for enterprise AI workflows.

The results were quite good—not perfect, but within a few hours they had an iterable working document. Some features are worth testing for 7 days; others need a full month because they might slightly affect conversion and payment rates. Finally, they used Base44 itself to build a central dashboard connecting BigQuery, PostHog, and GitHub, so everyone could see at a glance which experiments were running, how they were performing, and whether they were driving up AI costs.

Building a User Simulator for Realistic Evaluation

At 80 people, evals finally became something "worth investing in," but they still needed to be quick and simple, without tying up top AI engineers for months. The team realized that what they really needed wasn't to evaluate model output, but to verify whether the apps users built actually ran correctly.

The key insight: when a user requests an app and a small part of it doesn't work, that doesn't mean the eval failed—the evaluation suite should feed the "rejection" back so the Agent can fix the missing part. Ultimately, they built a user simulator plugged into the CI/CD pipeline: any change to AI code spins up a real Base44 instance, uses Stagehand to simulate real user actions, and simultaneously observes latency, number of interaction turns, cost, and credits consumed.

Stagehand and the paradigm shift in AI-driven testing: Stagehand is an AI browser automation framework developed by Browserbase, layering AI comprehension on top of traditional automation tools like Playwright, allowing user actions to be described in natural language (e.g., "click the sign-up button and fill out the form") without manually writing selectors and assertions. The biggest pain point of traditional E2E testing is that UI changes cause selectors to break, requiring constant maintenance—especially fatal in fast-iterating AI products, where the interface may undergo structural changes every few days. Stagehand uses a vision-language model (VLM) to understand page screenshots and locate elements semantically rather than by DOM structure: the VLM turns a page screenshot into semantic understanding ("this is a blue primary action button at the bottom of the form") instead of relying on brittle CSS selectors ("#submit-btn-v2-mobile"). A button's visual semantics tend to remain stable across iterations, while its DOM structure may frequently change due to front-end refactoring, making semantic localization far more stable than the traditional selector approach. Plugging this into the CI/CD pipeline represents a paradigm shift from "testing code logic" to "testing user experience"—every code commit automatically triggers a testing agent that simulates a real user, rather than merely verifying whether function inputs and outputs match expectations. The deeper significance of this model: when a software's core logic is dynamically generated by AI, traditional unit and integration tests lose their stable "test anchors," and end-to-end user behavior simulation becomes the only reliable means of quality validation.

The most classic eval is the "Hello World" smoke test, and interestingly, it can pass on the smallest models.

Encapsulating QA Capabilities with Skills

For a consumer product, how do you do QA well without linearly increasing the number of testers? The team knew Claude Code could operate a browser (there are plenty of tools—Playwright, MCP, browser use, etc.), but they were missing a key piece—each time it had to relearn the platform's selectors, flows, and which events to check in the database and Mixpanel.

So they encapsulated common flows into Skills. Skill encapsulation is a modular design pattern in Agent engineering: a series of complex operation sequences and platform-specific knowledge (such as specific selectors, API call paths, and database field names) are pre-written as structured instructions for the AI Agent to reuse when executing tasks, without having to learn the context from scratch each time. In essence, it makes an expert's tacit knowledge explicit—turning the "what's this button's selector, which database table to check, which events this action triggers" that once existed only in an engineer's head into a structured instruction library the AI can directly reference. From a technical architecture perspective, Skills are essentially a "context compression" mechanism: the Agent's context window is limited, and exploring the platform environment from scratch each time consumes many tokens and introduces errors; precompiled Skills, by contrast, give the Agent an "expert domain memory," enabling it to enter an effective operating state directly without repeated trial and error. This closely resembles the "function encapsulation" concept in software engineering, but the object of encapsulation extends from "code logic" to "operational knowledge"—it includes not only what to do (what), but also how to correctly execute in a specific business context (how in context). The Skills mechanism resolves a fundamental tension in Agent engineering: a general-purpose AI model possesses broad world knowledge but lacks the specialized knowledge of a particular business environment (such as internal systems' field naming conventions or a specific team's testing standards). By encoding this kind of knowledge into reusable Skills, the team is effectively building an "organizational knowledge base," enabling the AI Agent to act like a veteran employee who understands the company's internal conventions, rather than a smart but business-clueless newcomer.

One Skill teaches Claude Code to traverse the main user flows that most features touch; for new features, they trust Claude to figure it out on its own. They also built CLI tools to abstract the API and database, specifically for setting up test environments—for example, overriding the database config to test edge cases like "a user on a specific subscription tier approaching their credit limit." Ultimately, all these efforts were consolidated into a "how to do QA well" meta-Skill. The moment a PR opens, the Agent triggers, generates a test plan, sends it to the Base44 app, begins testing, and reports back with screenshots, covering about 80% of scenarios. When it runs into something beyond its reach, it proactively flags the missing capabilities.

The Four Core Methodologies Running Throughout

Gabriel closed by summarizing four shared ideas, valuable for teams of any size:

First, treasure simplicity. Pursue "bold but simple," deliberately not building complex systems before the time is right. Evals are a prime example—they waited until the right scale before going all in.

Second, taste can be encoded. "Taste" is often seen as humanity's last moat against machines, but by analyzing behavioral data such as historical PR comments and past A/B experiments, you can distill a substantial portion of a team's decision-making instinct into executable guidelines. The deeper logic of this insight: an expert's "intuition" is often a compressed expression of a large number of past decision patterns, and these patterns can precisely be refined and reconstructed by AI through historical data. Cognitive science calls this kind of knowledge "procedural knowledge"—it's hidden in behavior sequences, hard for the expert to directly articulate, yet it can be reverse-engineered by observing behavior patterns. The advantage of large language models in this "compress and reconstruct behavior patterns" task stems from their exposure to vast numbers of human decision cases during pretraining, forming an implicit understanding of "high-quality judgment": when you feed 100 historical PR comments into Claude, the model isn't just recognizing textual patterns—it's reconstructing the reviewer's hierarchy of value priorities. It's worth noting that this "taste encoding" is not meant to replace human judgment, but to upgrade human judgment from "reinventing the wheel each time" to "making incremental decisions on top of an AI-distilled baseline"—the PR review bot won't replace Maor's judgment, but rather filters out 95% of the mechanical check items, letting Maor focus his limited attention on the edge cases that truly require high-level judgment. This model reveals an efficient division of labor in human-machine collaboration: AI is responsible for systematically executing historical best practices, while humans handle novel problems that have never appeared in history.

Third, use your own product (dogfooding). Base44 repeatedly "ate its own dog food" in its experiment dashboard, evaluation tools, and QA processes, gaining a fast-iterating feedback loop from it.

Fourth, the bottleneck keeps moving. After solving the current problem, a new bottleneck emerges—for example, how to do "post-launch validation" well: once a PR goes into production, how do you automatically confirm it actually moved the right business metrics, rather than having people keep watching manually?

Base44's set of practices offers a pragmatic reference point: today, when AI tools are powerful enough, small teams can absolutely use minimalist prompts and workflows to leverage the kind of scaling that once required extensive processes and manpower—provided they resist the urge to complicate everything.

Key Takeaways