A technology project is likely burning money when three things happen together: deadlines keep moving without a specific cause, nobody has shown you something you could actually use in the last few weeks, and new requirements keep arriving while no single person has the authority to say no. When you see these signs, pause and ask for a working demonstration and a reduced plan, rather than adding more budget and hoping.
How good projects slowly turn into expensive ones
Very few projects fail in one dramatic moment. They drift. The first delay has a reasonable excuse, the second one sounds similar, and by the third everyone is used to it. Meanwhile the team is busy, reports are full of activity, and the business owner feels it would be rude or risky to ask hard questions of people who know more about technology.
A common starting point is a custom build for something that ready-made software already does reasonably well. Custom feels attractive because it promises to fit the business exactly. But every special requirement adds design, coding and testing work, and later every change in the business means paying again. The project becomes a permanent dependency rather than a one-time purchase.
Another pattern is the moving target. Halfway through, the owner sees a competitor's app and asks for a similar feature; a department head adds a report; someone wants it to work on phones too. Each request is small, but together they double the work, and the original deadline was never adjusted to match.
The hardest part is the sunk cost feeling. After spending a large sum, stopping feels like admitting waste. Yet the money already spent is gone either way. The only real question is whether the next sum will buy something useful.
Warning signs to watch for
Progress is measured in activity, not results. Reports list meetings held and hours worked, but you cannot click through anything that works.
Deadlines move without a specific reason. "Some technical issues" is not a reason. A real reason names the problem and the plan to fix it.
Nobody can show a working version. Healthy projects deliver small usable pieces every few weeks. Months of "it will all come together at the end" is a risk.
The scope document keeps growing. New features are added, nothing is removed, and the budget and timeline stay the same on paper.
Only one person understands the system. If a single developer leaving would freeze everything, the project is fragile.
Your staff have not touched it. The people who will use the system daily have not tested anything yet, so their objections will arrive late and expensively.
Questions get answered with jargon. A good team can explain problems in plain language. Constant technical fog often hides uncertainty.
Payments are ahead of deliverables. You have paid most of the contract value but received less than half of the agreed functionality.
There is no list of what is finished. Without a clear list of done items, nobody can judge how far the project really is.
How to reset a project that is going wrong
Resetting is not punishment. Done calmly, it often rescues the useful half of a project.
- Call a short pause. Stop new feature work for one to two weeks. Keep the team, but focus everyone on clarity.
- Ask for a live demonstration. Not slides. The team shows what works today, on real devices, using realistic data.
- List what is done, half done and not started. Write it in plain language your staff can read.
- Cut the scope to the smallest useful version. Choose the features without which the system is useless and postpone everything else.
- Name one decision owner on your side. This person approves or rejects every new request and can say no.
- Re-plan in short cycles. Agree on a usable delivery every two to four weeks, with payment linked to what is delivered.
- Set a stop condition. Write down in advance what result by what date would make you stop, so the decision is not made in panic later.
When stopping is the right decision
Stopping makes sense when the reset shows that the smallest useful version is still far away, when the team cannot explain the remaining work, or when a ready-made product now covers most of what you need. In those cases continuing usually means paying again for the same uncertainty.
Before stopping, secure what you have paid for. Make sure you receive the source code, design files, database structure, server access and documentation, in whatever state they are. Check what your contract says about ownership and handover; if it is unclear, a lawyer can advise on your rights.
Then look for value you can still keep. Sometimes the data cleanup done during the project, the process maps or the list of requirements are worth more than the code itself, because they make the next attempt, or the choice of ready-made software, much faster.
It also helps to write a short, blame-free review while memories are fresh. What did we ask for that we did not need? Which warning sign appeared first, and why did nobody act on it? Which decision would we make differently? Two pages of honest notes protect the company far better than a vague feeling that "tech projects are risky".
Finally, talk honestly with staff. A cancelled project leaves people tired and sceptical. Explaining what was learned and what happens next prevents that scepticism from killing the next, better-chosen project.
Continue, reset or stop: a quick decision guide
Use this after the live demonstration and the honest status list.
| Situation | Likely decision | Why |
|---|---|---|
| Core features work, extras are late | Continue with reduced scope | The useful part exists; delay the rest |
| Some core features work, plan is unclear | Reset with short cycles | Value exists but needs control |
| Nothing usable after many months | Seriously consider stopping | Further money buys more uncertainty |
| A ready-made product now covers most needs | Stop or switch | Custom work no longer pays for itself |
| Key developer has left, no documentation | Pause and assess handover first | Risk is too high to keep building |
Frequently asked questions
How often should a software project show working results?
Every two to four weeks is a healthy rhythm for most business projects. Each delivery does not need to be complete, but it should be something real people can try.
Is it normal for tech projects to go over budget?
Some overrun is common, especially when requirements were vague at the start. What is not normal is overrun without explanation, or a budget that grows while delivered results stay flat.
Should we change vendors in the middle of a project?
Only after securing the full handover of code, accounts and documentation, and after a new team has assessed what they receive. Switching without a clean handover often means starting again from zero.
How do we say no to new feature requests from managers?
Keep a visible list of postponed ideas and promise to review it after the core system works. People accept "not now" more easily than "never", and the list often shrinks once the system is in use.
Who should own a tech project inside a small company?
Someone from the business side who understands the daily work and has authority to decide, supported by technical advice. Leaving ownership entirely with the external developer means nobody protects the company's priorities.
