The software was never the problem.Nobody made it run your business.That's what I do.

Roughly 95% of contacts carried attribution that could not be true, which meant every downstream report was confidently wrong rather than obviously broken. The cause was at the form, not in the reporting layer, and fixing reports on top of it would have produced a number that looked better and meant the same thing.

We fixed it at the form and backfilled 230 closed-won deals with zero failures. The signal that it landed was not ours: the team renamed their own Slack channel to match the new system.

The sync had drifted far enough that people had stopped believing what it produced, and the honest read was that incremental repair would restore the mechanism without restoring the trust. So we reset it deliberately, which costs more up front and is the only version that ends with anyone believing the output.

Three months on, the RevOps lead's own verdict was that the flow is generally working. That is a deliberately unglamorous sentence and it is the one worth reporting, because it came from them rather than from us.

A meaningful part of how this business sold had never been measured, so it existed as an impression rather than a figure, and every decision that touched it was being made on feel. The work was making it countable rather than estimating it.

When the figure arrived it was within a rounding distance of what the owner had believed all along, which is the outcome you want and the one people underrate — a number that confirms an experienced operator's instinct gets adopted immediately, where a surprising one starts an argument about the method.

The build mattered less here than who could operate it afterward, and that was the client's framing before it was ours. Their CEO's verdict was that done-for-them without transfer "would have been a failure" — his words, and the cleanest external statement of the thing this practice is built around.

It is also the hardest outcome to evidence, because success looks like an absence: no standing dependency, no retainer that exists to keep the lights on, no call that has to come back to us.

An acquisition left two portals and an integration nobody could read: its author had gone and the repository was lost, so the only available source of truth was what it did when it ran. We reverse-engineered it from behavior, which is slower than reading code and is the only method available once the code is not there.

The instinct at that point is to sample the workflows and extrapolate. We scanned all 696 instead, which is what surfaced the actual risk — enabled status rather than logic — and the 60-workflow re-point that followed was verified to zero stale IDs rather than assumed clean.

At 424K contacts and 1,623 properties, nobody can hold the portal in their head, and four duplicate pipelines meant the same commercial motion was being counted in several places at once. The audit was the deliverable before any rebuild could be scoped honestly.

The finding that mattered was not in the pipelines. A broken service worker was firing a fake 404, and that 404 had quietly become the number-one first-touch interaction in the portal — which means every first-touch attribution report was ranking a bug at the top and nobody could see it, because at that volume a wrong number and a right one look identical.

Contacts were being hard-deleted while transactions referencing them were still running, so the failure showed up somewhere else entirely and looked like an unrelated bug. We locked deletion down, which is a governance change rather than a technical one and is the reason it held.

The second half was timing rather than craft: a developer who held knowledge nobody else did was leaving. Custom-code training and a shared repository went in before the departure rather than after it, which is the only point at which that work is cheap.

Their sellers needed proposals built from what was actually available, and the gap between the inventory and the document was being closed by hand every time. We built the UI extensions that close it inside the CRM, so the proposal comes from the live record rather than from a copy of it.

The part worth reporting is who scoped it. Their own sales ops led the rebuild scope, which is slower at the start and is the difference between a system a team uses and one they work around.

The commercial system and the operational system each held a partial account of the business, so any question that crossed them was answered by a person reconciling two screens. We made them one operating picture rather than two feeds pointed at a dashboard.

It was also the first engagement where handing the low-signal work to AI produced a visible speed difference for the team rather than a demo. That is reported as a first proof rather than a general claim, because one engagement is what it rests on.

Standing up a partner channel means the commercial model gets harder in a specific way: the rate that applies to a given deal depends on the partner, the tier, the product and the timing, and that resolution has to happen somewhere reliable rather than in a spreadsheet someone maintains. We designed the model and custom-coded the rate resolution.

What I cannot tell you is whether it is running well in production today. My own record marks the outcome as affirmatively in doubt, so this sits here as a design story and nothing more. It is on the page because leaving it off would make the rest of this list look better than the work actually was.

A permit-lead integration was built and the client confirmed it works. That is the whole outcome, and it is a real one: something they needed exists and does its job.

There is no transformation story here and I am not going to construct one. It is on this page deliberately, because every other case describes something changing shape, and a proof section where every engagement is a turnaround is telling you more about the selection than about the work.

The original build fit a prior, generic business model — not a multi-location vehicle retailer with a buyer side, an acquisition side, financing, and a post-sale operation. We put the objects that carry the real operation into production behind a unified contact view, ran the architecture audit against live reads, and found and reconciled the drift between the design docs and the portal.

The buyer-pipeline reshape that follows is in progress and gated on a sandbox test — named as in flight rather than finished, because it is.

Their buyer makes a 12-to-24-month decision and arrives through referrals, brokers, and on-property events — a population a standard engagement score systematically buries, because referral contacts rarely carry a tracking history. Ranking who was worth a call was being done by hand, from memory.

We built a Combined model and wrote down why: a nine-tier grade where the letter reflects Fit and the number reflects Engagement, so a referral-led contact stays legible on the axis that actually describes them. Their architect owns the pieces his team is closest to — the point is that they can run it without us.

Growth had outrun the systems: four-hundred-plus active workflows with dependencies nobody could trace, renewals scattered across three divisional pipelines, roughly 450 hours a year spent fixing associations by hand. We audited the workflows down to about 65, built a contact health score their team actually uses, and rebuilt renewals — 409 quarterly contracts extracted from production data into clean records, with the end-to-end renewal quote flow demonstrated working.

A renewal used to be reconstructed by hand across three systems. It is becoming one record with a date on it that a named person owns — and "becoming" is deliberate, because the rollout is still in progress and saying otherwise would be a lie.