From One Person to 80: Scaling a Hypergrowth Eng Org with Claude Code

1. The Base44 story: from side project to 80 engineers overnight

Base44 is a low-code platform that lets anyone — technical or not — build production software through natural language. Founder Maor Shlomo started building it at the end of 2024, shipped a working product within weeks, built an audience on LinkedIn and X, and was profitable by April 2025.

That trajectory attracted acquisition interest almost immediately. Wix — a company with a very similar user base — bought Base44 for approximately $80 million in June 2025, and then moved fast: within months the team went from two people to fifteen engineers, and later nearly doubled overnight when an entire Wix vibe-coding team merged in, taking the headcount from 40 to nearly 80 in a single evening.

The talk at Code with Claude London 2026 is delivered by Yav (Head of Product) and Gabriel (Head of AI). They split the story into two phases:

• Phase 1 (1 → 15 engineers): The immediate scaling challenges after the Wix acquisition — onboarding, code review, and quality assurance for a suddenly larger team.
• Phase 2 (50 → 80 engineers): A second wave of challenges driven by the team merger — experimentation governance, proper evals, and agentic QA.

The through-line of both phases is a single principle: keep everything elegantly simple, and let AI carry the complexity you would otherwise bake into process.

2. Phase 1 bottleneck 1 — Onboarding that scales without docs

The classic response to onboarding pressure is to write documentation. Someone has to write it, someone has to update it every time the codebase evolves, and new engineers read a version that is already slightly stale. Base44 refused to do this.

Instead, every new engineer gets two tasks to run before touching their first feature:

Prompt 1 — Org map from git history:

“Go over all the commits and tell me what everyone cares about.”

By the time the fourth or fifth engineer joins, the commit history already encodes who owns what, which areas are changing fast, and what the team’s current priorities are. A new engineer sends this prompt and gets a living, real-time map of the organisation — no wiki page required.

Prompt 2 — Component diagram on demand:

“Give me a Mermaid chart of how this component works.”

Because this is generated from the actual current source, it can never go stale. You don’t maintain the diagram; Claude regenerates it whenever an engineer needs it. This maps perfectly to a codebase that is changing every day.

The proof: a new engineer joined on a Thursday, ran both prompts, and by Sunday morning had submitted a complete WhatsApp integration — touching the agentic flow, a new Meta API, and a non-trivial third-party webhook. The team had budgeted one to two weeks for the task.

3. Phase 1 bottleneck 2 — Code review without a bottleneck

Maor (the founder) reviewed every PR himself. He had strong opinions about what should and shouldn’t go into the Base44 backend. That doesn’t scale past a team of two or three.

The typical response is to write a code-review checklist or hold sessions where senior engineers articulate standards. Base44 skipped straight to the source:

1. After a week or two, there was already a meaningful pool of PR comments Maor had written in the repository.
2. They asked Claude to read those comments and distil the most important patterns and rules.
3. That output became the code-review instruction set, refreshed every few days as new PRs accumulated.

The result: multiple engineers could now give PR feedback consistent with Maor’s standards without Maor being in the loop for every review. The instruction set evolved automatically as Maor’s real comments kept accumulating.

The underlying principle generalises widely: your team’s taste is already encoded in your past actions. Rather than holding a standards committee meeting to articulate it, ask Claude to read your history and surface it.

4. Phase 1 bottleneck 3 — Quality assurance from live traffic

When Base44 was tiny, Maor and early colleagues would sit with customers and watch sessions live. That doesn’t scale. The instinctive replacement is an evaluation suite: write test cases, run them on every release, check whether the agent’s outputs are correct.

The problem: building a proper eval suite is a significant engineering project. A fifteen-person team usually can’t afford it, and pulling top AI engineers off product work to build evaluations would slow down the very product they’re trying to evaluate.

Base44’s solution was to use the traffic they already had:

• When the agent is working well, users say nothing. They just move on to the next request.
• When the agent breaks, users get vocal: “Why isn’t this working? I can’t believe it’s broken.”

This signal is strong, consistent, and available in production right now. They ran a lightweight classifier (a small, cheap model) over every user message to tag it as high or low frustration. Once they had that metric, they could canary-test every agent change:

1. Route a small percentage of users to the new agent version.
2. Compare frustration levels between the canary group and the control group.
3. Roll forward if frustration falls; roll back if it rises.

This pattern works regardless of what changed: model, prompt, infrastructure, or product logic.

5. Phase 2 bottlenecks — When the team doubles overnight

Six months in, the team merged with a Wix vibe-coding group in a single night, going from ~40 to ~80 engineers. New challenges emerged that hadn’t been a problem at 15:

Experimentation governance. At 15 engineers, intuition governed when to A/B test something and for how long. At 80, you can’t expect every new hire to carry that intuition. You need written guidelines — but writing them from first principles would require a committee and a lot of meetings.

Base44 solved this the same way they solved code review: look at past behaviour. They fed Claude their last 100 experiments from PostHog (their A/B testing platform) alongside the matching pull requests, and asked it to distil the guidelines. The output was rough, but it was a working document that could be iterated in hours rather than debated over weeks.

Now every pull request gets a bot comment that answers three questions:

• Can this ship directly, or does it need an experiment?
• If it needs an experiment: how long should it run?
• Which KPIs should it monitor?

Evals. At 15 engineers, the team consciously deferred building an evaluation suite — the ROI wasn’t there yet. At 80, with the AI code surface expanding rapidly, it became essential.

The key insight for their eval design: for a product like Base44, where users are building apps, a single failed step doesn’t mean the eval should fail. The correct signal is whether the system can recover — how many turns does it take to reach a working state, how much does it cost, what’s the latency? They built a CI/CD pipeline that spins up a real Base44 instance on every AI code change and runs a user simulator (using Stagehand for browser automation) against it.

Agentic QA. Instead of growing a QA headcount linearly with engineering, they extended Claude Code with skills: reusable knowledge about the platform’s selector patterns, common user flows, database setup shortcuts, and how to read Mixpanel events. Every pull request triggers an agent that writes a test plan, sends it to a Base44 app (dog-fooding their own platform), runs the tests, takes screenshots, and reports back. It handles about 80% of edge-case QA scenarios; the remaining 20% surface as explicit “I couldn’t test that” notes rather than silent gaps.

6. The philosophy: elegant simplicity and the moving bottleneck

Gabriel closes the talk with four principles that thread through every solution Base44 built:

1. Keep everything simple. Whenever the temptation is to build a sophisticated process, ask whether a simpler one — even a single prompt — could get 80% of the value. The team resisted the urge to build eval suites, onboarding wikis, and committee-driven guidelines at every stage. They built them only when the simple version had clearly stopped scaling.

2. Encode taste from past actions. “Taste” — the intuition of an experienced founder or senior engineer — feels impossible to scale. But it’s already latent in your git history, your PR comments, your past experiments. Claude can read those artefacts and surface the underlying logic. You don’t need to articulate your standards from scratch; you need to point AI at your history.

3. Dog-food your own platform. Base44 used their own low-code platform to build their internal experimentation dashboard, their eval runner, and their QA reporting UI. This creates a tight feedback loop: every time they encounter a limitation while building internal tools, it shows up as a product improvement.

4. The bottleneck will keep moving. Every phase solved the current constraint, and every solution revealed the next one. At 15 engineers the onboarding, review, and QA problems were solved. At 80, experimentation governance, evals, and agentic QA became the new bottlenecks. The right posture isn’t to anticipate every future problem and over-engineer for it; it’s to solve the present constraint simply and stay alert to what surfaces next.

Go over all commits from the past 90 days and summarise:
1. Which files and directories change most often?
2. What are the main areas of concern based on commit messages?
3. Who (by commit author) owns which areas?
Output as a structured list, one area per line.

Read the source files in src/auth/ and give me a Mermaid diagram
showing the main classes, their relationships, and the key data flow.

gh pr list --state merged --limit 50 --json number,title | \
  jq -r '.[].number' | \
  xargs -I{} gh pr view {} --json reviews --jq '.reviews[].body' 2>/dev/null | \
  grep -v '^$' > /tmp/pr-comments.txt

Read /tmp/pr-comments.txt — these are real pull request review comments from our team.
Identify the top 10 most frequently mentioned concerns or patterns.
Format them as a numbered list of code-review guidelines I can add to CLAUDE.md.

Review the staged changes against these team standards:
{{paste guidelines here}}

Flag any violations with file and line number. Be concise.

# Pseudo-code — adapt to your stack
def classify_frustration(user_message: str, client) -> str:
    response = client.messages.create(
        model="claude-haiku-4-5",  # cheap, fast
        max_tokens=10,
        messages=[{
            "role": "user",
            "content": (
                f"Classify the user frustration level in this message as HIGH or LOW.\n"
                f"Message: {user_message}\n"
                f"Reply with only HIGH or LOW."
            )
        }]
    )
    return response.content[0].text.strip()

Read the last 20 merged PRs using `gh pr list --state merged --limit 20`.
For each, read the review comments with `gh pr view <number> --json reviews`.
Compare patterns against our current guidelines in CLAUDE.md.
Suggest any additions or removals. Do not make changes — just report.

Where to go next

• Watch the original talk at youtube.com/watch?v=VueeyKcquoA — Gabriel’s section on evals and agentic QA is especially detailed.
• The Mastering Claude Code lesson covers the agentic loop and memory files that underpin everything Base44 built.
• For the broader conference context, the Code with Claude London 2026 keynote covers how Claude Code adoption is changing engineering at scale across Shopify, Mercado Libre, and Anthropic itself.