Every few months a partner tells us they have found the tool that will fix it. Usually they have already booked the demo. Sometimes they have already paid.
We understand the instinct. The work is visibly dragging, everyone can feel it, and software is the one lever a founder can pull on a Tuesday afternoon without having a difficult conversation. Tools are purchasable. Handoffs are not.
Here is what we keep finding when we go and look, though. The drag almost never starts where the tool would go. It starts at the seam between two people.
A job arrives, and someone has to decide whether it is complete enough to work on. If there is no standard for that, three things happen at once: the person receiving it invents a standard privately, the person sending it never learns what was missing, and the gap gets absorbed by whoever is most conscientious. That person is now the process. They are also the bottleneck, and they are usually the one you can least afford to lose.
Nobody logs this. There is no line item for rewriting the brief again. It surfaces as a vague sense that everything takes longer than it should, and as one specific fact: someone capable spends every Friday in a spreadsheet.
Add a tool at that point and you have automated the transport of an incomplete brief. It arrives faster, in a nicer interface, still incomplete.
What buying software does to a bad seam is hide it. That is the part worth being precise about, because saying it does not help undersells the problem — it actively makes the mess harder to see. Before the tool, the failure was legible: you could watch a job bounce between two people and count the round trips. After the tool, the same round trips happen inside a system that reports on itself, and the report says the workflow completed. The status went from draft to in review to approved. What it does not say is that in review meant someone chased the missing dimensions over WhatsApp for two days.
There is a money version of this too. One partner was running client pipeline, project delivery and people admin in three separate products from the same vendor, paying per seat in each, with nothing talking to anything. The number that mattered — what a project had actually cost — depended on which of the three you opened. That is not a tooling gap, and three more tools would not have closed it.
So we do the boring things first, roughly in this order. Write down what complete means, as an intake standard with validation that runs before a reviewer ever opens the file; this is usually the highest-yield item on the list and it is almost always a form and a checklist rather than a platform. Name who approves what and at what threshold, with a defined escalation path, because most stalls we find are not disagreements but two people each reasonably assuming the other has it. Make the handoff explicit rather than implied, so that when a stage ends something says so. Only then look at tools — by which point you usually need fewer than you thought, and you know exactly what you are asking them to do.
The order is the whole argument. Automate a clean handoff and you get leverage. Automate a dirty one and you get the same mess at higher throughput, plus a subscription.
Often enough that we should say it plainly: sometimes a tool genuinely is the answer. If the handoff is already clean and the cost is purely transport — copying the same numbers between two systems, chasing a status somebody already knows, re-typing an approval — then buy the thing, or connect the two you have. That is what integration is for and it pays back quickly. The test we use is whether you can describe the handoff end to end without saying “and then usually someone checks”. If you can, it is ready to automate. If you cannot, the tool is going to inherit that sentence.
The uncomfortable part is that fixing a seam means telling two people their working arrangement is now written down. That is a management conversation, not an implementation, which is why this route is less popular than the demo. It is also why structural changes need watching for a few cycles before anyone calls them fixed: the first version of an intake standard is always slightly wrong, and the people using it are the only ones who can tell you how.
None of this argues for fewer tools as a principle. We are not romantic about doing things by hand. It argues for a sequence — make the business easier to run, then make it faster. Doing it the other way round is how a team ends up with eleven subscriptions and the same Friday spreadsheet.