What the Tractor Repair Fight Teaches You About Owning Your Business Software

There's a story doing the rounds about a farmer who used John Deere's official self-repair programme to fix his own tractor. It worked, technically. But he came away unimpressed, because the process was still slow, still gated behind the manufacturer's software, and still left him feeling like a guest on his own machine rather than the owner of it.

That's not really a story about tractors. It's a story about what happens when the thing you rely on to run your business is controlled by someone else's software, and you only find out how much control they have once something goes wrong.

I see the same pattern in ordinary business software all the time. Not as dramatic, but the same shape.

The subscription tool that quietly becomes load-bearing

Most businesses start with off-the-shelf tools because they're quick to set up and cheap to try. A booking platform. A CRM. An invoicing tool. A stock system. Nobody signs up for one of these expecting it to become critical infrastructure. But two years later, the whole scheduling process runs through it, staff have learned its quirks, and customer history lives inside it.

At that point you don't really have a subscription anymore. You have a dependency. And dependencies only reveal their terms when they change:

• The vendor raises prices sharply, because they know switching costs are high.
• A feature you built a process around gets removed or moved to a higher tier.
• The API you integrated with changes or gets deprecated.
• The company gets acquired, or shuts down, or just stops investing in the product.

None of this is hypothetical. It happens to well-run tools all the time, for perfectly ordinary commercial reasons. The vendor isn't doing anything wrong. They're running their business. The problem is that you didn't check, up front, what your position would be if any of that happened.

Ownership isn't all or nothing

The lesson from the tractor story isn't "never use anyone else's software." That's not realistic, and most of the time off-the-shelf tools are the right call, especially for anything that isn't specific to how you work. The lesson is that ownership sits on a spectrum, and you should know where each part of your business falls on it.

At one end, you're a customer of a product, using it the way everyone else does, with no real customisation. That's fine for email, accounting software, and most general-purpose tools.

At the other end, a process is specific enough to how you operate, or valuable enough to your margin, that you need to actually own it: the code, the data, the ability to change it without asking permission or waiting for a roadmap. Somewhere between those two points, most businesses are running a core process on a tool that was never built for them, and haven't asked which end of the spectrum it should sit on.

A few questions are worth asking about any tool that's become load-bearing:

• Can I export my data in a usable format right now, without opening a support ticket?
• If the vendor doubled the price tomorrow, could I actually move, or am I stuck?
• Does the tool do the job the way my business actually works, or have I been quietly reshaping my process to fit its limitations?
• If this tool disappeared, how long would it take to notice, and how much would it hurt?

If the answers are uncomfortable, that's not a reason to panic. It's a reason to plan, before a price rise or a shutdown forces the decision on your timeline instead of yours.

Where bespoke actually earns its cost

I build bespoke software for a living, so it would be easy for me to say "just build everything yourself." I won't, because it's not true. Building your own version of a general tool that already works well is usually a waste of money.

Where it earns its cost is when the process itself is the thing that makes you competitive, or when being locked out of your own data would genuinely hurt. A trades business whose entire booking and payment flow runs through a rented platform is one price change away from a bad month. A firm whose pricing logic, customer history and audit trail are the actual product they're selling can't afford for that logic to live inside someone else's black box.

In those cases, owning the software isn't about control for its own sake. It's about the fact that when you own it, nobody can change the terms on you. No repricing, no feature removal, no "sunset" email with three months' notice. You decide what changes and when.

If you're not sure which category a given tool falls into, it's worth working through the trade-offs properly rather than guessing. I built a build vs buy calculator for exactly this, to help you see where a process sits before you commit further to a platform you don't control. And if you've already inherited an old system that's showing its age, or you're trying to work out whether to keep, replace or integrate it, that's the kind of assessment I cover on the legacy software modernisation page.

The tractor argument will keep running, because right-to-repair touches something real: the discomfort of paying for a thing and still not really owning it. Your business software raises the same question, just quieter. It's worth asking it before the vendor answers it for you.