How business owners make software decisions that don’t come back to bite them. A short, plain English book for the people who have to sign off technology decisions without being technical. Out now in paperback and on Kindle.

Read chapter one, free

The whole of the first chapter is below. No form, no download. If it is useful, the rest of the book is on Amazon.

Who it is for

Owners, operations managers and finance leads in businesses of roughly five to a hundred people: the ones who have outgrown their spreadsheets and are now being asked to decide what to do about it. You do not have to be technical to make these decisions well. You have to make them deliberately, and that is an entirely learnable thing.

There is no glossary and no code. Where a real term matters, it is explained in plain English the first time it appears. There is also no pitch at the end of each chapter and no number to call. The aim is simply to hand you the way of thinking I would want a friend who ran a business to have before they spent serious money on software.

What is in the book

• Introduction: Decisions, not code
• 1. The real problem isn’t software
• 2. Buy, build, or bodge
• 3. Fix the process first
• 4. The myth of the perfect brief
• 5. What it really costs
• 6. Going well, or sideways?
• 7. Bringing your people with you
• 8. Your data is the asset
• 9. AI: yes, but how?
• 10. Choosing (and working with) a technology partner
• Conclusion: Make it a decision

Every chapter opens with a summary you can read in a minute and closes with a checklist of plain questions you can run against the decision actually in front of you. Those checklists ladder up, at the very end, into a single one page framework you can keep by your desk.

---

Chapter 1: The real problem isn’t software

A while ago I took a call from the owner of a business about an hour up the road. She’d made her mind up long before she dialled. She wanted a new system: a proper one, built for her, to replace the tangle of spreadsheets and the off-the-shelf package that everyone in the office had stopped trusting. She had a budget in mind. She wanted to know how soon we could start.

I should have been delighted. That’s a customer who knows what they want, ready to spend money, asking me to do the thing I do. Instead I asked her a question she clearly wasn’t expecting.

“Before we talk about building anything, what’s the actual problem you’re trying to solve?”

There was a pause. Then: “Well. The software’s rubbish.”

I’ve had some version of that conversation more times than I can count, and I’m starting the book here because it’s the most important idea in it. The software probably isn’t the problem. Not really. It’s the thing you can see, the thing with a name and a price and a salesperson attached, so it’s the thing that gets blamed. But underneath almost every “we need new software” conversation is a problem that software, on its own, won’t fix, and that the wrong software will only make worse.

That’s a strange thing for someone who builds software for a living to say. Bear with me. By the end of this chapter I think it’ll make you money rather than cost me work.

The most expensive question in business

The most expensive question in business isn’t “how much will this cost?” It’s “what are we actually trying to fix?” And it’s expensive precisely because so few people ask it before they start spending.

When something in a business hurts (month-end takes forever, the numbers don’t tie up, a good person is drowning in admin, you’ve turned down work you weren’t sure you could cope with) the instinct is to reach for a tool. A new CRM. A bespoke system. Lately, some flavour of AI. The tool feels like action. It feels like progress. You can put it on a slide, point at it in a meeting, and tell yourself you’re dealing with the problem.

But a tool is an answer, and you can’t choose a good answer until you understand the question. Buy first and you spend the next six months discovering what you actually needed, usually by finding all the ways your shiny new thing doesn’t do it.

A tool is an answer. You can’t choose a good answer until you understand the question.

I’m not asking you to become technical. This isn’t a book about how software works, and you don’t need to learn to code any more than you need to understand metallurgy to buy a good set of kitchen knives. It’s a book about how to make good decisions when technology is on the table: which build to back, which to walk away from, when to spend and when to wait. And the first decision, the one that sits underneath all the others, is whether you’ve correctly diagnosed the problem at all.

Why software feels like the answer

There are a few reasons we reach for software before we’ve understood the problem, and they’re all completely human.

The first is that software is tangible. A messy process is hard to point at. A vague sense that “things take too long around here” doesn’t fit on a purchase order. But a system, a thing with a login and a dashboard and a monthly fee, feels real. It’s something you can buy and be seen to have bought. When the pressure is on, doing something concrete beats sitting with an uncomfortable, fuzzy problem.

The second is that someone is always selling. The technology industry is very, very good at telling you that your problems are software-shaped and that it happens to sell software. Every demo is built to look like the answer to a question you haven’t quite formulated. The pitch is rarely “this will help you do the specific thing you’re struggling with”; it’s “businesses like yours are transforming with this.” That’s not a lie, exactly. It’s just an invitation to skip the diagnosis and go straight to the prescription.

The third reason is the quietest, and the one I have the most sympathy for. Stopping to properly understand the problem feels like a luxury you can’t afford. There’s always something more urgent: a customer to look after, a fire to put out, a person to manage. The systems feel like background infrastructure: uncomfortable but functional, like a draughty office you’ve stopped noticing. So the problem never gets examined. It just gets a budget thrown at it and a hope attached.

I understand all three; I’ve felt them in my own business. But I’ve also seen where they lead, which is to a business that’s spent real money and still has the original problem, now with an expensive new system bolted on top of it.

What the problem usually actually is

So if it isn’t the software, what is it? In my experience it’s almost always one of a handful of things, and none of them are fixed by a download.

It’s a process that was never really designed. Most businesses don’t decide how they do things. They accumulate how they do things. A step gets added here because a customer once complained, a check gets added there after something went wrong, and a few years later you have a way of working that nobody chose and nobody could fully explain. When you try to put that process into software, you discover it isn’t a process at all: it’s a pile of habits, exceptions and “well, it depends.” Software needs clear rules. If the rules don’t exist, no system can invent them for you.

It’s data you can’t trust. Where do your customer records actually live? In the CRM? In someone’s inbox? In a spreadsheet that three people maintain and none of them quite agree on? Is “J Smith”, “John Smith” and “Smith, John” one customer or three? Most growing businesses are running on data that’s scattered, duplicated and slightly wrong, and they don’t notice until they try to do something that depends on it being right.

It’s a business that has outgrown its tools. This one isn’t a failure at all, though it can feel like one. The spreadsheet that was perfectly sensible when two people used it becomes a liability when eight people need it at once, from different places, all on the same Tuesday afternoon. The tools that got you here were the right tools for where you were. The mistake is assuming they’re the right tools for where you’re going. Growth changes the maths. What works smoothly at five people starts creaking at fifteen and becomes dangerous at thirty.

It’s a pile of workarounds nobody flagged. This is the sneaky one. When software doesn’t quite fit, people don’t down tools and complain. They cope. Someone builds a spreadsheet to hold the information the system can’t. Someone adds a manual step because a handoff doesn’t happen automatically. Someone keeps a private notebook of the things the system gets wrong. Each of these works; that’s exactly why they’re dangerous. They work just well enough that nobody calls them a problem, and they become part of the job.

Workarounds are insidious because they work. That’s the problem.

And they carry a second cost that’s easy to miss: they make the business fragile. The knowledge lives in one person’s head rather than in the system. When that person is off sick, or on holiday, or hands in their notice, the workaround goes with them. I’ve lost count of the businesses whose most critical process turned out to be “Dave knows how to do it”, right up until the week Dave didn’t.

None of those four things is a software problem. They’re business problems. Software can absolutely be part of how you solve them. But if you buy the software without naming the problem, you’re not solving anything. You’re just decorating it.

Software is an amplifier, not a cure

Here’s the bit that the demos never mention, and it’s the single most useful thing I can tell you.

Software doesn’t fix a broken process. It runs it faster.

If your current way of doing something is unclear, inconsistent or plain wrong, putting it into a system doesn’t sort it out. It automates it. You take the mess and you make the mess happen at the speed of a computer, on every transaction, without the human pauses where someone occasionally notices that something’s off and puts it right.

Think of it like this. If your filing system is a heap of randomly named folders, giving yourself a faster search tool doesn’t solve your problem. You just get to search through the chaos more quickly. Software is the same. It’s an amplifier. Point it at something that works and it makes the good thing bigger. Point it at something broken and it makes the broken thing bigger, and more confident, and harder to see: because now it has a clean interface and a price tag, so it must be sound.

This is why so many technology projects end in disappointment that gets blamed on the technology. The business takes an undefined process and a heap of untrustworthy data, wraps a new system around them, and is surprised when the result is an undefined process and untrustworthy data with a login screen. The software did exactly what software does. It faithfully automated what it was given. The problem was upstream the whole time.

I see this most starkly with AI at the moment, because AI is the most powerful amplifier we’ve ever pointed at our businesses. But the principle is old. It was true of the database projects of the nineties and the cloud migrations of the noughties, and it’ll be true of whatever we’re all excited about in five years’ time. A tool amplifies. It does not understand. The understanding has to come from you, before the tool arrives.

The cost of solving the wrong problem

It would be one thing if buying the wrong solution were merely a waste of money. Often it’s worse than that, because it sets you back.

Here’s a figure that should give any business owner pause. For the best part of thirty years, the Standish Group’s CHAOS research has tracked the outcomes of software projects, and the headline has barely moved: only about a third of them fully succeed. The rest either fail outright or limp in: late, over budget, or doing less than they were meant to. Sit with that for a second. Three decades of faster computers, better tools and hard-won experience, and roughly two in three software projects still disappoint. Whatever is going wrong, it plainly isn’t the technology. The technology has improved beyond recognition. The failure rate hasn’t.

It isn’t only the giant, complex projects either, though those are spectacular when they go. Closer to home for most readers, the humble CRM (the system nearly every growing business buys sooner or later) has carried a failure rate that analysts have long put at around half. Half. You could toss a coin.

And here’s the part that matters: when researchers dig into why, the culprits are almost never technical. Unclear requirements. A problem nobody had properly defined. And, tellingly, failing to involve the people who’d actually have to use the thing. Across all of that Standish data, the single biggest predictor of whether a software project succeeds isn’t the cleverness of the technology. It’s user involvement: whether the people it was built for were part of building it. We’ll come back to that more than once, because it matters more than almost anything else in this book.

The newest and loudest version of this old story is AI, where the gap between promise and reality is currently at its widest: plenty of firms are spending heavily and shelving the results a year later. But take the word “AI” out and it’s the same mistake businesses have been making for thirty years: buying a solution before understanding the problem. The label on the box changes every few years. The error inside it doesn’t.

These aren’t foolish companies. They’re companies that did the steps in the wrong order. They started with “we should have this” instead of “here’s what’s costing us, and here’s whether this helps.” It happens, less visibly and less expensively, with ordinary business software every single day. It just never makes the news, because nobody writes a case study about the £40,000 system that’s technically live and quietly unused.

And there’s a hidden cost on top of the wasted money: the scar tissue. A business that’s been burned once gets cautious in unhelpful ways. The team stops trusting “the new system” before it’s even arrived. The owner concludes that “this stuff doesn’t work for us,” when the truth is that the last attempt skipped the diagnosis. Solving the wrong problem doesn’t just cost you the price of the solution. It costs you some of your appetite to try again, and that appetite is worth protecting, because the right project, done well, is transformative.

Solving the wrong problem doesn’t just waste money. It costs you the confidence to solve the right one later.

Start with the problem

So what do you do instead? You start at the other end. Before anyone says the word “software,” you get specific about what actually hurts.

Specific is the key word. “We need to be more efficient” isn’t a problem you can solve; it’s a mood. “Our office manager spends a full day every month copying figures between two systems to produce the management report” is a problem you can solve, because you can see it, measure it, and put a number on it. The difference between those two sentences is the difference between a project that works and a project that wanders.

A handful of questions will get you most of the way there. You don’t need a consultant to ask them, though, as we’ll get to much later in the book, a good outside pair of eyes can help you answer them honestly.

Where does the time actually go? Not roughly. If you can’t say how many hours a week your team spends on a given task, you can’t know whether it’s worth automating, and you certainly can’t tell afterwards whether anything improved.

What does this cost: in hours, in errors, in opportunities missed? Put real numbers against the pain. The exercise is usually uncomfortable and always clarifying. It tells you what’s worth fixing and, just as importantly, what isn’t.

Is this a process problem, a data problem, a tools problem, or a people problem? Naming the category stops you reaching for a tool when the issue is that nobody ever decided how the job should be done.

If this were running perfectly, what would actually be different? If you can’t describe the better world in concrete terms (a report that builds itself, a customer record you can trust, a Monday morning that starts with a clear picture instead of a scramble) then you don’t yet know what you’re buying.

Answer those before you look at a single product, and something useful happens. Sometimes you discover the answer is software, and now you know exactly what it needs to do, which makes you a far harder customer to sell the wrong thing to. Sometimes you discover the answer is a process change, or a tidy-up of your data, or a single clear decision about how a job gets done. No system required. Either way, you’ve spent an afternoon of thinking instead of a year of regret.

This isn’t an anti-software book

I want to be careful here, because it would be easy to read all this as “don’t buy software.” That’s not what I’m saying, and it would be a strange message from someone who builds the stuff.

Software, chosen well and aimed at a problem you actually understand, is one of the best investments a growing business can make. The right system removes a ceiling you’d stopped noticing. It frees your best people from work that wastes them. It turns month-end from a data-gathering exercise into a five-minute review. It lets you take on the client you’d have nervously turned down a year ago. I’ve watched businesses change shape, not because the software was clever, but because it was pointed at the right problem by someone who’d taken the trouble to understand it first.

The goal was never to use software. The goal is to run a better business. If software helps with that, wonderful, and most of this book is about how to make sure it does. But the technology is the means, never the point. The moment you forget that is the moment you start buying answers to questions you haven’t asked.

The goal isn’t to use software. The goal is to run a better business. Sometimes software helps. Often, something simpler helps more.

That owner an hour up the road, by the way: we did eventually build her something, and it’s worked out well. But not until we’d spent the first conversation not talking about software at all. We talked about how her business actually ran, where the time went, which of her quirks were genuine strengths worth protecting and which were just scar tissue from years of making do. By the time we got to what to build, the hard part was already done. The build was just the easy bit at the end.

That’s the order this whole book follows, and it’s the order a good technology decision always follows: understand the problem, weigh the options, get the foundations right, and only then reach for the tool. The chapters ahead take those decisions one at a time.

But it all rests on this one idea, so it’s worth sitting with before we go any further.

The next time something in your business hurts and the instinct is to go shopping for a system, stop and ask the more uncomfortable question first. Not “what should we buy?” but “what are we actually trying to fix?”

Get that one right, and every decision after it gets easier. Get it wrong, and no amount of software will save you.

---

That’s chapter one. There are nine more.

The rest of the book takes the decisions in the order they land on your desk: choosing your route, fixing the process, scoping the work, understanding the cost, keeping a project healthy, bringing your people with you, looking after your data, using AI without losing your head, and choosing the right partner to help.

---

About the author

Richard Maly is co-founder and CTO of Maly IT Solutions in Ipswich. He has spent nearly thirty years on both sides of these decisions: writing the software, and helping business owners work out what software they need in the first place, what to spend, and who to trust with it. Much of the book comes from that work, in regulated and technically demanding environments as well as ordinary growing businesses. The stories in it are real and the names are not, because the lessons matter and the names don’t.