Red flags in a software project (and what to do about them)
Software projects almost never collapse overnight. They drift. A missed update here, a vague answer there, a demo that keeps getting postponed. By the time it is obvious, a lot of money and goodwill have gone.
The upside is that the warning signs show up early, if you know where to look. Here are the ones we would take seriously, whether you are about to sign with a team or already halfway in.
Before you sign
A price with no questions asked. If someone quotes you in the first call without asking what you are trying to do, the number is a guess. Maybe an optimistic one.
Guaranteed dates and fixed prices for fuzzy ideas. Certainty is comforting, but nobody can promise it about something that has not been defined. Be wary of confidence that the scope does not support. Our guide to choosing a partner has more on this.
No pushback, ever. A team that agrees with everything is either not listening or not thinking. You want someone who will say "that will cost more than it is worth."
Vague ownership. If it is unclear who owns the code, designs, and accounts at the end, fix that in writing now.
During the build
Long silences. Updates should be regular and boring. If you have not seen anything for weeks, ask for a demo this week. Progress you cannot see is progress you cannot verify.
Demos of screenshots instead of working software. Mockups are fine at the start. Later, you should be clicking through something real, even if it is rough.
"Almost done" for a month. When a task is permanently ninety percent finished, something is wrong. Ask what specifically remains.
Surprises about money or time. A change in cost should never arrive as a shock. Good teams flag trouble early and talk through options.
Lots of rework on the same feature. If a screen keeps being rebuilt, the requirements were unclear or the communication is. Pause and fix that before more is spent.
On your side of the table
Not every red flag comes from the vendor. Some come from us, the clients.
- Constantly changing direction. Each pivot is real work. Some change is healthy; weekly reversals are not.
- Slow answers. If questions sit unanswered, the project waits too.
- Too many opinions. Five stakeholders with five visions is how a clear product becomes a muddy one.
- Adding "one small thing" repeatedly. This is how scope grows by stealth. See what to leave out of a first version.
Being a good client is genuinely one of the best predictors of a good result.
Warning signs in the software itself
Things you can notice without any technical knowledge:
- It breaks when you do something slightly unexpected.
- Fixing one problem creates another somewhere else.
- Pages are painfully slow even with little data.
- There is no record of what changed or why.
- Nobody can explain how to set it up from scratch.
Any of these deserves an honest conversation, ideally with a second opinion from an independent developer.
What to do when you spot one
- Say it plainly and early. Describe what you have seen. Do not wait for a perfect moment.
- Ask for specifics. "What is blocking this, and what do you need from me?"
- Shrink the next step. Ask for a small, demonstrable piece within a week or two.
- Get it in writing. Agreements about scope, dates and money should be recorded.
- Consider a review. An outside developer can look at the work and tell you whether it is healthy. It is cheaper than finding out later.
When to walk away
It is a hard decision, and sunk cost makes it harder. But if trust is gone, if you cannot see real progress, or if the team will not engage with problems, continuing may cost more than stopping. Make sure you hold the code, your accounts, and your data first. That is why ownership matters from day one.
A closer look at three common patterns
Warning signs are easier to spot when you have seen how they play out. Here are three patterns that show up again and again.
The disappearing team
At the start, communication is excellent. Daily messages, quick answers, lots of energy. Then, a month in, replies slow down. Updates become vague. Meetings are rescheduled. Eventually you learn that the people who started your project have been moved to something else.
What to do: ask directly who is working on your project this week and what they accomplished. Ask for a recurring demo of working software on a fixed day. And make sure your contract names the people and the expected availability, not just the company.
The endless almost
Everything is nearly done. The login works, the main screen works, but a few things are left. Weeks pass. The remaining list never seems to shrink, and nobody can say precisely when it will.
What to do: break the remaining work into a written list, with each item small enough to finish in a day or two. Ask for an honest estimate on each and agree on what "done" means. A list you can tick off is a very different thing from a feeling that you are close.
The moving target
The scope keeps growing, and nobody quite knows how it happened. Each change was reasonable. Together they have doubled the project, and the budget and date are now fiction.
What to do: stop and reset. List everything in the current plan, mark what is essential, and agree what moves to a later phase. Then put a process in place so that every new request is weighed against time and cost before it is accepted. It is not about saying no; it is about making the trade visible.
Questions that surface problems early
Rather than waiting for symptoms, ask these on a regular basis:
- What is the riskiest part of the project right now?
- What are you waiting on from me?
- Has anything changed from the plan, and what does it do to the date?
- What would you do differently if you started this part again?
- What can I look at today that is actually working?
Healthy teams answer these easily, and often welcome them. If the answers are evasive, defensive, or always "everything is fine," keep asking, politely.
Protect yourself from day one
A few habits cost almost nothing at the start and are very valuable if things go wrong:
- Hold the keys. Your hosting, domain, code repository, and third-party accounts should be registered in your name, with the vendor added as a user.
- Pay against delivery. Tie payments to demonstrated milestones, not only to dates.
- Keep copies. Ask for regular access to the code and any design files, and confirm that you can actually open them.
- Write down decisions. A short email after each call saying what was agreed is enough.
If a project does go sideways, these habits turn a disaster into an inconvenience. You can bring in someone else, hand over the material, and continue.
Ask for a second pair of eyes
If you are not technical and something feels off, hire an independent developer for a few hours to review progress. They can look at the code and the working software and give you a plain report on quality and risk. It costs little compared to the project, and it gives you something you cannot get from the team itself: an unbiased view.
Not every delay is a red flag
It is worth saying that problems are normal. Software is hard, estimates are imperfect, and surprises happen. A late feature or a bug is not a sign the team is bad.
What matters is how they respond. A good team tells you early, explains what happened in plain words, and proposes options. A concerning one hides it, blames others, or goes quiet. Judge people by how they handle trouble, not by whether trouble ever shows up, because it always will.
Worried about a project that is not going well, or want a sanity check on a plan? Get in touch. We are happy to take a look and tell you what we see.
