Bringing software into a business is more than building a tool. It changes habits, roles, the pace of daily work. Six hurdles where things regularly stumble - and why you can't code your way around them.
Most failed software projects in SMEs don't fail because of bugs, missing features or weak architecture. They fail because of people, habits, and what no one said out loud.
We're not talking about the hurdles every developer knows. We're talking about the ones hiding in the desk drawer, in the break room, in the first two weeks after launch. If you know them, you can plan for them. If you miss them, you reliably build right past them.
The people
Scepticism, habit, fear of visibility - what no spec sheet captures.
The day-to-day
Operations, legacy systems, data from before - everything already in place.
What comes after
Maintenance, adjustment, ownership - everything that begins after launch.
The most common verdict after a failed software rollout isn't "the tool was bad," it's "the people didn't take to it." That sounds like sulking - but it's usually something else. To someone who has developed their own way of doing things in the engine room of a business over ten years, being told "this is how it goes from tomorrow" is an attack on their competence, not a relief.
Scepticism rarely has to do with convenience. It has to do with a quiet question: Will I still be needed with the new system? No one asks it out loud. But it sits in the room when the new system is rolled out - and it decides whether the system gets used, or whether a covert Excel shadow-network keeps running alongside it. If you don't answer the question, you're building software for an empty office.
In organisational psychology, the finding is called psychological safety - coined by Amy Edmondson (Harvard Business School) from 1999 onward. Her studies show: teams in which employees are allowed to admit mistakes, ask questions and confess uncertainty take up new tools markedly faster and more sustainably than teams where that's taboo. The technology of the tool is secondary here.
The classic reference is Everett Rogers' "Diffusion of Innovations" (first edition 1962). Rogers shows that every innovation runs through a predictable distribution of innovators, early adopters, late majority and laggards - and that the late majority only joins in when it sees the early adopters in the same building succeeding with it. Anyone who only commands the rollout top-down skips this bridge - and then wonders why no one arrives on the other side.
Installing new software takes an hour. Actually making it part of the daily work routine takes months. Everyone underestimates this gap - the vendor selling the demo, the boss signing the contract, and sometimes the employee who thinks Monday will be different. Nothing's different. It's just added pressure.
Habits aren't replaced by logins, but by successful repetition. When the new system doesn't do what you expected on the first try, you go back to the old one - and reclaim it as "this has always worked." That's why the second day after launch wins the entire project: if it stumbles there and no one catches it, the tool is already lost, no matter how good it is technically.
The term for this gap is the adoption gap or "valley of disillusionment" - made visible in the annual Gartner Hype Cycles: every new technology goes through a predictable phase in which it's already installed but isn't yet delivering value. Anyone who pulls support during this phase loses the investment almost entirely.
A McKinsey review from 2023 on IT transformations in mid-sized businesses shows: 70 percent of software rollouts don't reach their planned adoption rate - in 80 percent of those cases not because of software shortcomings, but because of a lack of support in the first six weeks. Charles Duhigg described the psychological mechanism in "The Power of Habit" (2012): a habit only changes when the new variant produces a success faster than the old one. Otherwise the familiar path wins - every time.
When a software project starts in a business, it gets added to the day-to-day - it doesn't replace it. Customers keep calling, deliveries keep arriving, orders still have to go out. That's the reality in which training sessions, testing and data migration are supposed to happen: between two complaints and the lunch break.
Anyone who doesn't plan for that is planning against the business. So in every project we reserve explicit protected windows - short, clearly defined slots in which we take in material, run tests, hold training sessions. Without these windows, neither happens: the day-to-day doesn't suffer because the software gets neglected - and the software gets neglected because the day-to-day can't be allowed to suffer. It's one of the few places where firm dates are worth more than flexibility.
The economic term for this is opportunity cost: every hour an employee invests in the new system is an hour they're not spending in operations. In businesses with a tight headcount, those are hard numbers. A 2024 study by Bitkom (Germany's digital industry association) shows: in 64 percent of mid-sized digitalisation projects, "the time of your own people" is the limiting factor - not money, not technology.
The Theory of Constraints (Eliyahu Goldratt, "The Goal," 1984) explains why. Every business has a bottleneck - a person, a machine, a shift. Anyone blocking that bottleneck for software training blocks the whole business. The conclusion isn't to skip the training - it's to schedule it so the bottleneck doesn't seize up.
Every business has a past, and it lives in Excel files, in a ten-year-old program, in an Outlook folder of 40,000 emails. It all has to come along. Not entirely, but what matters - otherwise the new system starts on an empty stage, and no one can find their regular customers again. Data migration is the most invisible, most boring and often most expensive phase of a project.
And it's the only phase that can't be deferred. New software without a clean data base is an empty shelf: beautifully built, but useless. So we take the old data sets in hand very early, often still in the analysis phase. Not to rescue them - but to see what in them still holds up. Sometimes the answer is "a lot," sometimes "surprisingly little." Both answers help size the project properly.
The umbrella term is legacy burden - studied in academic computer science by, for example, Michael Feathers ("Working Effectively with Legacy Code," 2004). His finding: in grown systems, 70 to 80 percent of the effort isn't building the new - it's understanding the old. That applies to code just as much as to data.
The Standish Group Chaos Reports have documented software projects in mid-sized businesses since the 1990s. A recurring pattern: projects with unclear data have a failure rate more than twice as high as projects that do data analysis early. Geoffrey Moore ("Crossing the Chasm," 1991) turns this into a maxim: the migration of existing data isn't a project's last risk, but its first.
In the euphoria of a project, one question slips into the background: what happens in two years? Who maintains the software, who does updates, who builds the next button? This question has the unsympathetic quality of feeling like spending money on top of money. But anyone who doesn't ask it is buying a tool without a warranty.
Software is not a piece of furniture. It ages, because the surrounding internet changes: APIs shift, browsers get updates, new laws come in. Anyone who builds software once and then leaves it sitting will find in two years that it no longer works - not because it was bad, but because the world around it has turned. That's why for us, every project includes the answer to "what happens afterwards" - before the contract, not at the first bug.
The term for this is Total Cost of Ownership - coined by the Gartner Group in the late 1980s, originally for IT hardware. The core finding: the purchase price typically accounts for only 20 to 30 percent of lifecycle costs. The rest goes into maintenance, adjustment, training, migration. Anyone comparing only the purchase price is comparing the wrong third.
In software, the same phenomenon is called software entropy - described, among others, by Andrew Hunt and David Thomas ("The Pragmatic Programmer," 1999): every software system decays when it isn't actively maintained. Not from material fatigue, but because the surroundings move on. The consequence: maintenance is not a bonus to the purchase price - it's part of it, whether you state it that way or not.
In SMEs, distrust of expensive software runs deep, and rightly so: too many projects have gone off the rails. The reaction is often to save at the beginning - take the cheapest quote, choose the smallest version, skip the training. That looks thrifty. Most of the time it's the opposite.
What's saved at the start resurfaces later - as workarounds, duplicate work, data no one can find, and a tool no one uses. Software that isn't used is 100 percent lost, no matter how little it cost. The question isn't how much the project costs, but how much the unsolved problem keeps costing if you don't address it. That sum is uncomfortable - but it's usually the most honest answer to the question of what you can afford.
The psychological mechanism is called hyperbolic discounting (David Laibson, Quarterly Journal of Economics, 1997): people rate costs today markedly higher than costs in the future, even when the future costs are objectively greater. In a software project, this means: the 3,000 Euro I save today feel more real than the 30,000 Euro I'll pay in three years because of poor data - even though, on average, the equation works out exactly that way.
In IT practice it's called technical debt - a term coined by Ward Cunningham (1992). Like financial debt, the shortcut taken today is repaid with interest: every adjustment to the system gets more expensive, until at some point a complete rebuild is cheaper than one more patch. Martin Fowler popularised the term in the 2000s and boiled it down to a bitter rule of thumb: software savings made today are repaid with interest - usually by someone other than the one who booked the savings.
None of them is a technical problem. All of them decide whether the technology works in the end.
Bringing software into a business isn't building a machine. It's building at the place where people, routines and tools come together. That's why a project doesn't only need a developer - it needs someone who takes the people along, respects the day-to-day, honours the old data and talks honestly about the time afterwards. That's what we mean by "support." It's more effort than a pure code commission. But it's the only effort that genuinely pays off in a business.
More on how we work in practice is on Before we build, we figure out what's broken and on Tools first, AI second. An honest take on what AI risks in a business, you'll find on What AI can't do, even when it looks like it can.