CW Colton Weeks Consulting

Case studies

The work, including what went wrong.

Four case studies from recent work, shown in full. The wrong turns stay in — they're where the method earns its keep.

Building the Concierge my own practice needed

Concierge · Case Study Zero

Multiple inboxes, multiple calendars, and the quiet feeling of always being slightly behind. I needed a way to get above the load instead of living under it.

The problem

Messages and commitments were landing in different places. Nothing was broken, but nothing was unified either. The cost was attention: scanning, deciding what mattered, and still missing things that should have been simple.

What was built

Concierge, as I run it: one place that holds the day. A ranked morning surface, plus specialists as needed, all trained on one voice and one set of rules. I still decide. Portable playbook. Propose-only for anything irreversible.

Outcome

One surface for what actually needs me. The rest is filtered, proposed, or held. Concierge is live; the lessons log is real.

What transfers

The method is the product. Stand Concierge up on another practice the same way: sit in their mess, ship on their tools, stay through week two.

Helping a non-profit untangle a complex situation with an uncooperative vendor

Flagship

More than 15,000 rows of data corrected on a live system that a team depended on daily. Nothing taken offline, every change reversible.

The problem

A subset of recipes had quietly wrong ingredient amounts or wrong total yield calculations. Scaled to the day's headcount they produced too little food, or too much. The cause was an inconsistency inherited from a predecessor system — invisible from inside the data.

The wrong turn

A lot of effort went into a statistical model of what “healthy” data looks like. It was wrong, and wrong in a way the dataset itself could never reveal — it had been calibrated on its own symptom. One read-only harvest of an outside system made the problem tractable in a way no better heuristic would have.

How it was done

  • A read-only audit shipped first, establishing the true blast radius
  • The correction ran as an idempotent migration step — writing prior state before each overwrite, so the whole sweep was reversible
  • A tripwire shipped alongside it, warning when a recipe's header and its ingredients disagree

Outcome

Repaired data verified on production after deploy.

What transfers

When correcting data, the first question is what can I check this against? — not what pattern can I infer? An external anchor beats a better heuristic.

Normalizing a legacy database that couldn't go offline

Data quality

Twenty years of undocumented data turned into a canonical source of truth, one measured pass at a time, while the team used it every day.

The problem

Roughly 2,000 recipes and 15,794 ingredient rows maintained by many hands with no enforced conventions. Duplicate identities differing only in case or word order. 48 distinct unit values. 3,487 rows recording dry goods in a liquid measure — the fossil residue of an old mechanical conversion. Roughly 170 free-text values in a field that should have held a closed vocabulary.

The constraints

  • No downtime and no freeze — the kitchen cooked from this data daily throughout
  • No authoritative reference to reconcile against; conventions had to be inferred, then ratified by a domain expert
  • I am not a chef. Every vocabulary decision needed someone who was, and their time was scarce

The method

Audit first, always: ship a read-only report of the true scope, review the real numbers, then design the fix as a separate step. Pair every cleanup with a rule that stops the drift returning — closed vocabularies, a gate on ingredient auto-creation, validation on the type dropdown. The goal wasn't just “clean the data once.” It was to make the database outlive any single contributor.

What transfers

Spend the domain expert's time on rulings, not archaeology — they should review a structured proposal, not answer questions for three weeks. And every cleanup needs a gate, or you'll do it twice.

Building the coding review partner a solo maintainer doesn't have

For engineering leaders

Test gates, secret scanning, and an automated advisory reviewer — built because code auto-deployed to production on merge and there was no second pair of eyes.

Where it started

One honest question: what actually happens when I click merge? The real answer was worse than the felt answer. That inventory is worth running on any project you've been shipping to for a while.

What was built

  • A test suite and CI gate — fast safety net rather than exhaustive coverage. The highest-value test asserts a migration is idempotent, because that failure mode is silent, recurring, and corrupts production rather than breaking a build
  • A secret-scanning gate in CI and an optional matching pre-commit hook
  • An automated code review on every pull request, deliberately advisory rather than blocking

The considered position

Advisory beats blocking when there's nobody to escalate to. A gate whose failure mode is “the one person who can override it, overrides it” isn't a gate. Separate the second-opinion value from the veto power — you usually only need the former. The repository contains a documented case of a bot finding being knowingly declined, with the reasoning written down.

What transfers

Solo teams and small teams have to deliberately construct what a second engineer would have provided. It's cheap to build once you name what's missing. And a safeguard that fights the workflow gets deleted — all three of these are still running, hundreds of pull requests later.

Your business could be next.

Every one of these started the same way: a short call, then a fixed-fee, read-only audit.

Book a call Get started