Field notes: the week of September 9, 2026

A client asked us this week to explain why their cost per lead had dropped 40 percent while their revenue stayed flat. That gap is the whole story of the week, and it is worth walking through because it is a mistake almost everyone makes, including people who should know better.

When a good number hides a bad one

The cost per lead fell because we changed the offer on a landing page. The old page asked for a demo. The new page offered a free audit. More people fill out a form for a free audit than a demo, so the raw lead count went up and the cost per lead went down. On a dashboard, that looks like a win.

The problem is that a free-audit lead is worth less than a demo request. Someone asking for a demo has already decided they might buy. Someone taking a free audit is curious. Both are leads. They are not the same lead. When we traced the two groups through to closed revenue, the demo requests closed at roughly three times the rate.

So the 40 percent drop in cost per lead was real, and it was also misleading. We had made the top of the funnel cheaper by pouring in traffic that converted worse downstream. The dashboard rewarded us for doing that. Revenue did not.

We reverted part of the change and kept part of it. The audit offer stays as a secondary path for colder traffic. The demo request goes back to being the primary call to action for people who arrive with intent. The lesson is not "audits are bad." It is that a metric measured in isolation will lie to you with a straight face.

A cheaper lead is only cheaper if it is the same lead. Change what you are counting, and the cost per unit stops meaning anything.

The MCP server change that saved us an afternoon a week

On the software side, we shipped a change to one of our MCP servers, the one that lets Claude read and write inside the project manager. Until this week, pulling a client's task history into a planning session meant a human copying and pasting from the workspace. That is fifteen minutes that nobody enjoys, done maybe twenty times a week across the team.

The server now exposes task state directly, so a planning conversation can ask for the last month of activity on an account and get it without the copy-paste ritual. Two things we learned building it:

• Scope the read narrowly. The first version returned every field on every task, which made the responses huge and slow. Trimming to status, owner, due date, and last update cut the payload by most of its size and made the answers faster.
• Write access needs a confirmation step. We let the assistant propose task updates, but a human approves them before they land. We are not ready to let an automated system silently change a client's project record, and we do not think you should be either.

The point of building our own tools is that we control this trade-off. A vendor would either give us full write access or none. We wanted the middle, and the only way to get the middle was to build it.

A rescue that turned into a rebuild

Earlier in the summer we wrote about how to decide between fixing a site and starting over. This week we hit a case where the decision flipped halfway through.

We took on a site as a rescue. The plan was to fix the page speed, clean up the internal linking, and rewrite the three pages that drove most of the organic traffic. Standard work. Then we opened the theme.

The site was built on a page builder stacked on top of another page builder, with custom CSS overriding both, and a caching plugin fighting all three. Every fix we made created a new problem somewhere else. After two days of this, the honest math changed. Continuing the rescue was going to cost more than a clean rebuild on a maintainable stack, and the client would still be left with a fragile site at the end.

We stopped and told them. Nobody likes hearing that the plan changed in week one, but the alternative is billing for a rescue you already know will fail. We moved the engagement to a rebuild, kept the content work we had already done, and reset the timeline. The client agreed because we showed them the specific conflicts, not because we asked them to trust us.

How we tell the difference now

The signal we missed at the start was the number of layers. One page builder is a choice. Two page builders plus override CSS is a symptom. When we see three or more systems each trying to control layout, we now assume a rebuild is likely and price the discovery phase to find out for sure before we commit to a rescue timeline.

What we told a prospect who wanted guaranteed rankings

A growth-stage company came in this week asking whether we could guarantee a first-page ranking for a specific head term inside 90 days. We said no, and we explained why, because the reason matters.

Nobody controls the ranking. Google does. What we control is the work that tends to move rankings: the content that answers the query better than what is there now, the technical health that lets it get crawled and indexed, and the links that signal the page is worth trusting. We can guarantee the work and the mechanism. We cannot guarantee the outcome on a fixed date, and anyone who does is either lucky or lying.

That answer costs us some deals. It also filters for the clients we actually want, the ones who care whether the reasoning is sound rather than whether the promise is bold. Our compensation is tied to outcomes, so we have every incentive to make rankings move. We just will not pretend we own a lever we do not own.

Three smaller things

• We removed the bounce rate widget from two client dashboards. It was generating questions that led nowhere, and modern bounce rate is measured too inconsistently to act on.
• We started A/B testing form length on a lead-gen site: four fields versus seven. Early read is that the shorter form wins on volume but we are holding judgment until we see closed revenue, for the reason described at the top of this post.
• We wrote a short internal checklist for handoff between the content team and the site team, because two revisions this week got lost in the gap between them.

Most of this week was about the same discipline from different angles: measure the thing that pays, not the thing that is easy to count. If you want an outside read on which numbers your site is optimizing for, run the free grader, or if you are ready to work with a partner paid on outcomes, apply for partnership.