It’s that creeping chill —&nbsp;what you feel and what you’re told about your application build seem like two different things. There’s movement, there’s progress, but there’s also a sneaking suspicion that it’ll all go wrong. Trust that intuition. No one wants to be the client who cried wolf, but we’ve joined a lot of “almost done” projects that were anything&nbsp;but.&nbsp;



There’s no surefire way to condemn a piece of in-progress software, but the problematic ones leave traces. Here are some of the usual signs, which may help validate (or assuage) your current&nbsp;concerns:



<ul><li>What you’re hearing, covering the style and substance of&nbsp;communication</li><li>The technical details, diving into the hints of development&nbsp;issues</li><li>What you’re seeing, handling the reality of what’s being&nbsp;delivered</li><li>(Struggling) project benchmarks, putting numbers to problem&nbsp;projects</li></ul>



Don’t wait to get your software project back on track. Download our whitepaper to help determine if those signs are red&nbsp;flags.

&lt;figure&gt;&lt;img src=&quot;https://wordpress.envylabs.com/wp-content/uploads/2023/08/SignsMissFinishLine_Header.jpg&quot; alt=&quot;&quot; width=&quot;1600&quot; height=&quot;610&quot; /&gt;&lt;/figure&gt;

&lt;p&gt;It’s that creeping chill — what you &lt;em&gt;feel&lt;/em&gt; and what you’re &lt;em&gt;told&lt;/em&gt; about your application build seem like two different things. There’s movement, there’s progress, but there’s also a sneaking suspicion that it’ll all go wrong. Trust that intuition. No one wants to be the client who cried wolf, but we’ve joined a lot of “almost done” projects that were anything but.&lt;/p&gt;

&lt;p&gt;There’s no surefire way to condemn a piece of in-progress software, but the problematic ones leave traces. Here are some of the usual signs, which may help validate (or assuage) your current concerns.&lt;/p&gt;

&lt;h2&gt;Part 1: What You’re Hearing&lt;/h2&gt;

&lt;p&gt;For a group of developers, we sure talk about communication a lot (like &lt;a href=&quot;https://envylabs.com/insights/software-project-communication-success/&quot;&gt;here&lt;/a&gt;, &lt;a href=&quot;https://envylabs.com/insights/communication-benefits-of-wireframing/&quot;&gt;here&lt;/a&gt;, and &lt;a href=&quot;https://envylabs.com/insights/semantics-communication-software-development/&quot;&gt;here&lt;/a&gt;). It’s key to a project’s success, and what you’re hearing — or &lt;em&gt;not&lt;/em&gt; hearing — is the first source of potential red flags. Let’s look at the typical trouble spots.&lt;/p&gt;

&lt;h3&gt;Inconsistent, Irregular Conversations&lt;/h3&gt;

&lt;p&gt;Scheduled check-ins add routine and accountability. There’s space (and an impetus) to talk about things while they happen. Software tends to struggle in silence.&lt;/p&gt;

&lt;p&gt;With inconsistent communication, it feels like requirements are being tossed over a wall, and you’re waiting weeks or months to hear back. When there &lt;em&gt;is&lt;/em&gt; something to see, it’s rife with issues that should’ve been talked about in real time. Feedback runs through a similar loop: talk, wait, wait, half-baked delivery.&lt;/p&gt;

&lt;p&gt;Going extended stretches without contact isn’t the norm.&lt;/p&gt;

&lt;h3&gt;Hesitancy to Talk Details With Anyone Else&lt;/h3&gt;

&lt;p&gt;Modern applications are a grab bag of integrations, dependencies, and custom code. Other groups may need a peek behind the curtain, like:&lt;/p&gt;

&lt;ul&gt;
  &lt;li&gt;Specialists working on a specific feature&lt;/li&gt;
  &lt;li&gt;Security analysts for certain industries or certifications&lt;/li&gt;
  &lt;li&gt;Potential customers with stringent security or integration needs&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;If a development team is reluctant to share details or help outside parties (save for a really good reason, like protecting intellectual property), it makes sense to be uneasy. Hiding a report card says a lot about what’s inside.&lt;/p&gt;

&lt;h3&gt;Deadlines Come and Go Quietly&lt;/h3&gt;

&lt;p&gt;Communication has to handle the good &lt;em&gt;and&lt;/em&gt; the bad.&lt;/p&gt;

&lt;p&gt;Software leans on the word &lt;em&gt;estimate&lt;/em&gt; a lot and, as the name implies, estimates won’t always hit the mark. You’re virtually assured that some features will slip. The question: How’s that handled? Do you know ahead of time? Do you have an idea of why? Do you have a say in the solution? It isn’t a fun conversation, but it still needs to happen.&lt;/p&gt;

&lt;h3&gt;No One Knows What’s Left&lt;/h3&gt;

&lt;p&gt;“What’s left?” shouldn’t kick off a research project for your PM. There will always be in-progress tasks and tickets waiting on an update, but everyone should have a place to go (including you) for a general sense of status. Something like a:&lt;/p&gt;

&lt;ul&gt;
  &lt;li&gt;Kanban board&lt;/li&gt;
  &lt;li&gt;Gantt chart&lt;/li&gt;
  &lt;li&gt;Simple to-do list&lt;/li&gt;
  &lt;li&gt;Series of scribbles on a sticky note&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;&lt;em&gt;How&lt;/em&gt; is less important than having &lt;em&gt;something&lt;/em&gt;, and a quick glance goes a long way towards reconciling the team’s updates. After all: If there isn’t a shared understanding of work-to-be-done, what are the budgets and timelines based on? Estimates have wiggle room, but they shouldn’t be pure guesses.&lt;/p&gt;

&lt;h3&gt;Open-Ended Checkpoints&lt;/h3&gt;

&lt;p&gt;Software fills whatever time you give it. We’re pretty sure that’s what the Theory of Relativity is all about, or something like that.&lt;/p&gt;

&lt;p&gt;An application without a deadline sounds like a developer’s dream, but it’s a decision-making nightmare. There are no constraints to guide goals and needs — anything goes, and it’s hard to argue against a change or addition. Even if it’s not “real,” someone should put a date on a calendar to avoid a runaway build.&lt;/p&gt;

&lt;h3&gt;Planning Was Skipped&lt;/h3&gt;

&lt;p&gt;A kitchen, a garage, a living room, a dining room, 3 bedrooms, and 2 bathrooms. If home construction relied solely on a list of requirements, we’d wind up with outcomes like:&lt;/p&gt;

&lt;ul&gt;
  &lt;li&gt;A nine-story tower, with the kitchen up top, dining room at ground level, and a garage somewhere in the middle.&lt;/li&gt;
  &lt;li&gt;One really big space for everything, sans walls.&lt;/li&gt;
  &lt;li&gt;Nine different, disconnected buildings.&lt;/li&gt;
  &lt;li&gt;A complete lack of closet space. Closets weren’t on the list, after all.&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;Writing code feels like progress, but coding in the wrong direction is a quick march towards failure. All parties should be advocating for prototypes, wireframes, diagrams, napkin sketches — whatever’s needed to avoid miscommunication and uncertainty. Otherwise, you’ll be stuck problem-solving for a fifth-floor garage.&lt;/p&gt;

&lt;h2&gt;Part 2: The Technical Details&lt;/h2&gt;

&lt;p&gt;In a twist that’ll surprise no one, the development part of your development project is the next vector for potential woes. Here’s what to watch for as the technical crew gets rolling.&lt;/p&gt;

&lt;h3&gt;The Developers Are Locked Away&lt;/h3&gt;

&lt;p&gt;Should you expect constant contact? Personal phone numbers and addresses? Nah. Playing &lt;a href=&quot;https://en.wikipedia.org/wiki/Chinese_whispers&quot;&gt;a game of telephone&lt;/a&gt; with the technical folks, though, is a lost opportunity. Some details will be lost on the round-trip through someone else (see, communication always creeps in), and live conversation has a habit of spitting out ideas.&lt;/p&gt;

&lt;h3&gt;Features Miss Their Target (Twice)&lt;/h3&gt;

&lt;p&gt;We’ve talked a bit about the volatile nature of estimates, deadlines, and &lt;em&gt;how&lt;/em&gt; problems are handled. As far as the problems themselves go, beware the two-layer surprise.&lt;/p&gt;

&lt;p&gt;A two-layer surprise? It’s not a baked good (sorry) — we’re referring to a feature with multiple revelatory moments. Maybe you want a widget showing total revenue for the last 30, 60, and 90 days. Surprise: Actually, only 30 days is really possible right now. Later, another surprise: Some data isn’t accessible, so it won’t quite be the “total” revenue.&lt;/p&gt;

&lt;p&gt;This isn’t an uncommon situation, but it cuts deep; the feature (and everything touching it) is now off-orbit and threatening to impact others. Trust is shaken, too. After two or more misses, what’s to say this feature won’t continue to be an issue?&lt;/p&gt;

&lt;h3&gt;New Surprises Are a Weekly Thing&lt;/h3&gt;

&lt;p&gt;Keeping with the surprise theme (but still not the fun kind, sorry), how often are they popping up? How far along is the project?&lt;/p&gt;

&lt;p&gt;New discoveries should be concentrated at the start of development and trail off as you go. If launch is “really close” while surprises continue to be a weekly thing, there’s cause for concern. The planning phase missed too many details, and it may be in the project’s best interest for you to pause it and resolve more uncertainty.&lt;/p&gt;

&lt;h3&gt;Technical Decisions Lack Explanation&lt;/h3&gt;

&lt;p&gt;You’re in an exam room. The doctor walks in, wordlessly draws a line on your leg, and pulls out a scalpel. You — very justifiably — have a few questions.&lt;/p&gt;

&lt;p&gt;Custom vs. off-the-shelf, third-party services, dependencies, integrations: There’s no “perfect” solution to most of an application’s needs. Each has pros, cons, and a business impact that you’ll need to understand and agree to (or at least respect). That calls for some physician-esque bedside manner from developers, covering the options, the impact, and what happens next.&lt;/p&gt;

&lt;p&gt;Are you in the loop on technical decisions? Ahead of time?&lt;/p&gt;

&lt;h3&gt;Too Many “Nice-to-Haves” Have Snuck In&lt;/h3&gt;

&lt;p&gt;Has your implementation team stopped pushing back? Did they ever push back? Are you advocating for “nice-to-have” additions and changes well beyond the planning phase? Like open-ended checkpoints, open-ended features keep moving the goalposts (and timelines, and budgets). There’s new complexity to deal with, and nothing’s ever truly &lt;em&gt;done&lt;/em&gt;.&lt;/p&gt;

&lt;p&gt;Setting a finish line and sticking to it is a shared responsibility. Otherwise, you’re left wondering why ten incomplete wishlist items are holding up the stuff that matters.&lt;/p&gt;

&lt;h2&gt;Part 3: What You’re Seeing&lt;/h2&gt;

&lt;p&gt;Once there’s code to look at, what are you looking for? Let’s cover the issues that’ll make an appearance when there’s something tangible to test.&lt;/p&gt;

&lt;h3&gt;Work Happens Somewhere You Can’t See&lt;/h3&gt;

&lt;p&gt;Even if the application hasn’t taken a shape you can click through yet, code is being pushed &lt;em&gt;somewhere&lt;/em&gt;. Preferably, that’s into a shared repository which, ideally, you have access to. Servers, monitoring, issue tracking, databases — you may not own the accounts (yet), but do you know which services are in use and have the means to take a look?&lt;/p&gt;

&lt;p&gt;Don’t worry, this isn’t a rallying cry for you to pitch in. But if you’re wondering what everyone’s up to, this is the most direct route.&lt;/p&gt;

&lt;p&gt;Further, work doesn’t have to be interactive to make the progress report. There’ll be plenty of behind-the-scenes tasks without flashy color or animation, like performance tuning, accessibility improvements, and dependency updates. Are those efforts being demoed or shown in a screencast?&lt;/p&gt;

&lt;h3&gt;The App Needs More Than “Some Polish”&lt;/h3&gt;

&lt;p&gt;An in-progress application has rough spots. Weird (or missing) animations, canned data, screen sizes that don’t look great, and so on. It’s tough to pinpoint when &lt;em&gt;rough&lt;/em&gt; crosses over to &lt;em&gt;problematic&lt;/em&gt;, but that may include:&lt;/p&gt;

&lt;ul&gt;
  &lt;li&gt;Lots of “popping” and shifting when loading&lt;/li&gt;
  &lt;li&gt;Inconsistent handling of color, type, and spacing&lt;/li&gt;
  &lt;li&gt;Difficulty sorting out which parts are interactive (or not)&lt;/li&gt;
  &lt;li&gt;A general lack of crispness, especially with images&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;We all use a lot of technology, and you don’t need a design background to intuit a modern look and feel. It’s a red flag if you’re relied on to set the quality bar.&lt;/p&gt;

&lt;h3&gt;Quality Assurance Has Been Tossed Aside&lt;/h3&gt;

&lt;p&gt;Do new deploys add new bugs or, worse, bring back old ones? This sign is an easy one: It should feel like someone’s actually looking at the site before it hits the server.&lt;/p&gt;

&lt;h3&gt;The Change Orders Are Stacking Up&lt;/h3&gt;

&lt;p&gt;Tables are in, but you expected column sorting. Payments are set, but mobile payments are missing. Users can sign up, but why can’t they use their existing Google accounts?&lt;/p&gt;

&lt;p&gt;Just like the section on late-stage surprises, gaps between expectation and execution reflect poorly on planning. Change orders shouldn’t be falling like dominoes. If you didn’t have a chance to talk about column sorting, what else is absent? How much can the budget take?&lt;/p&gt;

&lt;h3&gt;“Slow” Is a One-Sided Decision&lt;/h3&gt;

&lt;p&gt;The baseline for your application is fast. Snappy. Slowness is a problem that’s part polish, part technical explanation, and it’s painful for users (in the productivity and/or revenue sense). You shouldn’t be finding out late in the cycle that some features — data fetching, filtering, processing, navigation, etc — will be unavoidably sluggish, especially without recourse.&lt;/p&gt;

&lt;h2&gt;Part 4: (Struggling) Project Benchmarks&lt;/h2&gt;

&lt;p&gt;No two projects are alike, and your situation may vary. With that disclaimer out of the way, here are some recurring benchmarks we’ve seen &lt;strong&gt;struggling&lt;/strong&gt; projects meet.&lt;/p&gt;

&lt;h3&gt;Release: More Than a Year&lt;/h3&gt;

&lt;p&gt;Too many things change — the market, your customers’ needs, your domain expertise — if you’re not releasing something in the six-month range, much less a year. Many of the issue-laden applications we’ve seen are still preparing for launch 1–2 years in.&lt;/p&gt;

&lt;h3&gt;Faces: Three or More&lt;/h3&gt;

&lt;p&gt;Let’s face it: Keeping staff in the technology industry is a challenge. Still, if you’re pre-launch and the folks leading your product build have swapped out a few times, it’s worth examining why.&lt;/p&gt;

&lt;h3&gt;Staging: Nah&lt;/h3&gt;

&lt;p&gt;A lot of development effort will be behind the scenes, incomplete, and not very pretty. Even so, there aren’t many strong reasons against standing up a staging server. Early and throughout the project, you should be able to peek at the in-progress platform easily.&lt;/p&gt;

&lt;h3&gt;Reserve: Zero&lt;/h3&gt;

&lt;p&gt;Whether your development partner mandates it or not, there’ll be a handful of fixes, changes, and surprises right around launch that you’ll want to resolve. Don’t exhaust the budget completely to press the launch button.&lt;/p&gt;

&lt;h3&gt;Communication: Shrug&lt;/h3&gt;

&lt;p&gt;You should be able to see the work and see the back-and-forth as it happens, but you really should be chatting with the team (at least) weekly. Some conversations still happen better “live.”&lt;/p&gt;

&lt;h3&gt;Automated Tests: Nah&lt;/h3&gt;

&lt;p&gt;Small changes can have a big impact on applications, especially a few years in. There’s no guarantee that you’ll always have the same developers around, and the new ones will rely on automated tests to feel any sort of confidence towards updates.&lt;/p&gt;

&lt;h3&gt;Feeling: Dread&lt;/h3&gt;

&lt;p&gt;That 2:30 in the morning feeling — how would you characterize it? Listen to your gut. The technical side of things shouldn’t be the source of lost sleep.&lt;/p&gt;

&lt;h2&gt;Reviewing Red Flags&lt;/h2&gt;

&lt;p&gt;We’ve covered a lot of ground, and there are plenty more red flags out there.&lt;/p&gt;

&lt;p&gt;Software’s a big, complex beast of an undertaking. No one tackles it the same way, so it’s hard to tell if things are truly okay — especially when you’re being constantly reassured. We’ve had to break the bad news more times than we’d like. Hopefully, the nudges in this whitepaper offer a bit more clarity around the actual status of your project.&lt;/p&gt;

&lt;p&gt;Still not sure? &lt;a href=&quot;https://envylabs.com/contact/&quot;&gt;We’d be happy to chat&lt;/a&gt; about your current challenges and uncertainties.&lt;/p&gt;

Signs That Your Software Project May Miss the Finish Line

Unlock Content

Skip the Unlock Stuff

Up Next —

Designing Links: Tips for Implementing a Fundamental Piece of the Web

Insights: Sign Up