How to Run a 20x Startup: 9 Practices We Use With Claude Code

A 20x company beats rivals 20 times its size. It does this with a small team and relentless automation. We are that company. At lowtouch.ai, we ship enterprise software with 2 engineers. Each sprint takes about half a day, not two weeks. This post shows you exactly how we do it.

These are not aspirational ideas. They are the 9 steps we follow every day.

Here is what each step looks like in practice.

---

Step 1: Set Up Claude Code in WSL Sandboxes

The foundation matters. A bad setup slows everything down.

We run Claude Code inside WSL (Windows Subsystem for Linux) on Windows. VS Code connects to WSL using the Remote extension. Each project lives in its own WSL sandbox. This keeps projects isolated and avoids dependency conflicts between them.

Open multiple WSL terminal windows to run tasks in parallel. Each window can run a separate Claude Code session. One engineer can drive two or three workstreams at once. This is how a small team moves at the pace of a large one.

Keep your CLAUDE.md file under 5,000 characters. Here is why it matters: context usage grows quickly with file size. A 10,000-character CLAUDE.md can push token costs up significantly across a long session. Output quality also drops as Claude Code tries to process a large instruction set on top of actual code. A tight CLAUDE.md with the stack, brand rules, and key constraints is better than an exhaustive one.

Tip: Use section headers in CLAUDE.md and put the most critical constraints at the top. Claude Code reads the whole file, but clear structure helps it apply the right rules at the right time.

---

Step 2: Let Pre-Sales and Product Create the PRD

Most teams waste engineering time on the wrong problem. Engineers write PRDs. Engineers build prototypes. Engineers sit in product discovery calls. That needs to stop.

Train your pre-sales and product teams to use Claude.ai on the web. They can create a full product requirements document and a clickable mockup without writing any code. We also use Claude Design for interactive prototypes. Note: Claude Design is in beta. Quota can run out mid-session. Do not rely on it as your only prototyping tool.

Once the customer approves the design, the product team commits the PDF and mockup to their own Git feature branch. Engineering never receives a vague email. They get a customer-approved spec with a commit hash and a review trail.

This one change removes the biggest source of miscommunication in software projects. Engineering does not start until the customer has already said yes to the design. No surprises at demo day.

---

Step 3: Solutions Architect Adds the Engineering Layer

A PRD tells you what to build. A solutions architect figures out how.

The SA uses the ARCHITECT skills in Claude Code to review the PRD. They generate a solution.md file. This file covers system design, data models, API contracts, integration points, and key risks. It is written in plain language that both engineers and product managers can read.

The solution.md file is added to the project's CLAUDE.md as a referenced document. Now every Claude Code session an engineer opens already knows the architecture. The SA is the bridge between what the customer approved and what the engineers build. This step prevents the most expensive kind of waste: building the right feature the wrong way.

---

---

Step 4: Claude Code Writes the Sprint Plan

Once solution.md is ready, it is time to plan the work.

Open Claude Code in the project. Give it this prompt: "Plan this work for a team of 2 engineers in 2-week sprints. Reference solution.md and the PRD. Output a sprint.md file." Claude Code reads both documents, breaks the work into tasks, estimates effort, and sequences the dependencies. The output is a complete sprint.md.

The PM reviews the draft. They check that task descriptions are clear and the scope is realistic. They adjust priorities where needed. The SA checks that the technical sequencing is correct and that no dependencies were missed. They make edits together. The result is a sprint plan that the whole team can act on without a kickoff meeting.

---

Step 5: SA Approves and Locks the Plan

This step is a gate. Engineering does not start until it is cleared.

The SA does a final review of sprint.md. They verify that the sprint tasks match solution.md. They check for technical gaps and adjust the sequence if anything is out of order. When they sign off, solution.md and sprint.md become locked. Changes after this point require a new review.

Locking the plan sounds like overhead. It is not. It is the fastest way to prevent the most common failure mode in startup engineering: building the right feature in the wrong way, then discovering it at demo day. Thirty minutes of SA review before engineering starts saves two weeks of rework after.

---

Step 6: Engineers Execute One Sprint at a Time

This is where the numbers get surprising.

A traditional 2-week sprint takes 2 weeks. With Claude Code, the same scope of work takes about half a day. We have seen this consistently across dozens of sprints. Engineers open Claude Code, point it to the current sprint tasks in sprint.md, and iterate using the BUILD, QUALITY, and SHIP skills in a loop.

The loop works like this: build a feature, run the quality check, fix issues, commit and push, move to the next task. The QUALITY skills catch most code issues before the PR review. Engineers review the output, approve what is right, and redirect what is not. They are making judgment calls and architectural decisions, not writing boilerplate.

The half-day figure deserves a note. Complex integrations with poorly documented third-party APIs can take longer. But straightforward feature work, API development, and UI component builds consistently compress to a fraction of the traditional time. The key is a clean sprint.md and a well-structured solution.md. Vague inputs produce vague outputs, with Claude Code or any tool.

---

Step 7: Daily Standup is 30 Minutes

Long standups are a sign that the team is not working from a shared source of truth. Our team has one.

The standup covers 2 to 3 sprints of completed work. Everyone reviews working software in the staging environment. Not slides. Not status reports. Real software running in front of the team. If something does not match the expected behavior from solution.md, it gets flagged right away. The meeting ends with one decision: ship it or keep iterating.

Thirty minutes is enough because everyone reads sprint.md and solution.md before the meeting. They already know what was planned. The standup is a check on how close the software is to the plan, not a discovery session.

---

Step 8: QA Testing With Claude and the Chrome Extension

Testing is not a bottleneck in this workflow. It is a checklist that Claude Code helps write.

The QA engineer uses Claude Code to generate a test plan. The inputs are sprint.md and solution.md. The output is a test-plan.md file. It covers the happy paths, edge cases, and regression areas for the current sprint. There is no manual test design from scratch. The test plan comes directly from the requirements documents everyone already agreed on.

The team uses the Claude Chrome extension to execute tests against the staging environment. Test results go into a results.md file. That file is committed to Git. Engineering leads review it the same way they review a pull request. Everything lives in the repo. Nothing is stored in a disconnected spreadsheet or someone's head.

---

Step 9: Go Live and Sanity Check

The standup ends with a decision. If the decision is "ship it," the PR is merged. The merge triggers the deployment pipeline automatically.

After the build completes, the team runs a quick sanity check using Claude Code and the Chrome extension. They verify the key user flows still work in the live environment. This takes under 15 minutes. Any issues are logged as new GitHub issues or PRs immediately. Nothing waits until the next sprint to be acknowledged.

After shipping, the team does one more thing: they update sprint.md to mark the sprint complete. This keeps the source of truth accurate. It also gives the SA a clear view of what shipped, which feeds directly into the next planning cycle.

---

What This Achieves

Two engineers. Half a day per sprint. Thirty-minute standups. No long planning meetings. No waterfall handoffs between teams.

Customer-approved features go from PRD to production in days. The model works because each role does what it is genuinely best at. Pre-sales and product handle the customer conversation. The SA handles technical design and the quality gates. Engineers handle code judgment. Claude Code handles the volume of execution that would otherwise require a much larger team.

This is what the 20x model looks like in practice: a small team that ships faster than a company 20 times its size, because every step is tight, documented, and automated.

Metric	Traditional	20x Model
Sprint duration	10 working days	0.5 days
Daily standup	60 to 90 minutes	30 minutes
PRD-to-code handoff	Slack/Confluence	Git branch + customer sign-off
Test documentation	Spreadsheet or none	MD files in repo
Post-live sanity check	Manual, ad hoc	Claude Code + Chrome, 15 min
Team size for same output	10 to 20 engineers	2 engineers

---

If you want to understand the broader 20x company concept, read The Rise of the 20X Company. To bring this model to your enterprise team with SOC 2 Type II controls and private-by-architecture deployment, talk to the lowtouch.ai team.

---

Rejith Krishnan is the Founder and CEO of lowtouch.ai, a private agentic AI platform for enterprises. lowtouch.ai is SOC 2 Type II and ISO/IEC 27001:2022 certified.