The first ninety days after you ship an internal tool.

Internal tools fail politely. Nobody writes a review. People open the old workbook in another tab and wait for the new system to become optional. Ninety days is usually enough to tell whether you shipped a system or a demo with a database.

This is the checklist we run after a release — what to watch, when, and what to change. It is the difference between a studio that ships software and a vendor that ships a phase.

Why launch metrics mislead

At launch we measure what is easy to count: tickets closed, screens shipped, whether the training session went well. All of it is about the build. None of it is about the work.

Days 1–14: watch the workarounds

The first two weeks are about noticing what people do when they think nobody is looking. Sit with them. Do not ask what they think of the tool; watch what they open.

• The old workbook. Is it still open? Is it still being edited, or only read?
• The CSV export. Who exports, to where, and why? Every export is a missing feature or a missing trust.
• The chat message. Which questions still go to a person instead of the tool?

The signal

A workbook that is read but not edited is a comfort blanket. A workbook that is still edited is a requirement you missed.

Days 15–45: find the lying status

By week three, the data starts to reveal where the model and the work disagree. The classic symptom is a status that people set because the system requires it, not because it is true.

Questions worth asking

1. Which status is set and never read?
2. Which status is set in bulk, at end of day, from memory?
3. Which role was invented in the workshop and does not exist on the floor?
4. Which required field is filled with a placeholder?

A status that is always "Done" ten minutes before the shift ends is not a status. It is a tax. Remove it, or make it true.

Days 46–75: the second cut

The second cut should come from these answers, not from the backlog written before anyone used the thing. In practice that means the second release is smaller than people expect and more important than the first.

With Halcyon, the first cut was inbound exceptions, assignment, and a morning digest. The second cut — customer-visible notes — came directly from sales asking dispatch for screenshots in week five.

Days 76–90: decide what stays optional

Ninety days in, you should be able to answer a blunt question: could the team go back? If the old workbook were deleted tomorrow, would work stop?

• If work would stop, you have a system.
• If work would slow slightly, you have a good tool that is not yet load-bearing.
• If nothing would change, you shipped a demo with a database.

Decide, deliberately, what happens to the old artifacts. Archive them read-only, name a date, and say so in writing. Ambiguity is how a system stays optional.

The handover that makes ninety days possible

None of this works if the studio disappears after launch. It also does not work if the studio never leaves. The pattern we use: a written handover, a named operator on the client side, and a short, explicit window for the second cut.

• A named person who owns the system after handover.
• Runbooks for the cases that happen after hours.
• A scheduled review at thirty and ninety days, with the questions above.

A measurement kit you can set up before launch

Everything in this essay depends on being able to see what people do. That means instrumenting the tool before go-live, not adding analytics in week six when the interesting behaviour has already formed habits. The kit is small.

Pair the quantitative signals with two qualitative ones: a weekly ten-minute conversation with the most sceptical user, and a standing question in the team channel — what did you do outside the tool this week? The second question surfaces the workaround before anyone thinks to call it one.

SELECT status_to,
       date_trunc('hour', changed_at) AS hour,
       count(*)                       AS changes,
       count(DISTINCT record_id)      AS records
FROM   status_events
WHERE  changed_at > now() - interval '30 days'
GROUP  BY status_to, hour
HAVING count(*) > 20      -- a burst of changes in one hour
ORDER  BY changes DESC;

Running the thirty-day review

The thirty-day review is where the second cut is decided. Keep it short, keep it evidence-led, and keep the person who owns the system after handover in the chair. A good agenda fits on one page.

1. 01

   Read the numbers (10 minutes)

   Show created versus updated volume, export counts, and no-result searches. No interpretation yet.

2. 02

   Walk the workarounds (15 minutes)

   List every artifact still in use outside the tool. For each, ask: missing feature, missing trust, or habit?

3. 03

   Name the lying statuses (10 minutes)

   Any status set in bulk or set to please the system rather than describe the work.

4. 04

   Choose the second cut (15 minutes)

   Pick at most three changes. Write what each should do to a named metric.

5. 05

   Assign the retirement date (10 minutes)

   Decide which old artifact is read-only from when, and say so in writing.

Handling resistance without a campaign

Resistance to a new internal tool is almost never irrational. It is usually a rational response to a real cost: the new system is slower for a task the person does forty times a day, or it exposes an informal arrangement the old sheet was hiding. Treat resistance as data.

A week-by-week timeline of a real ninety days

The Halcyon rollout is a useful reference because the numbers are recorded. The pattern generalises even where the details do not.

The most telling row is week five. Nobody wrote a requirement. The need appeared as a repeated, slightly annoying request between two teams. Watching for that kind of friction is the entire method.

Anti-patterns that make the ninety days fail

Shape Up ^[1] describes a related idea in product development: a fixed cool-down after each build cycle to fix what real use reveals, before starting new work. The ninety-day window is the same principle applied to a tool that has just landed in a busy team.

Closing

The internal tool is finished when the old workbook is closed and nobody reaches for it. Everything before that is a launch. Plan for the ninety days, not the week.