The TWIMCO notebook

Field notes.

Useful observations from inside the work.
For people building a better way.

Buying software · 28 notes

Antique workshop contract desk with four evidence folders—dry-run, on-call, change log, tabletop—bound by red thread to a partnership ledger.

Don't sign an SLA you cannot open.

A percentage on a slide is not coverage. Ask for a recovery they already ran, a real on-call window, a past change notice, and a date to practice an incident with you.

Read the note ↗︎

Antique workshop with a buyer and craftsperson at a workbench, a live demo slate propped like a sample board, red thread marking exception, ownership, recovery, and visibility notches on a wooden score stick.

Buying softwareField note

Score the demo by the exception path, not the happy path.

Every click works on the prepared account and the room nods. Two months later the first stuck case has no owner and no way back. Ask the vendor to show you the awkward path during the demo, and write down what you actually saw.

Read the note ↗︎

Antique operations desk with a severity matrix board, keyed cabinets for change rights, a red thread from P1 to a named owner card, and a coverage calendar.

Buying softwareField note

Write the incident matrix before the first P1.

The proposal says you'll be supported after launch. Then the first serious incident hits and it turns out "the team" doesn't answer a phone. People in named roles do, and the time to write those names down is before the bad hour.

Read the note ↗︎

Antique workshop with a scored checklist clipboard, a server crate being passed between teams, diagnostic gauges, a repair bench, and a red thread linking deploy to support.

Buying softwareField note

Score the handover by what the next team can do.

The zip arrived, the README is from mid-sprint, and the message says you should be good. Six weeks later nobody can deploy cleanly. A handover is finished when the next team can deploy, diagnose, recover and change the system on their own.

Read the note ↗︎

A designer and operator fit a paper pattern to the way their workspace functions

Buying softwareField note

Write the brief before you pick the builder.

Before hiring a builder or prompting an AI app builder, write the job, boundaries, exceptions, success evidence and handover expectations. A brief outline you can use today.

Read the note ↗︎

Hands working together over an architectural model and a sketched workflow

Buying softwareField note

What ongoing partnership should mean in a software contract.

After launch, decide who owns incidents, upkeep and change—and what evidence shows that coverage is real, not just promised.

Read the note ↗︎

An engineer guides a new operator through a working mechanism using its matching illustrated manual, access key and spare parts.

Buying softwareField note

What a useful software handover should include

Source code is one part of ownership. A useful handover lets the next team deploy, diagnose, recover and change the system with confidence.

Read the note ↗︎

Engineers and operators inside a connected fulfillment business, joined by a red thread

Buying softwareField note

AI app builder or engineering partner: how to choose

Choose around the work your system must do, the consequences of mistakes, and who will operate it after launch. A practical guide for founders and operations teams.

Read the note ↗︎

A good place to begin.

A familiar problem? Let’s look closer.

Tell us where you want to go. We’ll find the first thing worth changing.

Tell us about it ↗︎