Signs That an App Project Is Set Up to Fail

Dating back to the dawn of my career as a developer, this project holds a special place in my professional evolution. It taught me invaluable lessons, helping me identify warning fail signs that indicate when a project is in crisis and needs rescue.

Here, I'm going to point out three critical causes of software project failure that I believe one should stay away from when developing an app if they want it to ever have any users. Concurrently, I'll share a story about this project to show just how harmful these new product development pitfalls can be.

Issue #1. There Is No Plan for the App Release

The customer approached our company with an existing app project, previously overseen by a single engineer. They were looking to speed up development, and that is how I became involved in the project, stepping in as this engineer's assistant.

I'm Adding an Auto Photo Gallery, but Why?

No one briefed me on the project's details. Instead, the customer assigned me my first task, which was concise:

• Implement a photo gallery feature to the car listings on the website.

So, I learned that we're building a website with car listings. Yet, their purpose and audience remained unclear to me. Perhaps my role in the project is quite limited, and I don't need to know more? However, it didn't take long to notice that even the lead engineer was unaware of this.

The customer's practice was to withhold their plans from developers and only disclose information essential for accomplishing current tasks.

Who Will Comment on Auto Photos?

The customer's next task was even more mysterious:

• Incorporate the capability to comment on photos attached to car listings.

Why would website visitors want to comment on these photos? The customer clarified that users of this web app will upload photos of their own cars and wish to leave comments on each other's pictures.

Yet, prior to users being able to leave comments, they must have the ability to:

• Sign up and log in to the website.
• Create, edit, and delete their car listings, including photos.

We need to incorporate these features first. This situation demonstrates why providing developers with tasks without explaining the purpose may not be the best idea. Here's a striking story with a similar project management failure example, showing how developers stray from the customer's intended outcomes in such a scenario.

What Are We Trying to Build Here, Anyway?

Why go through the trouble of building a dedicated app for sharing car photos when it can be done anywhere? I finally posed this question to the customer. After all, it's not just curiosity (although that's certainly a part of it); ultimately, you can't excel in a task unless you grasp its essence.

Based on the customer's reply, here are the key points of the app's concept:

1. The app is intended to be a social network for a niche group of users.
2. The target audience includes car collectors, especially the customer and their global network of friends.
3. The app should serve as a convenient way for them to proudly display their collections and recent purchases.

As I see it, the customer's development approach didn't extend beyond planning one step ahead. After delivering a new feature, they decided the app's next needs based on their personal preferences.

How Can We Know When the App Is Ready for Release?

What features should the app have for users to get started with it? Neither the customer nor the developers had an answer to this question. It appears that the customer intended to continue improving the app until they were pleased with it.

I believe that such an approach can be fatal, ultimately leading to the failure of IT projects, as it often makes a release nearly unattainable. I also hold that this project mistake is the fundamental reason for all following issues in this project. Let's continue to see how this played out.

Issue #2. There Is No User Feedback

No release means no users for the app, and consequently, there's no feedback from them either. As a result, the customer relied solely on their own perception of user desires.

How Long Should the App's Car Models List Be?

After adding the commenting feature, the customer's next request was:

• Make a dropdown list of car models.

In this way, the customer intended to provide users with the ability to select from predefined options instead of having to input their car models in varying formats.

Here's how the customer went about compiling this list:

1. They strived to include into this list every car model ever produced. It expanded rapidly, seemingly without end.
2. They decided to introduce a special notation for models in this list that have different names in various countries. This magnified the technical difficulties even further.

Given the app's likely restricted user base and rather limited number of cars owned by its users, does it make practical sense to provide them with such a vast selection of car models?

Does Anyone Actually Go So Deep Into Car Specification Details?

Car enthusiasts take pride in the technical parameters of their vehicles, like top speed, and 0 to 100 km/h acceleration. And they often upgrade their cars to achieve even more impressive numbers. Hence, they have a strong desire to compare these stats with one another. This feature became our next task, which was defined as follows:

• Allow car listings to feature technical specifications.
• Implement automatic conversion of these parameters between metric and imperial units, depending on the user's profile information.
• Allow users the opportunity to demonstrate the impact of car upgrades on technical specifications, if the owner has modified their vehicle.

The list of car specifications was truly extensive, and enabling the automatic conversion of all of them proved to be quite a labor-intensive task. One particularly striking example is the fuel consumption parameter, which quite literally caused development to encounter a roadblock.

The fuel consumption is measured in the metric system as liters per 100 kilometers, while the imperial system uses the inverse unit - miles per gallon. Furthermore, it's computed using a lengthy and intricate formula. Enabling the app to convert the car modification impact on fuel consumption between different unit systems forced me to dive into mathematical theory and spend a considerable amount of time.

Given that car enthusiasts usually don't pay much attention to fuel consumption when upgrading their cars, was it reasonable to dedicate such a substantial amount of resources to something that may not provide value to users?

How Many Languages Should Be Available Within the App?

Afterward, we translated the app into several additional languages since the customer's friends resided in various parts of the world.

It's not unlikely that specific languages were warranted by a rather small user group. Until the app had any users, the value of its content was unknown. Did it make sense to commit a substantial budget to extensive translations in this context?

Issue #3. There Is No Budget Planning

The customer planned to fund the app's development using their own finances. Regarding monetization, the app included a payment feature, albeit solely for voluntary donations. However, since the app had no user base, the customer never received any contributions.

Could Anyone Expect It to Be This Expensive?

With no development plan or defined endpoint, the customer had no grasp of the eventual expenses. They kept adding features to the app without much concern, until they were surprised to find that their budget had run dry.

The customer's choice was to sell one of the luxury cars from their collection, allowing them to keep working on the project. However, these funds also ran out quickly, while the customer still had many improvements in mind for their app.

Based on our experience, it's not uncommon for customers to underestimate their project's costs. Regrettably, unless a customer continuously commits to budget planning and adherence, the project usually ends when the funding dries up. This is particularly evident in projects lacking monetization strategies. So, the absence of project budget oversight is a clear fail sign.

Why Not Cut Expenses by Going With Engineers Who Charge Less?

The customer opted to change the team in order to save on further development. My involvement in this project came to an end, spanning a total of six months. Nonetheless, we eventually discovered the outcome of this story.

Two years later, the customer approached our company again with a rather unusual request. They no longer sought to extend the app's features and simply asked us to enhance the website's performance, as it had become unacceptably slow.

Those are the updates we learned about this project:

• Throughout these two years, the app was under active development.
• Still, no user had seen it - the release never happened.
• Yet, the app grew considerably in size, while the customer sold more of their precious autos to cover expenses on development.
• The performance problems were likely due to the excessive accumulation of less-than-optimal code.

As I see it, the cost savings the customer achieved by changing teams were quite illusory.

If the code lacks quality, it becomes the source of expenses to deal with it, no matter how cheap its development was. Furthermore, creating features without a clear release plan can anyway result in a complete loss of investments, as the app might never reach users. Our engineers have authored an article to share such stories with failed project examples and provide their thoughts on proven alternatives for saving in development.

Did the Story Have a Happy Ending?

Upon considering the costs of enhancing the app's quality and performance, the customer chose to abandon this idea. This ultimately sealed the app's fate - it remained unseen by any users. Nonetheless, there's a valuable lesson we can take away from this story.

As for me, this project played a critical role in shaping my professional journey. It was a tough experience, but it taught me the clear difference between a project that fails and one that succeeds. Ever since, I have been persistently working to structure projects from the outset in a way that makes such outcomes implausible. Some may view this as a positive turn.

So, How to Safeguard a Project From Being Set Up for Failure?

There are well-established practices for effective project management that have demonstrated their effectiveness in enhancing the prospects of app success. Their key points to stick to are simple and mirror the three warning fail signs I just mentioned.

1. App development starts with planning the release. It involves recognizing the essential features the users require to start using the app. Once this is done, it becomes simple to estimate the development timeline and establish release deadlines.
2. After the release, we need user feedback to guide development. To determine if users require the feature and if they find it satisfactory, we must rely on their feedback. Implementing features without gathering user opinions carries risks.
3. The project budget has to be managed to fit the release plan. Regardless of the project owner's approach to app monetization or funding, their budget has predefined limits. Thus, it's essential to follow the release plan and steer clear of expensive features with uncertain user value.

But What to Do Upon Encountering the Warning Fail Signs?

For a project to be robustly grounded, one thing is crucial: a highly professional development team. And its professionalism should extend beyond mere coding skills; those are insufficient by themselves. Two additional factors are critically important:

• The team must possess and strictly follow the well-established practices for proper project management - the industry standards I've mentioned before.
• The team must be able to communicate the significance of these practices to the customer.

Failure to do so will result in an irreversible build-up of problems in the project, which cannot be resolved from within. If your project demonstrates poor project management, has no definite goal, disregards user input, and spends recklessly, this is a signal that external help is needed. Otherwise, these issues could become reasons for crashing a project.

The first reasonable step to save the project is to consult with trusted independent experts and conduct a project audit. Confirming your suspicions would likely necessitate changing the team, or at least its leadership.

It All Might Have Gone Another Way

Looking back at the website I described as a failed project example, I believe if it had been led by our company's manager, or if I possessed then enough experience to prompt their intervention, we could have stuck to proper practices.

Under those circumstances, I believe the project's outcome could have been entirely different. The customer could have been happily using the app to share their collections with friends, all within a few weeks of the project's commencement.