Why Software Projects Fail in Small Companies

After hearing a software horror story, you want a better developer and a safer choice of technology. Fair enough. Broken screens, lost records and tools that can't do the job are real concerns. You want someone who can build properly.

But your worry is bigger than whether the code works. Will your team use it? Will you still be answering every question? A technically sound app can sit unused while everyone carries on with the spreadsheet. Choosing the builder is only part of preventing that.

Why code gets too much of the blame

In small companies, I think people and process deserve the first look when you're asking why software projects fail. A developer can build the screen you asked for. That screen still won't settle who approves a changed order, persuade the warehouse to use it or answer questions while you're away.

After 25 years of government digital programs, the UK's National Audit Office found a consistent pattern of underperformance, often because decision makers fixed on technology before the fundamentals were thought through.

That finding comes from large government programs, but I think it fits a 25-person company too. You still have to agree on what should change, who can decide and how people will work differently. A smaller team doesn't remove those decisions. It puts them on fewer desks.

At Silla, I mapped every step from order to complaint with the people doing the work. The app connected orders, stock and purchasing. Getting those steps clear matters more to me than choosing a fashionable technology.

Seven ways a working app ends up unused

A working app ends up unused when daily work still depends on unanswered questions, duplicate records and people who haven't agreed to change how they work. I'd check these seven things before approving a build. Each needs a business decision, and each gives the builder something concrete to work with.

1. The process was never agreed

Software freezes an argument when the people doing the work haven't agreed on the rules. If sales can change a confirmed order but the warehouse thinks it's final, the app has to follow one rule. Until you settle that rule, every screen review reopens the same disagreement.

What it looks like: In a process like that, sales asks for an edit button. The warehouse asks for a lock. Both requests make sense from where those people sit. Coding either request means choosing who gets to decide.

What prevents it: Put both people together with a real order. Agree when it can change, who approves a change and how the next person finds out. Test the rule against an ordinary order and an awkward one. The builder needs that agreement before turning it into permissions and notifications. A software requirement should record an agreed business decision. It shouldn't be the place you first discover a disagreement.

2. Every decision waits for the owner

The build stalls when every decision waits for an owner who already has a full day. Questions about refunds, permissions or stock rules sit unanswered. The builder either waits or guesses. You don't need to attend every discussion, but someone needs permission to settle the ordinary questions without you.

What it looks like: If your team can describe a problem but can't approve a change, every review sends another question to your phone. Work waits while you handle the business.

At NS Drafter, every crisis landed on the founders' desks. Our work there was leadership development and coaching, giving people real responsibility. A leadership team now handles day-to-day operations.

What prevents it: Name someone who can decide routine process questions. Write down what they can approve and what still needs you. Set aside time for those decisions. Responsibility without clear permission to decide just gives you another person forwarding questions.

3. The team first sees it at launch

People need to help shape the system before they're expected to use it. The person entering orders knows which details arrive late. The person packing knows what they can read with their hands full. An owner approving a demo can't stand in for everyone who does the work.

What it looks like: If the team first sees the app at launch, an apparently simple task can reveal a missing step. They return to the file that lets them finish the job.

The Government Digital Service's standard for public services recommends testing ideas early to reduce the chance of building something people don't need.

What prevents it: Bring the people doing the work into process mapping and early reviews. Ask them to complete a real task, including a correction or an incomplete order. Watch where they stop. A demo shows that a screen works. Doing the job shows whether the screen fits the work.

4. The old way never stops

The team has little reason to trust a new system if the old spreadsheet remains the place you check before making a decision. Running both indefinitely means updating both. When the records disagree, people follow whichever one you use, even if you've told everyone the app is now official.

What it looks like: If every app entry also needs a spreadsheet update, you've added work. Keeping the spreadsheet current feels safer because that's where the owner still looks for answers.

At Silla, complaints, outlet, purchasing and reports went into use in the app. The team stopped using paper and Excel.

What prevents it: Agree on one master record and a date to stop editing the old one. Keep old records available for reference if needed. If you need a temporary comparison, give it an end date. The guide to rolling out a new system covers the switch in more detail.

5. Every exception becomes a feature

Scope keeps growing when every unusual request becomes something the app must handle before anyone can use it. An exception can matter without belonging in the first build. Your job is to distinguish work the business needs every day from an unusual case a person can handle with a clear rule.

What it looks like: If each review adds another special approval, another field and another report, the ordinary order gets buried. The team is still waiting for the basic work to become easier while the list grows.

What prevents it: For each request, ask what happens without it, how often the situation occurs and whether someone can handle it safely outside the app. A legal requirement or a serious risk needs attention even if it's rare. Other requests can wait. Keep them on a separate list, with the reason for each. Adding something to the agreed scope should mean explicitly replacing something or agreeing on additional work.

6. Nobody inside the company owns it

A system needs someone inside the company responsible for how it's used after launch. The builder can fix code, but someone in your business has to notice incomplete records, settle questions about use and decide which improvements matter. Without that person, every small problem waits for whoever happens to care.

What it looks like: If an order has the wrong status and nobody knows who should correct it, people start keeping personal notes. The app loses trust because nobody keeps the records useful.

What prevents it: Give one named person time and authority to own daily use. They collect problems, check that agreed rules are followed and bring priorities to the builder. Name a backup too. This can be part of an existing role, but it has to be part of the actual workload. Tell the team where to raise an issue and who will decide what happens next. A title alone doesn't keep a system useful.

7. The builder disappears after launch

Launch needs a builder who stays involved when real work exposes a problem. A first-week issue needs someone who can work out whether the cause is a bug, a confusing screen, a missing rule or a training gap. An unanswered problem gives people a reason to return to their old files.

What it looks like: If someone can't correct an order and has no clear way to get help, they write it elsewhere. The workaround becomes another record that someone has to reconcile.

What prevents it: Agree before the build how problems will be raised, who will review them and how fixes and improvements will be handled. Include the internal owner in that agreement. Check that support covers the way people use the system as well as faults in the code. I stay involved through rollout, troubleshooting and ongoing improvements. Ongoing support and improvements are monthly. Launch is the start of using the system, so the work needs to cover what happens afterward.

What to agree before you build

Before you approve a build, agree on one workflow, one person who can decide and one person responsible for daily use. Have the people doing the work test that workflow with real tasks. Decide what the first version must do, what can wait and when the old records stop being edited.

Build work with me starts with paid Discovery, which takes 1 to 2 weeks and ends in a written proposal with a fixed scope and price. I look at how the business runs before deciding what to simplify, change or build. Those decisions give the proposal something real to describe.

That's why consulting and software belong together. The work needs someone to help settle responsibilities and process rules, build what's needed and stay involved while the team uses it. The technology is rarely the hardest part. Getting people to agree on how work moves is harder, and that agreement needs to show up in the software.

When the technology really is the problem

The technology really is the problem when the software loses records, exposes information to the wrong people or can't handle the work you've agreed it must do. Those are engineering problems, and they need engineering fixes. Clear roles and a willing team don't excuse software that doesn't work.

See where decisions depend on you

If every software decision waits for you, the Business MRI can help you see how much of the business runs on you. It's 10 questions, about 2 minutes, no email needed to see your result. You get a founder dependency score, your three weakest areas and a first move for each.