A pilot customer asks when they can start. Or an investor asks whether the launch date still holds. You give the date. Later, you realize the only source for that answer is your vendor's last weekly update.
That update said "on track." So did the one before it. The launch date has still moved at least once, and you cannot tell whether the uneasy feeling is instinct or nerves.
You can check without reading the code. Below are 7 software development red flags, each with a question to send your team this week and a benchmark for what healthy looks like. At the end, you will find a self-check table and a 2-week plan for when 3 or more signs show up.
Bad news travels up slowly on software projects, including well-run ones. Researchers have tracked this for more than 20 years:
Outsourced development widens the gap. Your vendor has a commercial reason to keep the account calm, and you have fewer ways to check what you hear.
Every extra person between the developer and you adds a filter:
No one lied. Each person rounded up a little.
Frederick Brooks described the result in The Mythical Man-Month (1975): "How does a project get to be a year late? One day at a time." Each small slip is easy to defend, so the slips add up unnoticed.
For you, this means status reports are the least reliable information you have. The 7 signs below are things you can check yourself.
A good team having a rough month can show the same early signs as a bad development team. So treat each sign as a reason to ask a question, and hold your conclusions until you see the answer.
What it looks like. Your weekly report says "on track," same as the last 5. Nothing has ever turned yellow. Yet the launch date moved.
Why it happens. Project managers call this watermelon reporting: green on the outside, red on the inside.
The report tracks activity, like meetings held and tickets closed. The risk sits in work that has not made it onto the report. And if the last yellow week led to a tense call, the team has learned to avoid yellow.
What to ask this week.
"What is the one thing most likely to make us miss the next milestone?"
A team on top of its work answers in 1 sentence. A vague answer, or "nothing, we're on track," is the signal.
What healthy looks like. A useful weekly update covers:
A status that turns yellow now and then is a good sign. A project that has gone months without one is rarely reported accurately.
What it looks like. A feature has sat at "about 90%" for weeks. Each update nudges the number up a point, and it never reaches 100.
Why it happens. Tom Cargill of Bell Labs described this in a line Jon Bentley made famous in 1985:
"The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time."
Percent-complete is a guess. The slowest work sits in that last 10%:
A sprint is a fixed work cycle, usually 2 weeks. So 3 sprints at "90%" means about 6 weeks of work no one has listed.
What to ask this week.
"What exactly is left, as a list, and which items have you not started?"
What healthy looks like. Work is tracked as done or not done against a written definition of done. That is a short checklist every feature passes before anyone calls it finished, for example:
Once the checklist exists, percentages drop out of your updates.
What it looks like. Demos arrive as slides or screen recordings, or get pushed to "next sprint." You have seen plenty of pictures of your product and have not used it yourself.
Why it happens. Unfinished work is hard to show live. A screenshot can show a design that was never built. A recording can skip the screen that crashes.
That makes this the most reliable sign on the list, because working software is the hardest thing to fake. What to ask this week.
"Can you send me a link to the staging environment so I can try it myself?"
A staging environment is a private copy of your product where the team tests new work before release. If your team does not have one, ask why.
What healthy looks like.
For reference, DORA's 2024 Accelerate State of DevOps report groups high-performing teams as releasing between daily and weekly. You do not need that pace. You do need something you can open every sprint.
What it looks like. Each re-estimate adds 2 weeks, and none comes in shorter. When you ask why, you hear "it took longer than expected."
Why it happens. Some overrun is normal. McKinsey and the University of Oxford studied more than 5,400 IT projects. Large ones (initial budgets over $15 million) ran 45% over budget and 7% over time on average, and software projects carried the highest risk of overruns.
So a software project behind schedule is common. Watch for a slip with no named cause. It usually means the team does not know the cause, or does not want to say.
When the team does dig in, the cause is usually one of these:
What to ask this week.
"What did we learn that changed the estimate?"
What healthy looks like. Every slip comes with a reason and a decision for you to make:
What it looks like. You report a bug. It gets fixed. Two releases later, it is back.
Or a new feature breaks something that worked last month.
Why it happens. Usually, missing automated tests and rushed code. Automated tests are small programs that check the product still works after every change. Without them, each release is a gamble.
The team then spends more of its week fixing than building. Stripe's 2018 Developer Coefficient survey found developers spend about 17.3 hours a week on maintenance, such as debugging and refactoring. The survey covers developers in general, with no separate figure for outsourced teams.
What to ask this week.
"Do we have automated tests? Roughly what share of the code do they cover, and do they run before every release?"
What healthy looks like.
As a benchmark, DORA 2024 puts elite teams' change failure rate (the share of releases that cause a problem in production) at around 5%.
What it looks like. A simple question gets a long technical answer you cannot follow, or no answer until the next call. You have started to feel like the problem, so you ask less.
Why it happens. Jargon is often an unconscious defense. Burying a question in detail is easier than admitting bad news, which is the mum effect again.
The bigger risk sits on your side. Once you stop asking, you depend entirely on what you are told.
What to ask this week.
"Explain it to me as if I had to explain it to an investor tomorrow."
What healthy looks like. A good team explains any decision in 2 or 3 plain sentences and welcomes the question. If you still do not follow, ask 2 more:
What it looks like. You have no access to the code repository, the task board, or the hosting accounts. Everything reaches you as a summary.
Why it happens. Sometimes it is convenience, sometimes control. Either way, everything you know has passed through someone else's filter.
It is also a business continuity risk, and a common offshore development red flag. If the relationship ends, you may not own, or even be able to reach, what you paid for. What to ask this week.
"Please add me to the repo, the task board, and the hosting account as an owner."
What healthy looks like. From day 1, you own or co-own:
You can see commit activity (the log of code changes) without reading any code. If the repo shows no commits for 2 weeks, ask what the team has been working on.
Screenshot this table, or copy the "Ask this" column into a message to your vendor.
|
Sign |
Ask this |
Healthy answer |
Red-flag answer |
|
Always green |
What could make us miss the next milestone? |
A specific risk, named in 1 sentence |
"Nothing, we're on track" |
|
Stuck at 90% |
What exactly is left? |
A list marked done / not done |
"Just finishing touches" |
|
No working demo |
Can I get the staging link? |
A link today |
"Next sprint" |
|
One-way estimates |
What changed the estimate? |
A named cause, plus options |
"It took longer than expected" |
|
Recurring bugs |
Do tests run before each release? |
Yes, with a coverage number |
"We test manually" |
|
Jargon or silence |
Explain it like I am telling an investor |
2 to 3 plain sentences |
A longer technical answer |
|
No access |
Add me as owner on the repo and hosting |
Done the same day |
Delays, or "we'll send reports" |
How to read your result:
Most software projects slip. The Standish Group's CHAOS 2020 data rates only 31% of projects successful, 50% "challenged" (late, over budget, or short on features), and 19% failed.
Researchers have questioned the CHAOS methodology (Eveleens and Verhoef, 2010), so treat those figures as directional.
What tells you more is how the delay reaches you:
|
Normal delay |
Delay in trouble |
|
|
How you hear about it |
The team flags it early |
You discover it yourself, late |
|
Explanation |
A named cause |
"It took longer than expected" |
|
What comes with it |
Options for you to choose from |
A new date, already set |
|
Example |
"The payment provider's test environment keeps failing. We can launch without saved cards, or hold the launch 10 days." |
A demo quietly does not happen, or an investor asks and you realize you do not know |
A delay you hear about early is manageable. A delay you discover is the real warning.
For that independent look, you can schedule a team assessment with Sproutly, whether you plan to keep your current team or not.
Sproutly works with startups and small businesses that build software with outsourced teams. Our model has 3 steps: define, assess, and monitor.
We help you define what you are building, assess your current team or find a new one, and monitor progress, so you have evidence to go on besides status reports.
Tow Ninja came to us with a partial MVP from a previous developer, a tight budget, and legal reporting requirements to meet in Harrisonburg, VA. We:
Tow Ninja launched its pilot, met the city's reporting requirements, and onboarded tow companies, drivers, and vehicle owners. Read how we took over a partial MVP, or browse more client stories.
"We were just kind of walking around in the dark before Sproutly came on board." Jason Wilhelm, Product Manager
You can also meet the team behind Sproutly.
If you recognized 3 or more of these signs, schedule a team assessment. You will get a plain-language read on where your project stands, from people who do not work for your vendor.
Check what you can see for yourself: working software on a staging link, fixed bugs that stay fixed, plain answers to plain questions, and owner access to your repository and hosting. Good developers make their work easy to check. If most of what you know comes from status reports, you are relying on the least reliable signal.
Yes, it is common. The Standish Group's CHAOS 2020 data rates only 31% of projects successful, and McKinsey found large IT projects run 7% over time on average. The red flag is a delay you discover yourself, late, with no explanation. A delay your team flags early, with a reason and options, is manageable.
Watermelon reporting is project status that looks green on the outside and is red on the inside: updates say "on track" while problems build underneath. It usually comes from optimistic bias. One study found project managers' status reports were biased 60% of the time, mostly in the optimistic direction. Sign 1 above gives you a question that cuts through it.
Yes, from day 1, as an owner. Access lets you see commit activity without reading code, and it protects you if the relationship ends. Without it, you may not be able to retrieve the product you paid for. Owner access to the repository, hosting, domain, and credentials is a standard request, and a good vendor will grant it.
Do not switch on signs alone. One sign is worth a conversation, and 2 in the same month are a pattern to raise. At 3 or more, get an independent assessment before deciding anything. Switching mid-build is expensive. If the root cause is unclear requirements or weak reporting, it will follow you to the next team.
Technically, yes, if you already have access to the repository. In most cases, telling them works better. An assessment goes faster with the team's cooperation, because they can explain decisions the code alone does not show. Framing it as a routine health check, the kind an investor might ask for, also keeps the working relationship intact.