Founder Fires Developers and Upgrades CRM with Claude Code: 22 Test Suites

A familiar situation for any founder: the product was built over years, the team had to be disbanded, and the code remained. The author of this story spent several years building a CRM for working with leads in Telegram. When the developers were let go, he was left alone with a system he had not written. He described on Habr how he got out of that position with the help of Claude Code.

What he inherited

The system consists of six services: a React admin panel, a main FastAPI backend with MongoDB and Redis, a background mailing engine, a module for working with live Telegram accounts via Telethon, lead enrichment, and intake of requests from the website. On top of that sit Docker and GitLab CI.

The product logic was also left over from the team. It consists of six blocks: greeting new group members, template-based campaigns, a follow-up message to those who did not reply, intro groups, cold messages, and an analyzer of active members for a personal touch.

There were also unpleasant discoveries. Across all six repositories there was not a single automated test, even though pytest was listed in the dependencies. Three helper scripts contained database passwords. The most serious problem was not in the code: all leads lived in a single MongoDB database, and no copy of it existed. The code can be restored from GitLab, but the data cannot.

How Claude Code worked

The first step was an audit. The GitLab token was read-only, so the original was safe. Claude cloned 10 repositories, read the READMEs, extracted the links between services from env keys and docker-compose, and drew a map of the system.

The second step was unexpected. The author had planned to write a new CRM from scratch, but after the audit the assistant said there was no need: the system was written decently and needed to be hardened. Tests and secrets first, then changes in small blocks.

Third step: a second layer appeared around the old system, built on local SQLite databases with leads, personal correspondence and chats. The lead database now holds about 99 thousand records, and the new layer has 22 test suites.

Fourth step: the assistant and the author found gaps in the product together. All blocks worked only outbound, from the author to the person. There was no scenario for people who came on their own, no "how is this person useful" field, and no date after which a lead card goes stale.

How the process works

The author sets the task in his own words, often by voice. Claude opens a separate session, reads the code and real data, and explains what will change and what might break. Then it writes a small script and tests. The result is additionally reviewed by other models: Codex, Grok and Gemini. The author feels this is more reliable.

All Telegram sends go through safe_send.py, while budget.py calculates limits, usually 5 messages per day per account. At night the CRM maintains itself: it downloads conversations, recalculates which leads are warm, and reminds about promised dates. These are ordinary scripts without an LLM, so almost no tokens are spent and the development runs on a subscription.

Limitations and takeaway

The article is written in the first person and without independent verification. There are no savings figures, only the words "much cheaper." The author himself candidly says that programmers built the product, and AI read it and improved it.

Three things are practically useful. First: before rewriting inherited code, have an agent run an audit and build a service map in read-only mode. Second: tests and a data backup first, then new features. Third: move everything that can work without an LLM into ordinary scripts. That way you pay for AI only for development, not for every nightly job. For small teams and solo founders this is a workable scheme, provided there is discipline and a safety net of tests and limits.