The two bugs we inherited by cloning, and what they taught us

The CRM had been running a builder's business for months without a complaint. We copied it for a landscaper, pointed it at a fresh database, and the first test lead refused to save.

Bug one: the migration that did nothing

A migration is a small file that changes the shape of a database: add this column, create that table. They run in order, and the list of which ones have run is the database's record of its own history. On a healthy project, the files and the database agree.

The builder's CRM had a migration meant to add two columns to the leads table: the lead's score and its tier (hot, warm, cold). At some point the production database had received those columns by hand, so when the migration file was later written, it would have failed on a database that already had them. Somebody did the practical thing: emptied the file to a comment so the migration would run cleanly and the history would stay tidy. On the original it was harmless. The columns existed, the file said it had run, everyone moved on.

The clone ran the same files against a new, empty database. Every migration reported success. The history looked perfect. And the leads table had no score column and no tier column, so every attempt to save a lead failed, because the code reasonably expected them to be there. The symptom was total. The cause was a file that looked like it had already done its job.

Bug two: every lead was hot

The second one did not break anything, which is worse. Lead scoring adds points for things that suggest a lead is worth chasing: a budget, a timeline, a phone number, a specific project. The builder's rules had grown over time, and the points for simply filling out the website form had crept up to the point where a plain form fill hit the maximum. Every website lead arrived labelled hot.

On the builder's side nobody noticed, because website leads were a small share of the whole and the team called every one of them anyway. For a landscaper whose leads mostly come from the website, a scoring system where everything is hot is a scoring system that says nothing. We only caught it because we were rewriting the rules for the new trade and sat down to total the points.

What a clean copy really copies

A fork is an exact copy of the code and every decision ever made in it, including the shortcuts. The original keeps working because it carries its own history, with the hand edits and the slowly drifting rules already baked into its database and its habits. The copy starts from zero and asks the files to be literally true. That is the trap: the better the original has been running, the more of its quiet accommodations are invisible until a fresh start exposes them.

• A placeholder migration is invisible until a database is built from scratch.
• A drifting scoring rule is invisible until someone totals it by hand.
• A setting that only exists in the original's hosting account is invisible until the copy tries to send its first email.

The checks we added

1. Build a fresh database from the migrations before trusting them. Not against a backup of the original, against nothing. If a column the code uses is missing afterward, a migration is lying.
2. Insert a test lead on the live preview as the first act. Before any styling, before renaming a single field. A lead that saves proves the core; a lead that fails points straight at the layer that matters.
3. Score a plain form fill and look at the number. It should land somewhere in the middle. If it is hot, the rules are broken no matter how reasonable each one looks.
4. Rewrite scoring per industry, from a conversation, not from the previous client's rules. What makes a lead hot for a builder is not what makes one hot for a lawn crew or an advisor.
5. List every setting the original holds outside its code, and recreate each one deliberately. Email passwords, service accounts, secret keys. The copy inherits none of them.
6. Go back and check the earlier clones. The advisor's CRM was copied from the same source before we found the migration, so it went on the list to verify.

What it taught us

Cloning is still the right move. The landscaper and the advisor got months of fixes on day one. But a working original is evidence that the system works for the original, not that the files describe it truthfully. The copy is the audit. Now we treat the first day of every clone as a test of the source, and the source is usually the thing that gets fixed.

Both bugs are now fixed in the copies and written into the checklist we run every time a proven system becomes someone else's, which is how most of the CRMs and internal tools we deliver begin.

Questions people ask