Skip to content
Insights · Field notes

Draft-first is not a courtesy

Two separate incidents—one on a law firm homepage, one on a dental redesign—converged into a single non-negotiable: for sensitive-industry clients, draft-first delivery is not a politeness. It is the only safe delivery model.

Two incidents. Different engagements. The same lesson.

The first was a law firm homepage redesign. The brief was explicit: build the new homepage in WordPress draft status, keep it closed to indexing, and hold for agency sign-off before any page goes live. Standard arrangement for legal clients, where every statement on a homepage—case-result framing, jurisdiction language, attorney-advertising disclaimers—carries compliance weight. During QA before handoff, we found the page had been accidentally published. It was live. We rolled it back immediately, and no review had gone out from the agency’s side yet, so the exposure window was short. But we ran the thought experiment: if the agency’s review cycle had been two days later, a half-built homepage for a law firm would have been publicly indexed before anyone with approval authority had seen it.

The second was a multi-page dental redesign. Early in the homepage build, a developer modified a Divi module that was scoped to the new homepage—but the module was pulling from a global template scope that propagated the change across the entire live domain. Every page broke. We had a fifteen-minute backup, and we used it. Total recovery time was under an hour. But from that point forward, every build on that engagement ran out of a cloned test environment that was completely isolated from the live domain.

Two incidents. Two different failure modes. One common factor: the assumption that working on a live WordPress canvas, even carefully, carries acceptable risk for sensitive-industry clients.

It does not.

After these two projects, draft-first delivery moved from an implicit preference to an explicit, Redmine-tracked protocol on all redesign engagements for legal, dental, and financial clients. The agency principal’s post-build review became a named sign-off requirement in the ticket itself—not a casual walkthrough, but a documented approval event, dated and recorded, before a single page transitions from draft to published. Test-environment-first became mandatory on any engagement where a page builder’s global scope could propagate a change across a live domain without a confirmation step.

This costs something. There is setup time for the test environment. There is the overhead of a tracked sign-off round. There is the extra coordination of keeping draft pages synced with the direction of the live site during a long build.

That cost is not overhead. It is what you bill for.

For a law firm, a healthcare practice, or any client operating in a regulated space, the homepage is not a marketing asset you can adjust after the fact. It is a published statement with legal weight. A build partner who works directly on a live Elementor or Divi canvas—regardless of their skill level—is one accidental global-style override away from publishing something that the client’s compliance team has not approved. The process gate does not slow the build down. It is the build.

If your current dev partner does not have a formal draft-first protocol for sensitive-industry redesigns, that is worth asking about before the next engagement starts.

— Working on something similar?

If any of the above sounds familiar, we should talk.

Scroll to Top