Shipping a SaaS in three weeks with Claude Code: our setup, our numbers, our mistakes

Claude Code alone is not enough to ship fast. What creates speed is the framework around it: written rules, detailed tickets, clear roles, real acceptance testing, and a human who decides about production. Here is how a small TIC-NOVA team goes about it, with its numbers, its limits and its mistakes.

The context

A small team, one lead who is also the product owner and three developers, built a complete B2B business SaaS for a first customer: an API, a web back office, a public website and a mobile app. The work is split across several Claude Code sessions running in parallel, supervised by a “lead dev” session.

For confidentiality reasons, we name neither the customer nor the product, and the examples in this article are generic.

The numbers, and their limits

Over three weeks, from 6 to 27 October 2026, we measured in the repository and the ticket tracker:

• about 680 commits on the main development branch;
• nearly 300 merge requests merged in 9 days, or 30 to 35 a day;
• nearly 100,000 lines of code added and about 29,000 removed, across about 1,100 files;
• 23 versions delivered, from 0.0 to 0.16;
• more than 600 tickets tracked, and 4 applications covered.

These are activity measurements, not proof of a productivity gain. We have no “before and after” comparison and no control team working without Claude Code, and the number of lines of code does not measure value. What counts, and what can be seen: the delivery cadence, the number of versions, and the fact that acceptance testing on a real environment keeps up.

The ten practices that move things along fast

1. A short, versioned CLAUDE.md file. A page and a half, in the repository, read by every session. It says where the truth lies and in which order to consult it, the code rules in ten lines, the Git and continuous integration rules, and the prohibitions: pushing to main branches, changing CI variables, running a migration in production, disabling a test. Every new session starts within the same framework, and the file is updated through a merge request like any other.

2. A ranked source of truth. Decisions are written in a dated file. When two documents contradict each other, the order of priority settles it: Claude does not have to guess what was decided, and neither do we three weeks later.

3. We complete the ticket, not the prompt. A ticket describes a precise task: the files concerned, the steps, the expected tests. If the ticket is not enough, we complete it. Any session can then take any ticket, and the work stays traceable.

4. Mockups as a starting point and as the acceptance reference. We code from the mockup, not from the old page. Acceptance testing compares the real screen with the mockup, side by side, at two widths. A feature that is mocked up but missing is a defect, not a suggestion.

5. A “lead dev” session that orchestrates. This is the practice that changes speed the most. The lead dev session distributes tickets, reviews merge requests, merges them when continuous integration is green and prepares releases. It hardly codes at all. Peer sessions take a ticket or a batch of tickets, code it, test it and open the merge request. Acceptance sub-agents test the deployed result as a user would.

6. One working folder per session. Each session works in its own isolated Git folder: no conflicts between sessions, no branch changing under your feet. These folders are heavy, with their installed dependencies. On this project, around a hundred folders took up several tens of gigabytes and we had to clean up urgently. Plan regular cleanup from the start.

7. Safeguards that do not depend on goodwill. Permissions are set by the project: what Claude may do without asking, what it must ask. A forced push to a shared branch was refused automatically. A human gives the “go” for production, every time. Test data in production is prefixed and then deleted, and no secret is displayed or stored.

8. Persistent memory. Claude keeps small memory files, one fact or one rule per file: how acceptance testing is done, who is assigned to what, what was decided yesterday. A new session does not start from zero and the same mistakes do not repeat.

9. Automated acceptance testing with real interactions. A browser driven by the test tool, an emulator for mobile, automatic accessibility checks, mockup-versus-real comparison, end-to-end tests. A rule we learned: a test failure is confirmed with a real interaction, a keyboard press or a click, not with a script that forces the element. Otherwise you manufacture false alarms.

10. Conventions that keep the versions turning. Commits follow a conventional format, with the ticket reference. A job reads those commits and creates the version and its number. The acceptance environment is deployed with every version, and production is deployed by hand.

What went wrong

A method that admits no mistakes is not credible. Here are five real ones:

1. Two green merge requests that break the main branch once together. Each passed CI, but a shared type had changed in the meantime. Now, a merge request that touches a shared type is rebased before it is merged, and it is written in CLAUDE.md.
2. False acceptance alarms. A reported “critical bug” was not one: it was the wrong page. Reproduce and confirm before opening a critical ticket.
3. An output-filtering tool that distorted a list, which made a bulk deletion fail. In a script, you do not let a filter rewrite the output.
4. A ticket transition guessed instead of read, by the lead dev session. The ticket ended up in the wrong status, corrected immediately. List the available transitions before transitioning.
5. Continuous integration becoming scarce, for lack of an available runner. Response: group several small tasks into a single merge request, one commit per ticket, and check everything locally before pushing.

What we do not promise

We promise neither “ten times faster”, nor “no developers”, nor “AI does everything”. That is not our experience. Our experience is a human team that decides, reviews and keeps control of production, and that uses Claude Code to sustain a high delivery cadence inside a strict framework.

Setting up the same thing in your team

If you want to set up Claude Code on a real team project, with a CLAUDE.md, tickets, sessions and acceptance testing suited to your context, tell us about your project.