Tried and dropped

A list of tools someone uses tells you very little. A list of tools someone stopped using tells you how they decide. These four are on our record because we wrote down what happened at the time, not because they make a good story afterwards.

A multi-platform social publishing tool. We connected it properly — six brand accounts, fourteen destinations across the major networks — and built a full pipeline around it: verify the target, compose, review inline, approve explicitly, publish, then read back to confirm it landed.

Then we checked how many posts it had ever published. The answer was zero. Fully connected, fully configured, across six brands, for months, and it had published nothing.

What we actually learned

The interesting failure was not the tool. It was our own record-keeping. Two blockers had been carried forward for eleven days as reasons the pipeline could not proceed. Both turned out to be false — one was disproved by a single call to the connector, and the other was disproved simply by trying the thing we had written off. Nobody had re-tested either; they had been copied forward from status update to status update until they read as facts.

The second finding was sharper. The connector's default publishing target resolved to the wrong brand entirely, which meant any post accepting the default would have gone out to a completely different audience under a completely different name. We caught it before anything published — partly by luck, given nothing had published at all. The pipeline now forbids the default target and requires the destination to be named explicitly.

Status: pipeline built and held, not in production use. We would rather say that plainly than imply a publishing capability we have not exercised.

This one was genuinely used, which is what makes it a fair test. We ran a live board as a systems map, with a dedicated automated process that pushed rendered frames and documents onto it and kept a run log of what it had drawn.

It worked until the board got big. Then it started to freeze, and a systems map you cannot open is worse than no systems map — because people stop trusting the whole idea of a shared picture rather than just that one board.

What replaced it, and why

We moved the same output to layered HTML pages generated from the source of truth. The comparison we wrote at the time is the reason it stuck:

Note what is not in that table: collaboration. For live, messy, many-hands-on-the-canvas thinking, a visual board is still the better tool and we have not pretended otherwise. What we stopped doing was using it as a durable artefact. It is a workshop surface, not a record.

Status: reference-only. Existing boards are kept rather than deleted — dropping a tool should not mean destroying the history it holds.

The appeal of running a model on your own machine is obvious: nothing leaves the building, no per-use cost, works offline. We installed the standard tooling for it and kept a set of local models on disk.

It ended up being diagnosed as the likely cause of a hard machine freeze on a working morning. We removed it completely — the binary, the background service, the startup entry, and around twenty-seven gigabytes of stored models.

What we actually learned

Local models are not free; they are paid for in machine resources, attention and failure modes that are yours to debug. On a laptop that is also doing real work, that trade is usually bad. The quality gap against a frontier model on a serious task is also still wide enough that we would not put client work through it.

We would revisit it for a genuine data-residency requirement, on dedicated hardware, with someone owning it. As a convenience on a working machine, no.

Status: removed. Would reconsider only with a hard privacy constraint and separate hardware.

This is a different kind of entry: a tool that was in the architecture from the start and never got switched on. The plan called for a proper hosted database, on the reasonable assumption that a platform would eventually need persistent multi-user data.

It never did. Files in version control, generated pages, and a gated dashboard covered every requirement that actually arrived. We deliberately marked the database as an optional future phase — to be added only when something genuinely required it — and that day has not come.

Why this counts as a lesson

The default instinct on any system is to stand up a database early because everything might need one. Doing so buys you a service to secure, back up, migrate and pay for, in exchange for a capability you are guessing at. Writing it in as explicitly deferred, with a stated trigger, gave us the design clarity without the operational weight.

The equivalent question is worth asking about most infrastructure in an AI project: what breaks if we simply do not add this yet?

Status: designed in, deliberately unbuilt.