Write to production once and you're done. So I built a clone that can't.

Written with Kimi's kimi-for-coding.

There's a production SaaS I only have read access to.

Customers hammer it every day. It's the beating heart of their operations.
And I'm running a PoC where I clone it locally (partly to learn how it's put together).

Now, what's the scariest part of this kind of work?

Accidentally writing to production.

The API you thought was read-only turns out to mutate state.
A drag-and-drop you meant as "just looking" commits to production the moment you let go.
Touch one dispatch sheet and tomorrow's job sites start moving.

Just imagining it makes me want to scream.
I assume you feel the same.

"Be careful with production" doesn't scale

My first conclusion was this.

Relying on human attention to "be careful not to write to production" breaks, sooner or later.
When you're tired. When you're in a hurry. When you assume "it's probably read-only." Every incident comes from one of those moments.

So I turned the policy from a wish into a mechanism.

• Observation is look-only. Even when I open production in a browser, I never trigger a write (a drop = a commit). I take home nothing but the network log: which API returns what shape.
• No real data on my machine. All sample data for the clone is synthetic (a fake), mechanically remapped from real values. Names, vehicle numbers, phone numbers — not a single character of them lands in my repository.
• And the centerpiece: the next one.

Bound by tests, not promises (egress-fence)

Every write path in the clone has a test that verifies it never talks to the outside world.

The trick is simple.
Right before the save logic runs, swap every outbound doorway (fetch, http, all of them) with a trap that throws the instant it's called.
Then run the save and assert two things: it persisted locally, and the trap was never sprung.

If someday someone carelessly adds code that talks to production,
this test goes red and the commit can't land in the first place.

Here's the point.

"Don't write to production" is guarded by a failing test, not by a developer's good intentions.

Good intentions slip past code review.
Red tests don't.
Trust the latter, not the former. That's the whole story.

On top of that, I simply never implemented a "write to production" adapter.
The only write target is the local DB; the path to production does not exist.
Features that don't exist can't have bugs. The strongest wall turned out to be absent code.

"Don't lie" also became a mechanism

It's a clone, so of course parts of it behave differently from the real thing.
Do that sloppily and you get the worst kind of artifact: something that moves plausibly but isn't the original.

So every place where I deliberately diverge from the real system gets one line in a ledger, with a reason.
"Not observed yet." "Real data is 0% so I didn't build it." "Couldn't fabricate it, so preserved as an empty field." I record down to that granularity.
Any "quiet divergence" not in the ledger is a rule violation.

Observe first, implement second.
Don't build what you haven't seen. Don't fill gaps with imagination.
It's humble work, but this is exactly what decides whether the clone becomes "documentation" or "a plausible lie."

What I touched this time: a table where rows were missing

One concrete episode.

There's a table listing dispatch assignments.
The first version of the clone derived its rows (vehicles, drivers) backwards from assigned jobs.
In other words, a vehicle with no work didn't show up in the table. Easy to build, but not how the real one works.

The real one is the opposite: the master ledger is the source of truth, and idle vehicles appear as rows too.
"Which truck is free today?" is visible. That's literally the reason the dispatch table exists.

So this time I added that separate "master" data source to the clone and switched the rows to come from it.
I also split the views: one sorted by vehicle, one sorted by driver.
The interesting part was the merge rule.
Every entry in the master becomes a row, while a job that exists but has no matching master entry is always kept as an orphan row at the bottom.

Not a single record dropped.
Deleting data to make the screen look clean is, in a clone, the same as lying.

I stopped "being careful" and left it all to a feature that doesn't exist

If you're cloning a production system you can only read:

Guard what you care about with tests, not with care.
Record every divergence from the real thing in a ledger, with reasons — don't hide it.
And the most dangerous feature is the one you don't build at all. That's the strongest wall.

Because I never implemented a write adapter, production survived another day.
What doesn't exist can't break anything.