The TWIMCO notebook
Field notes.
Useful observations from inside the work.
For people building a better way.
Buying software · 28 notes

Opening note / Buying software
CSV import is a product feature, not a favor
Someone always asks to "just upload a spreadsheet." If import is how real customers start—or how they recover—it needs validation, a dry run, and an owner, not a one-off engineer weekend.
Read the note ↗︎
Leaving a tool that charges for contacts you never emailed
The bill jumped because your contact list grew—not because you sent more campaigns. Before you stay or go, weigh export quality, the true per-contact math, and what breaks on the Monday after you cancel.
Read the note ↗︎
Your first version should do one job properly. Cut everything else.
Feature lists for a first version tend to be wish lists for year two. Cutting one down is uncomfortable, especially when you're paying for every week of work. Here's what we'd usually take out, and the few things we'd argue to keep.
Read the note ↗︎
You've inherited a half-built app. Inspect it before anyone quotes a rewrite.
The last developer stopped answering, or the money ran out, or the agency moved on. Now there's an app that sort of works, and the first new developer you call says it should be rebuilt from scratch. That might be right. Find out first.
Read the note ↗︎
Fixed price or time and materials? Price the uncertainty, not the project.
Ask three development shops for a quote on the same app and you may get a fixed price, an hourly rate and a question back. Each one is a different bet about who carries the unknowns. Here's how to tell which bet suits the work you actually have.
Read the note ↗︎
Ask whose sales data your pricing tool learned from.
A lawsuit filed this month says McDonald's pricing software pooled private sales data from restaurants that are supposed to compete. Whatever the court decides, anyone shopping for pricing software now has a sharper first question to ask.
Read the note ↗︎
The morning after the store moves, customers find what the project didn't test.
Launch night went fine. The new storefront is faster and the team is proud of it. Then the support inbox opens at 8:15 the next morning, and the messages are about passwords, missing store credit and an old newsletter link, none of which were on the launch plan.
Read the note ↗︎
Ask how AI touched your code, then write the answer into the contract.
Almost every developer you might hire now works with AI tools, and almost no proposal says so. Here are the questions to ask on your next call, what a reassuring answer sounds like, and what belongs in writing afterwards.
Read the note ↗︎
A letter to the owner of the system everyone wants to rewrite.
You've heard it in three meetings now: the old system has to go, so let's rebuild it properly. Before you sign off on that, here's what we'd want you to know, as plainly as we can put it.
Read the note ↗︎
You may not need an app. Here's how to tell.
"We need an app" is sometimes exactly right and sometimes a way of saying we want to be taken seriously. Four common beliefs are worth checking before you pay to build and maintain two of them.
Read the note ↗︎
Isolation is a checklist, not a logo.
The vendor says multi-tenant and the demo shows two logos in a switcher. Underneath, a column on a shared table may be the only wall, and the support tool can open any account. Check every path that reads or writes, not the switcher.
Read the note ↗︎
Price what you'd own before you switch to open weights.
Reflection's open-weight model hasn't shipped yet, and people are already asking whether to switch. The download will be free. Running it won't be. Here's what you'd be taking on.
Read the note ↗︎
A retry is not a second write.
A payment capture times out, and the honest next move is to try again. The dishonest result is a second charge. "Our API is idempotent" isn't a policy until someone says what counts as the same attempt and who owns the duplicate.
Read the note ↗︎
When your vendor gets bought, use the quiet week.
Reports Sunday had Schneider Electric close to buying PTC. When a tool your team runs on lands in a headline like that, the reassuring email isn't a plan. Here's how we'd spend the first month instead.
Read the note ↗︎
Score the job before you buy the model.
The slide says the model tops the board. Your tickets still need a human. Before you route spend or traffic, run acceptance on the jobs you actually own.
Read the note ↗︎
Score build vs buy on evidence you can show.
Build and buy both sound fine in a meeting. The useful question is what evidence you can show, and who owns the failure neither option wants.
Read the note ↗︎
Checklist the disclosure package before the complex close.
A TWIMCO Disclosure Package Checklist: what must be verified, shown, and owned before a complex close—items, evidence, owner, blocker vs note.
Read the note ↗︎
Score exit readiness before you need to leave.
Renewal comes around and switching looks impossible. The export is unclear, identities won't map, and the runbooks live in the vendor's head. The time to find out whether you could leave is while you still have leverage.
Read the note ↗︎
Smoke the data contract before go-live—not after the first bad write.
Everyone agreed on the payload in a document. Then the first production write used a field the document forgot, and retries started duplicating. An hour of checks against the real edge in staging is cheaper than learning it from customers.
Read the note ↗︎
Put a name on every edge that can break the other side.
A retry doubles a charge. A field gets renamed without notice. The ticket bounces between two teams who each point at the connection between them. Every edge that can break the other side needs a named owner on both ends.
Read the note ↗︎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 ↗︎